-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exec and (very) long commands on Windows #2530
Comments
Similar proposal was discussed in #399 |
On Windows, the Exec task passes the command to cmd, so long commands run into the command length limit (see dotnet/msbuild#2530). This workaround shortens the xunit command line by replacing the path to the test binary directory with an environment variable.
On Windows, the Exec task passes the command to cmd, so long commands run into the command length limit (see dotnet/msbuild#2530). This workaround shortens the xunit command line by replacing the path to the test binary directory with an environment variable.
On Windows, the Exec task passes the command to cmd, so long commands run into the command length limit (see dotnet/msbuild#2530). This workaround shortens the xunit command line by replacing the path to the test binary directory with an environment variable.
Ping - Any chances for the fix or other action? |
On Windows, the Exec task passes the command to cmd, so long commands run into the command length limit (see dotnet/msbuild#2530). This workaround shortens the xunit command line by replacing the path to the test binary directory with an environment variable.
Isn't the limit due to Windows API itself instead of cmd.exe ? |
@rsaugier There are two distinct limits:
The |
On Windows, the Exec task passes the command to cmd, so long commands run into the command length limit (see dotnet/msbuild#2530). This workaround shortens the xunit command line by replacing the path to the test binary directory with an environment variable.
I've observed some problematic behavior when using the
Exec
task on Windows with a very long (~17000 characters) command string. There are a few points I've discovered:Exec
is documented as running throughcmd.exe
-- the command is not launched directly in a new process.cmd.exe
.Error behavior:
cmd.exe
has documented limits on command-line length. On relevant systems, the limit is 8191 characters.cmd /c <command>
, you get an error message:The command line is too long.
cmd /c <scriptfile>
, you get very misleading and dangerous behavior.It appears that cmd.exe will attempt to run a command in a script file which is over the length limit, but will silently remove individual characters at the command length boundary. In my case, characters 8192 and 16383 are being silently deleted from the command, but the rest of the command line is unchanged. I spent several hours debugging this behavior, because I thought something was wrong in my app code.
The current state (silent and confusing errors) seems undesirable. Can we do one or both of the following?
DirectExec
or something like that. This could be written by anyone, but it might be generally useful enough to include in MSBuild.Exec
itself?The text was updated successfully, but these errors were encountered: