I wonder MSFT team denies its own policy of not increasing Engine :-) Why don't put the short function in AzCLI with a helper module to collect a feedback. Then we could put the function in Utility module for 7.3.

@iSazonov it's not just AzCLI, that's just the most recent example. I've hit this myself a few times and it's really hard to figure out what's going on as an end user as the native command doesn't expect exec not to work so you get incorrect error messages. In this case, I think it's a core cmdlet and expected of a shell on Unix systems.

I think it's a core cmdlet and expected of a shell on Unix systems.

@SteveL-MSFT I see the point and I approve the intention but I'm afraid we may fall back into a long commit series of adaptations, especially if there is an intention to backport.
I mean it would be nice to see "we have received positive feedbacks for our helper module from Azure users in a few months" before we include this in Engine.

What do we know popular scripts using the exec which we could test with the solution? I see only two references in the related issue.

Why not do the real system call execv on Unix platforms? We already have some code for that in src\PowerShell\Program.cs.

Also, why making this visible on Windows too? I know why you exposed it on Windows after seeing the tests. I doubt its usefulness on Windows 😕

Why not do the real system call execv on Unix platforms? We already have some code for that in src\PowerShell\Program.cs.

We call sh -l -c 'exec pwsh "$@"' there. But we could call an exec here.

I'm going to re-work this PR so that exec calls execv api and is, of course, limited to just non-Windows.

It occurs to me that there might be some insight that the dotnet folks may have on this. I'm thinking especially of open file handles (which are preserved through the exec ) - this could mean that some clean up that happens when a managed app exits won't happen. I'm fairly certain that exec will not look like a standard process end to dotnet, but not absolutely sure.

Also, since this is a PowerShell view of exec I would consider adding a parameter -Environment as a hashtable which would enable the use of execve

The actual implementation should be in our native library and we should be calling the API from that library rather than directly having the system call.

We also need to figure out what to do about the exec code in src/powershell/Program.cs shouldn't there be a single call here rather than a PInvoke here and one there?

@JamesWTruher over time, we probably want to get rid of our native library and move them all to P/Invoke or .NET API calls. This will make it easier for us to support new architectures and also support MSIL builds. As for the separate execv calls, we already have this pattern where we don't necessarily want different assemblies calling into other assemblies internal methods for the purpose of P/Invoke calls. In this case, the ConsoleHost code is specific to ConsoleHost for purpose of working as a login shell and this is something that could be used in EditorServices, for example.

I've also asked .NET team to review this.

I've also asked .NET team to review this.

They introduced new GeneratedDllImport attribute and it would be great if they reviewed PowerShell Native repo too - can we rid of the PowerShell Native now (after moving to .Net 7) or no?
Also .Net has System.Native.dll - have they plan to rid of it or could we benefit from it to replace PowerShell Native?

@iSazonov I thought I had opened an issue previously on moving away from PowerShell-Native, but I created this issue PowerShell/PowerShell-Native#76. I haven't looked to see what the effort would look like based on new .NET APIs that weren't available when PS Core 6 first needed this library.

with regard to eliminating the native library, there may be difficulties with some of the APIs. I know when I did the UnixStat work I needed to handle all the platform differences in returning the stat structure. The stat structure is different on Mac, Linux, and ARM - this would likely be problematic - i solved it in the native library by returning a CommonStat structure which smoothed over the rough edges of these differences.

The stat structure is different on Mac, Linux, and ARM - this would likely be problematic - i solved it in the native library by returning a CommonStat structure which smoothed over the rough edges of these differences.

It is great request for .Net team. I see their dll import generator works today for simple types but structs are under question.
Then historically we do condition compiling (with #if) because absence .Net API. As soon as this API appears, we remove these conditions.
GeneratedDllImport is intermediate solution. It allow to move workarounds and mappings to managed code like if Platform.IsMac -> p/invoke GetMacStat() -> remap Mac Stat struct to generic Stat struct.

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

Label      : Medium
Size       : +125 -2
Percentile : 45.4%

Total files changed: 6

Change summary by file extension:
.cs : +75 -1
.resx : +6 -0
.ps1 : +44 -1

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

🎉v7.3.0-preview.2 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

@PowerShell/powershell-maintainers
Although it is potentially unstable, it has had some bake time, and the functionality is behind and experimental feature.

Let's give this some bake time to verify that it is stable.

I have seen customers that implement exec as a cmdlet which this behavior could break. The maintainers are inclined not to backport this unless we have a compelling argument to backport to the last LTS.

@PowerShell/powershell-committee reviewed this. Given that this is an experimental feature in 7.3 and the risk of impact of an existing exec command, we do not recommend backporting this to 7.2 pending customer feedback that it blocks their adoption of 7.2 in the future.