You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've done short research about process substitution on windows.
So - theoretically - you can create named pipe, then create server for this pipe and voila, you have something simillar to unix pipes. But not quite the same!
Named pipes could be addressed via \.\pipe\NAME - but cli tool must explicitly support pipes, it's not direct replacement! Most tools CANNOT read from \.\pipe\
You can do trick - create symlink - ie.: c:\symlink - that point to \.\pipe\NAME. But first - it's not always possible without admin rights (depends on OS version I think). Second - named pipes ARE NOT same as unix pipes, you NEED to properly handle errors, if not - server and/or client will hang. And third - there was at least one serious attack using this scheme (symlink to pipe) so there is risk, that antiviruses will treat using such trick as very suspicious.
So imho implementation using named pipes is not good idea.
Only other option I see: just run command which is in process substitution syntax, capture it's output to file, and after command finishes - resume script with normal file. Plus info in docs, that on windows it works differently.
The text was updated successfully, but these errors were encountered:
Just so I understand, I assume that you want to replace fmt.Errorf("TODO: support process substitution on Windows") with a working implementation?
Windows support in the interpreter is best-effort, simply because that's generally the best we can do. I think using regular files would be good enough in many cases, so I would welcome a pull request.
Yes - I want to replace process substituion on windows with files. So command is executed, it's whole output is saved to temporary file and then we can "pipe" it into command, that uses substitution.
I'll try to implement this in following month and send pull request.
Hello!
I've done short research about process substitution on windows.
So - theoretically - you can create named pipe, then create server for this pipe and voila, you have something simillar to unix pipes. But not quite the same!
Named pipes could be addressed via \.\pipe\NAME - but cli tool must explicitly support pipes, it's not direct replacement! Most tools CANNOT read from \.\pipe\
You can do trick - create symlink - ie.: c:\symlink - that point to \.\pipe\NAME. But first - it's not always possible without admin rights (depends on OS version I think). Second - named pipes ARE NOT same as unix pipes, you NEED to properly handle errors, if not - server and/or client will hang. And third - there was at least one serious attack using this scheme (symlink to pipe) so there is risk, that antiviruses will treat using such trick as very suspicious.
So imho implementation using named pipes is not good idea.
Only other option I see: just run command which is in process substitution syntax, capture it's output to file, and after command finishes - resume script with normal file. Plus info in docs, that on windows it works differently.
The text was updated successfully, but these errors were encountered: