Ticket #1110 (closed defect: wontfix)

Opened 14 months ago

Last modified 14 months ago

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

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

Description

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

comment:1 Changed 14 months ago by gb

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

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 14 months 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 14 months ago by fare

  • Status changed from closed to reopened
  • Resolution notabug deleted

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

comment:4 Changed 14 months 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 14 months 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 14 months ago by gb

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

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.

So:

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

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 "command.com", 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.

Note: See TracTickets for help on using tickets.