Skip to content
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

Open
mellinoe opened this issue Sep 15, 2017 · 5 comments
Open

Exec and (very) long commands on Windows #2530

mellinoe opened this issue Sep 15, 2017 · 5 comments
Labels

Comments

@mellinoe
Copy link

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 through cmd.exe -- the command is not launched directly in a new process.
  • Additionally, the command itself is actually run through a batch script containing the command line and some extra commands. The script is launched via cmd.exe.

Error behavior:

  • cmd.exe has documented limits on command-line length. On relevant systems, the limit is 8191 characters.
  • When an extremely long command is run directly with cmd /c <command>, you get an error message: The command line is too long.
  • When an extremely long command is embedded in a script and run indirectly through 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?

  • Add an alternative task which launches processes directly: DirectExec or something like that. This could be written by anyone, but it might be generally useful enough to include in MSBuild.
    • Is it feasible for this to just be an option on Exec itself?
  • Error out when a command is too long on Windows. We should be able to detect if a string is over the 8191 limit. If we do, we should not try to execute it given the above behavior.
@mellinoe
Copy link
Author

@ericstj

@akoeplinger
Copy link
Member

Add an alternative task which launches processes directly: DirectExec or something like that.

Similar proposal was discussed in #399

sbomer added a commit to sbomer/coreclr that referenced this issue Jul 23, 2018
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.
sbomer added a commit to sbomer/coreclr that referenced this issue Jul 23, 2018
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.
sbomer added a commit to sbomer/coreclr that referenced this issue Jul 23, 2018
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.
@4creators
Copy link

Ping - Any chances for the fix or other action?

jashook pushed a commit to dotnet/coreclr that referenced this issue Jul 24, 2018
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.
@rsaugier
Copy link

rsaugier commented Aug 7, 2018

Isn't the limit due to Windows API itself instead of cmd.exe ?

@rainersigwald
Copy link
Member

@rsaugier There are two distinct limits:

The Exec task writes and then executes a .cmd script, so it's subject to the smaller limit; the changes discussed here would raise it to the higher limit.

jashook pushed a commit to jashook/coreclr that referenced this issue Aug 14, 2018
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.
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants