Hi all,
I want to use a user command to post-process the axf file. I enclose the command in quotes to preserve spaces in the path. However, if I also use quotes to enclose parameters in quotes, then the external command does not get called. If I don't enclose the parameters in quotes, the external command is called but the parameter is not parsed correctly.
As an example, a batch file called test_cmd.bat:
echo Parameter 1 = %1 echo Parameter 2 = %2
If I call this using
"C:\nXDS\nXDS Interface Processor\Application\Release\test_cmd.bat" #L
I get
User command #2: "C:\nXDS\nXDS Interface Processor\Application\Release\test_cmd.bat" C:/nXDS/nXDS Interface Processor/Application/Release/Obj/nXDS.axf C:\nXDS\nXDS Interface Processor\Application>echo Parameter 1 = C:/nXDS/nXDS Parameter 1 = C:/nXDS/nXDS C:\nXDS\nXDS Interface Processor\Application>echo Parameter 2 = Interface Parameter 2 = Interface ".\Release\Obj\nXDS.axf" - 0 Error(s), 0 Warning(s).
The batch file is called but the parameter is split by the spaces.
If I call using
"C:\nXDS\nXDS Interface Processor\Application\Release\test_cmd.bat" "#L"
User command #2: "C:\nXDS\nXDS Interface Processor\Application\Release\test_cmd.bat" "C:/nXDS/nXDS Interface Processor/Application/Release/Obj/nXDS.axf" --- Error: User Command terminated, Exit-Code = 1 ".\Release\Obj\nXDS.axf" - 1 Error(s), 0 Warning(s).
The batch file does not appear to have been called when both the command and parameter are in quotes.
Apart from the obvious workaround of not using a path containing spaces, is there any solution for this problem?
Regards
The essence of the reply is: Don't do that, then
The "that" in question here is "store stuff in paths that contain blanks". Nor any other funny characters, for that matter. It just doesn't work in the long run.
It took Microsoft in their infinite "wisdom" only about one decade to finally revert their position of trying to ram down everybody's throat the entirely, obviously gratuitous choice for "c:\Documents and Settings". The only aspect of that choice that ever made the least bit of sense (as perverted as it is) was that it forced every Windows programmer to try and support blanks in paths. Most eventually succeeded to some more or less sufficient extent.
Only then, after had finally gotten on everybody's nerves enough, did Microsoft finally switch back to what would obviously have been the right choice all along: "c:\Users". Mission accomplished, apparently.
Yes, it is!
Note that, if you right-click 'My Documents' and choose 'Properties', there is a 'Move...' button which lets you move its location - eg, to somewhere without spaces.
Well, there is in XP, at least.
Windows has an alternative short name for MS-DOS programs that can't make use of names outside the normal 8.3 limitation. Not sure if it is still supported - Win7 doesn't have "command" anymore to switch to a "real" MS-DOS prompt.
But another thing about spaces is that you can use backslash+space ("\ ") to allow a path to contain a space without needing quotes around the path.
Well yes, but having said all that, the fact remains that spaces are allowed in filenames under Windows, and have been for a while.
It doesn't seem unreasonable that software designed to run on a particular OS should support the features of that OS. Certainly for the application software I write customers expect that they can use spaces in filenames.
I think this is a simple bug in the Keil IDE that could be fixed.
<QUOTE>Win7 doesn't have "command" anymore to switch to a "real" MS-DOS prompt"</QUOTE>
it does not do command but it does do cmd
same like nt4, 2000, vista
it is not real mode
it is a command line prompt
always yo're freind
Zeusti.
"the fact remains that spaces are allowed in filenames under Windows"
And the fact remains that this is and always has been the bane of software development tools - and anything else that relies on command-line utilities.
Filenames with spaces are fine for pointy-clicky GUIs, but a pain for development work.
As noted, I agree that there's a bug in uVision - whether it's "simple" or not is another matter...
And, as noted, it's been there for a long time.
And, even if you get Keil to fix this, you will still be laying a trap for yourself with some other utility or tool...
So, again, the only sensible approach is: Just Don't Do it!
I think just about every coding/development standard I've seen says, "don't have spaces in file or folder names"
"it does not do command but it does do cmd"
Yes, of course it does. But I wasn't talking about the newer "cmd" but about the "command.com" alternative.
The difference between the win32 application "cmd" (cmd.exe) and the 16-bit program "command" (command.com) is important for this discussion. The "command" prompt makes use of 8.3-based file and directory names, which can be valuable if you need to quickly jump around on the hard drive and find out suitable path names to use for some ancient win16 or MS-DOS program.
I never bothered with Vista, but command.com was available at least up to Win XP, in which case "c:\Documents and Settings\" would become "C:\DOCUME~1\" for compatibility.
<QUOTE>The "command" prompt makes use of 8.3-based file and directory names, which can be valuable if you need to quickly jump around on the hard drive and find out suitable path names to use for some ancient win16 or MS-DOS program.</QUOTE>
have you ever tried opening cmd.exe and typing:
dir /X
???
you can type in the short name as a parameter too
works in win7
Win7 doesn't have "command" anymore to switch to a "real" MS-DOS prompt.
Not so. Win7 32-bit still has it. Only 64-bit versions of Windows don't have it --- and that's because the hardware doesn't support 16-bit programs in the CPU mode 64-bit Windows needs to be in.
But ultimately, that's beside the point. The real problem is that Microsoft's command line shells all suck at handling blanks inside command line arguments. cmd.exe (as of W2K) doesn't suck nearly as badly as command.com, but it's still nowhere near sufficient.
No, you can't. Not in command lines to be passed through any Microsoft command shell, anyway. No windows program has the slightest chance to know whether a command line of
PROGRAM.exe A\ B\C.txt
is supposed to mean that there's one file argument called "C.txt" in directory "A B", or two argument, one of which is "A\", and the other a file called "C.txt" in directory "B".
The only way to quote a blank in a command line (as opposed to the argv[] array passed to a Windows process creation API call) is by enclosing it in quotes.
So no one has any actual fix?
It specifically says in the uVision documentation, if you have spaces in the path, enclose the parameters in quotes. It should work, but it doesn't. Works on every other toolset I've used.
Perhaps the sensible advice is "just don't use buggy IDEs".
As I said before - No!
"Perhaps the sensible advice is 'just don't use buggy IDEs'"
Again, this is (I think) a uVision bug - but even if the bug were fixed, the basic problem of spaces in pathnames would still be there.
That's probably why the bug is still there after all this time - it's not worth fixing because it really is better to just avoid the issue in the first place.
Similarly, that'll be why nobody has a "solution" - they just avoid creating the problem!