Opened 8 years ago

Closed 8 years ago

Last modified 4 years ago

#1110 closed defect (wontfix)

CCL on Windows outputs an extra space at the end of commands

Reported by: fare Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:


We found this bug while testing asdf's run-program. This notably matter when invoking CMD.EXE:

? (ccl::make-windows-command-line '("echo" "ok" "1"))
"echo ok 1 " ;; instead of "echo ok 1"

The problem is that due to the time when you shorten the list of string, the test (when strings ...) around printing the space should instead be (when (cdr strings) ...).

PS: you may or may not want to M-x delete-trailing-whitespace and/or have a svn hook that ensures you don't have such whitespace.

Change History (7)

comment:1 Changed 8 years ago by gb

  • Resolution set to notabug
  • Status changed from new to closed

Is there some reason to care whether a string that's intended to be processed as a Windows command line contains a trailing space or not, other than the fact that some ASDF test expects it not to ? E.g., does this affect how a program will parse that string into a C argument vector ?

Please provide an example of a C program that cares (creates its main() function's argv differently) about whether or not the command-line string it receives contains trailing whitespace, or whether the string contains sequences of whitespace characters where ASDF's test suite expects only one such character to exist, or tab characters where ASDF's test suite expects spaces, or anything that would make anyone care about what ASDF's test suite expects.

In the absence of such a program, I can't really care about this and don't see a bug here.

comment:2 Changed 8 years ago by fare

Yes, there is reason to care. As mentioned in the original bug report, CMD.EXE notably doesn't interpret its command line according to the standard C++ stdlib parsing, and if you "cmd /c echo ok 1 " it will print the last space, unlike "cmd /c echo ok 1"

comment:3 Changed 8 years ago by fare

  • Resolution notabug deleted
  • Status changed from closed to reopened

Reopening. This is a real bug, not a cosmetic issue. It does break valid code.

comment:4 Changed 8 years ago by fare

Actually, the existence of programs, such as CMD, that do not parse their command line with the standard C++ parser is a good reason why other implementations provide direct access to this command-line rather than (and/or in addition to) a list of strings. It would be nice if CCL did the same.

comment:5 Changed 8 years ago by fare

And yes, BTW, CMD.EXE is not a crazy marginal program that no one cares about, but the standard command interpreter of Windows. Though recent versions (starting with Windows 7) admittedly now also ship with powershell.exe — still it'd be nice to be able to invoke CMD properly.

comment:6 Changed 8 years ago by gb

  • Resolution set to wontfix
  • Status changed from reopened to closed

I thought that the fact that (on Windows) you can pass CCL:RUN-PROGRAM a string (instead of a list of strings that happens to be processed by CCL::MAKE-WINDOWS-COMMAND-LINE) was documented or at least mentioned in the release notes; it apparently isn't.


? (with-output-to-string (s)(run-program "cmd.exe" "/c echo ok 1" :output s))
"ok 1
? (count #\space *)

I checked in a change that doesn't output a trailing space. Beyond this, I don't care. It's 2013: if people are really calling "cmd.exe" (which is a slightly warmed-over version of "", which is the MS-DOS command interpreter) and no one has better things to do than to worry about what happens if they do, that would be a very sad state of affairs.

This is a huge waste of time; it won't waste any more of mine.

comment:7 Changed 4 years ago by rme

  • Milestone Clozure CL 1.10 deleted

Milestone Clozure CL 1.10 deleted

Note: See TracTickets for help on using tickets.