Adding hex format for native command exit codes #21067

sba923 · 2024-01-13T16:14:46Z

PR Summary

This implementation adds the hex-format version of the native command exit code message (#19886)

PR Context

PR Checklist

[X ] PR has a meaningful title
- Use the present tense and imperative mood when describing your changes
[ X] Summarized changes
[X ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ X] This PR is ready to merge and is not Work in Progress.
- If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
Breaking changes
- [ X] None
- OR
- Experimental feature(s) needed
  - Experimental feature name(s):
User-facing changes
- Not Applicable
- OR
- Documentation needed
  - [X ] Issue filed: 19886
Testing - New and feature
- N/A or can only be tested interactively
- OR
- [ X] Make sure you've added a new test if existing tests do not effectively test the code changed
Tooling
- [ X] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
- OR
- I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:
  - Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
    (which runs in a different PS Host).
    - Issue filed:
  - Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    - Issue filed:
  - Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    - Issue filed:
  - Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).
    - Issue filed:

pull-request-quantifier-deprecated · 2024-01-13T16:14:50Z

This PR has 6 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +3 -3
Percentile : 2.4%

Total files changed: 2

Change summary by file extension:
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

iSazonov · 2024-01-13T17:14:22Z

test/powershell/engine/Basic/NativeCommandErrorHandling.Tests.ps1

