Change Details

At the time of writing, `arc` does not escape all inputs to command line functions correctly on Windows. That is, for a snippet like this: ```lang=php list($stdout) = execx('echo -n %s', $input); ``` ..there is a set of possible values for `$input` where the code will execute without errors but `$stdout` and `$input` will have different values at the end of execution. Some examples of such input are: ``` %APPDATA% \0 ``` --- As an aside, this is also true on Linux systems (the code can execute without errors but the input and output may differ), because there does not appear to be any way to make `echo` echo the string `-n`, at least on OS X: ``` $ echo -n $ echo -n -n $ echo -n -- -n -- -n ``` For the purposes of this discussion, assume `echo` is a platonic ideal of `echo` which can truly echo any string. --- For prior discussion, see T8298 and connected tasks. This discussion is extensive and meandering, but roughly summarizes as: - no one really has any idea how to escape things on Windows; and - it appears to be impossible to escape a large set of inputs on Windows. --- **Environments** Part of the reason this is difficult is that Windows is not a single shell environment, but at least three: `cmd.exe`, MSYS, and Git Bash. (We may, today or in the future, also need to deal with Powershell.) The three shells have different behavior, with `cmd.exe` generally having the most absurd behavior. I currently believe that `cmd.exe`, at least, can not escape all inputs, and that the behavior of `csprintf()` under `cmd.exe` must sometimes be to throw an exception saying "this input can not be escaped, use a different input (or use Git Bash)". This is wholly absurd, but at least an improvement over the current behavior.

At the time of writing, `arc` does not escape all inputs to command line functions correctly on Windows. That is, for a snippet like this: ```lang=php list($stdout) = execx('echo -n %s', $input); ``` ..there is a set of possible values for `$input` where the code will execute without errors but `$stdout` and `$input` will have different values at the end of execution. Some examples of such input are: ``` %APPDATA% \0 ``` --- As an aside, this is also true on Linux systems (the code can execute without errors but the input and output may differ), because there does not appear to be any way to make `echo` echo the string `-n`, at least on OS X: ``` $ echo -n $ echo -n -n $ echo -n -- -n -- -n ``` For the purposes of this discussion, assume `echo` is a platonic ideal of `echo` which can truly echo any string. --- For prior discussion, see T8298 and connected tasks. This discussion is extensive and meandering, but roughly summarizes as: - no one really has any idea how to escape things on Windows; and - it appears to be impossible to escape a large set of inputs on Windows. --- **Environments** Part of the reason this is difficult is that Windows is not a single shell environment, but at least three: `cmd.exe`, MSYS, and Git Bash. (We may, today or in the future, also need to deal with Powershell.) The three shells have different behavior, with `cmd.exe` generally having the most absurd behavior. I currently believe that `cmd.exe`, at least, can not escape all inputs, and that the behavior of `csprintf()` under `cmd.exe` must sometimes be to throw an exception saying "this input can not be escaped, use a different input (or use Git Bash / some other shell / some obscure workaround)". This is wholly absurd, but at least an improvement over the current behavior. **Executables vs Arguments** Windows escaping behavior in at least some shells appears to be different for the first argument (the binary/executable) than for other arguments. This may require separate escaping behavior. **Bypass Shell** Under Windows, `proc_open()` in PHP has a `bypass_shell` mode. It is broadly unclear what this option actually does or how it affects command escaping.

At the time of writing, `arc` does not escape all inputs to command line functions correctly on Windows. That is, for a snippet like this: ```lang=php list($stdout) = execx('echo -n %s', $input); ``` ..there is a set of possible values for `$input` where the code will execute without errors but `$stdout` and `$input` will have different values at the end of execution. Some examples of such input are: ``` %APPDATA% \0 ``` --- As an aside, this is also true on Linux systems (the code can execute without errors but the input and output may differ), because there does not appear to be any way to make `echo` echo the string `-n`, at least on OS X: ``` $ echo -n $ echo -n -n $ echo -n -- -n -- -n ``` For the purposes of this discussion, assume `echo` is a platonic ideal of `echo` which can truly echo any string. --- For prior discussion, see T8298 and connected tasks. This discussion is extensive and meandering, but roughly summarizes as: - no one really has any idea how to escape things on Windows; and - it appears to be impossible to escape a large set of inputs on Windows. --- **Environments** Part of the reason this is difficult is that Windows is not a single shell environment, but at least three: `cmd.exe`, MSYS, and Git Bash. (We may, today or in the future, also need to deal with Powershell.) The three shells have different behavior, with `cmd.exe` generally having the most absurd behavior. I currently believe that `cmd.exe`, at least, can not escape all inputs, and that the behavior of `csprintf()` under `cmd.exe` must sometimes be to throw an exception saying "this input can not be escaped, use a different input (or use Git Bash / some other shell / some obscure workaround)". This is wholly absurd, but at least an improvement over the current behavior. **Executables vs Arguments** Windows escaping behavior in at least some shells appears to be different for the first argument (the binary/executable) than for other arguments. This may require separate escaping behavior. **Bypass Shell** Under Windows, `proc_open()` in PHP has a `bypass_shell` mode. but at least an improvement over the current behaviorIt is broadly unclear what this option actually does or how it affects command escaping.