@@ -48,7 +48,7 @@ Describe 'Native command error handling tests' -Tags 'CI' {

            $error[0].FullyQualifiedErrorId | Should -BeExactly 'ProgramExitedWithNonZeroCode'
            $error[0].TargetObject | Should -BeExactly $exePath
-            $stderr[1].Exception.Message | Should -BeExactly "Program `"$exeName`" ended with non-zero exit code: 1."
+            $stderr[1].Exception.Message | Should -BeExactly "Program `"$exeName`" ended with non-zero exit code: 1 (0x00000001)."


Why not (0x1)?

Because the hex format used is the fixed-sized 0xNNNNNNNN, for readability's sake. Call it a matter of taste, but I find reading values such as 0xFE234 "less pretty/readable/usable" than 0x000FE234.

How this lokks in docs https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

Just an FYI while on Windows the rc is a 32-bit integer, on Unix they are just a single byte. I don't have a particular preference either way just wanted to share that in case it helps to make a decision.

Just an FYI while on Windows the rc is a 32-bit integer, on Unix they are just a single byte. I don't have a particular preference either way just wanted to share that in case it helps to make a decision.

Are you somehow suggesting that the parenthesized hex value should use 0x{1:X} format on non-Windows platforms and 0x{1:X8} format on Windows?

I say about remove leading zeros.

@SteveL-MSFT shouldn't that be discussed / decided upon by the team? Who is supposed to have the final say on this?

The Engine WG discussed this today and agree that on Linux & macOS the hexadecimal format should be 0x{1:X2}. We also suggest removing the formatting string from the resx and put it in code. That is change this:

<value>Program "{0}" ended with non-zero exit code: {1} (0x{1:X8}).</value>

to

<value>Program "{0}" ended with non-zero exit code: {1} (0x{2}).</value>

Then in code, do something like this:

const string errorId = nameof(CommandBaseStrings.ProgramExitedWithNonZeroCode); const string hexFormatStr = Platform.IsWindows ? "{0:X8}" : "{0:X2}"; string errorMsg = StringUtil.Format( CommandBaseStrings.ProgramExitedWithNonZeroCode, NativeCommandName, _nativeProcess.ExitCode, String.Format(CultureInfo.InvariantCulture, hexFormatStr, _nativeProcess.ExitCode));

pull-request-quantifier-deprecated · 2024-02-07T11:18:52Z

This PR has 10 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +6 -4
Percentile : 4%

Total files changed: 3

Change summary by file extension:
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

sba923

Changes made and committed to sba923:master. How do I add this to the PR?

pull-request-quantifier-deprecated · 2024-02-07T11:23:05Z

This PR has 12 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +7 -5
Percentile : 4.8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-08T05:07:08Z

This PR has 12 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +7 -5
Percentile : 4.8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-08T05:41:41Z

This PR has 12 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +7 -5
Percentile : 4.8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

rkeithhill · 2024-02-08T06:01:50Z

src/Microsoft.PowerShell.SDK/Microsoft.PowerShell.SDK.csproj

@@ -17,7 +17,7 @@
  <ItemGroup>
    <!-- This section is to force the version of non-direct dependencies -->
    <!-- the following package(s) are from https://github.com/dotnet/fxdac -->
-    <PackageReference Include="System.Data.SqlClient" Version="4.8.5" />
+    <PackageReference Include="System.Data.SqlClient" Version="4.8.6" />


Does this change need to be part of this PR?

Nope, this clearly doesn't, but the CI builds all fail without that change....

Other than this issue, the PR LGTM.

OK, will let someone from the PS team chime in on what's going on here.

Great.

Will fix the Code Factor issue, BTW.

Will fix the Code Factor issue, BTW.

Done

OK, will let someone from the PS team chime in on what's going on here.

I've done this in a separate commit, JIC.

If this has to be done elsewhere (which would totally make sense) I'll probably need some help to exclude that commit from the PR, 'cos that's something I've never done.

This change was made in #21084.

I would suggest updating the PR with a merge commit.

I've done this in a separate commit, JIC.

If this has to be done elsewhere (which would totally make sense) I'll probably need some help to exclude that commit from the PR, 'cos that's something I've never done.

@sba923 Just revert that specific commit now that it's been in the PR mentioned above by @xtqqczze and ensure that you rebase from the powershell/main branch as that's cleaner than adding merge commits in your PR

Hi, I have reverted the commit (which results in the CI build to now fail with /home/runner/work/PowerShell/PowerShell/src/Microsoft.PowerShell.SDK/Microsoft.PowerShell.SDK.csproj : error NU1903: Warning As Error: Package 'System.Data.SqlClient' 4.8.5 has a known high severity vulnerability, https://github.com/advisories/GHSA-98g6-xh36-x2p7 [/home/runner/work/PowerShell/PowerShell/src/powershell-unix/powershell-unix.csproj]), but I can't seem to get the rebase to work. Can you please help me out with that (either using the git CLI or VScode)?

pull-request-quantifier-deprecated · 2024-02-08T19:15:29Z

This PR has 12 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +7 -5
Percentile : 4.8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

sba923 · 2024-02-08T21:09:12Z

The Windows CI fails, I don't understand why....

iSazonov · 2024-02-09T03:57:49Z

Reopen to restart CIs.

pull-request-quantifier-deprecated · 2024-02-09T03:57:53Z

This PR has 12 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +7 -5
Percentile : 4.8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +3 -1
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

iSazonov · 2024-02-09T03:59:25Z

src/System.Management.Automation/engine/NativeCommandProcessor.cs

@@ -969,11 +969,13 @@ internal override void Complete()
                    }

                    const string errorId = nameof(CommandBaseStrings.ProgramExitedWithNonZeroCode);
+                    string hexFormatStr = Platform.IsWindows ? "0x{0:X8}" : "0x{0:X2}";


We prefer #if UNIX over runtime check.

sba923

Change made.

Note: the codebase contains a significant number of runtime tests e.g. if (Platform.IsWindows)...

pull-request-quantifier-deprecated · 2024-02-09T10:45:54Z

This PR has 20 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +13 -7
Percentile : 8%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -1
.cs : +9 -3
.resx : +1 -1
.ps1 : +2 -2

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

sba923 · 2024-02-09T16:18:59Z

This time the MacOS CI fails...

xtqqczze · 2024-02-15T09:53:02Z

@iSazonov FYI, since #16760 the JIT will turn Platform.IsWindows into a constant, e.g. sharplab.

sba923 · 2024-02-22T13:43:36Z

what can I do about this?

sba923 · 2024-03-29T08:28:06Z

What's still blocking this PR?

kilasuit · 2024-03-29T22:39:27Z

@sba923 this will get another review before being accepted - also please see the comment I made above about reverting that commit & rebasing from main

sba923 · 2024-05-25T04:20:34Z

What's still blocking this PR? I'll probably need help with that rebasing action...

xtqqczze · 2024-05-25T20:11:01Z

git fetch upstream && git reset --soft 6df380910 && git commit --amend -C HEAD && git rebase upstream/master && git push --force-with-lease

sba923 · 2024-06-08T17:06:45Z

Last CI run reports PowerShell-Windows-Packaging-CI — This check was skipped.

What should I do next?

sba923 · 2024-06-19T05:16:15Z

@daxian-dbw what's still blocking this PR? Is there anything I can / should do?

xtqqczze · 2024-06-23T15:13:09Z

@daxian-dbw @TravisEz13 @adityapatwardhan @anmenaga
All checks have passed, could you please review?

sba923 · 2024-07-07T08:06:00Z

🏓

sba923 · 2024-07-23T13:16:14Z

If I understand correctly, this is blocked because it hasn't been reviewed....

rkeithhill · 2024-09-21T23:10:36Z

@daxian-dbw Any chance you could review this? It's a pretty small & straightforward PR.

sba923 · 2025-06-18T05:27:55Z

@rkeithhill / @daxian-dbw is there anything I can / should do to unblock this?

iSazonov · 2025-07-31T03:19:19Z

/azp run

azure-pipelines · 2025-07-31T03:19:32Z

Azure Pipelines successfully started running 1 pipeline(s).

microsoft-github-policy-service · 2025-07-31T03:23:44Z

📣 Hey @@sba923, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

pull-request-quantifier-deprecated bot added the Extra Small label Jan 13, 2024

iSazonov reviewed Jan 13, 2024

View reviewed changes

microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Jan 22, 2024

rkeithhill self-requested a review February 5, 2024 19:37

rkeithhill added the WG-Reviewed A Working Group has reviewed this and made a recommendation label Feb 5, 2024

sba923 commented Feb 7, 2024

View reviewed changes

sba923 requested review from daxian-dbw, TravisEz13, adityapatwardhan and anmenaga as code owners February 7, 2024 11:23

rkeithhill reviewed Feb 8, 2024

View reviewed changes

iSazonov closed this Feb 9, 2024

microsoft-github-policy-service bot removed the Review - Needed The PR is being reviewed label Feb 9, 2024

iSazonov reopened this Feb 9, 2024

iSazonov reviewed Feb 9, 2024

View reviewed changes

sba923 commented Feb 9, 2024

View reviewed changes

microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Feb 22, 2024

Adding hex format for native command exit codes (PowerShell#19886)

b71fa59

sba923 force-pushed the master branch from 8b56bfd to b71fa59 Compare June 8, 2024 09:12

rkeithhill approved these changes Jun 24, 2024

View reviewed changes

SteveL-MSFT assigned daxian-dbw Jul 15, 2024

microsoft-github-policy-service bot removed the Review - Needed The PR is being reviewed label Jul 15, 2024

microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Jul 23, 2024

rkeithhill mentioned this pull request May 17, 2025

NativeCommandExitException should display "negative" exit codes in hex, not decimal #19886

Open

5 tasks

daxian-dbw approved these changes Jul 29, 2025

View reviewed changes

daxian-dbw closed this Jul 29, 2025

daxian-dbw reopened this Jul 29, 2025

daxian-dbw added CL-Engine Indicates that a PR should be marked as an engine change in the Change Log and removed Review - Needed The PR is being reviewed labels Jul 29, 2025

daxian-dbw approved these changes Jul 30, 2025

View reviewed changes

iSazonov approved these changes Jul 31, 2025

View reviewed changes

iSazonov changed the title ~~Adding hex format for native command exit codes (#19886)~~ Adding hex format for native command exit codes Jul 31, 2025

iSazonov merged commit a993992 into PowerShell:master Jul 31, 2025
39 of 42 checks passed

Adding hex format for native command exit codes #21067

Adding hex format for native command exit codes #21067

Uh oh!

Conversation

sba923 commented Jan 13, 2024

PR Summary

PR Context

PR Checklist

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkeithhill Feb 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 7, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

sba923 left a comment

Choose a reason for hiding this comment

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 7, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 8, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 8, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xtqqczze Mar 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 8, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

sba923 commented Feb 8, 2024

Uh oh!

iSazonov commented Feb 9, 2024

Uh oh!

rkeithhill Feb 5, 2024 •

edited

Loading

xtqqczze Mar 29, 2024 •

edited

Loading