RE: [Boost-Users] Re: command line parsing
I wrote:
That is correct. Windows programs receive given a single string of arguments to parse whereas Unix programs receive a vector which can be passed to main unchanged by the startup code. ... A full solution will need to be a little bit more complicated. There isn't a specification of how Windows command-lines should be generated or interpreted from an array of strings...
What I should have written is: Windows programs receive a single string of arguments to parse whereas Unix programs receive an array which can be passed to main unchanged by the startup code. ... A full solution will need to be a little bit more complicated. There isn't a specification of how Windows command-lines should be converted to or from an array of strings... By the way, the startup code or other command-line parser does not have to handle redirection or variable substitution; this *is* done by the command processor (which implies that it does parse the command- line, even though it doesn't give you the results of this).
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window don't remember which is which, but one gives just the executable name, one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all. Also, I _distinctly_ remember something very whacky when I used unicode, I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth. //
E. Scott Larsen wrote:
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
don't remember which is which, but one gives just the executable name, one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all.
The latter case is disturbing. If the program name is not passed, it will be hard to skip the first argv element. Does it ever happens when you have non-empty set of options?
Also, I _distinctly_ remember something very whacky when I used unicode, I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth.
In fact, I'm not sure how to handle Unicode at all. - Volodya
Vladimir Prus wrote:
E. Scott Larsen wrote:
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
don't remember which is which, but one gives just the executable name, one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all.
The latter case is disturbing. If the program name is not passed, it will be hard to skip the first argv element. Does it ever happens when you have non-empty set of options?
I don't remember (I don't currently use command line parameters, nor winmain, or I'd just generate some specific cases for you). I do remember that figuring out how to skip the exectuable name was a big trick (that app was always using a non-empty set of options, never tried it with an empty set), and it seams like there was more than a couple variations. Sorry I don't have the code or remember the details. I'm all on unix now, so I can't run some tests to find out. If nobody has a way to test or wants to fill in the details, then I wouldn't worry about it, as that implies that there's no demand for a solution! But if someone wants a solution, they should be able to quickly generate some specific cases. I wasn't intending to generate a problem where there was not demand for a solution, I was just FYI'n from my memory. _I_ say you've done outstanding work already and have enough you'd love to do instead of solving a problem that doesn't need to be solved. Sure, if someone wants to pitch in with the specifics and would like a solution, then you'd have some specifics and something to work off of. //Scott
Also, I _distinctly_ remember something very whacky when I used unicode, I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth.
In fact, I'm not sure how to handle Unicode at all.
- Volodya
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Vladimir Prus wrote:
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
don't remember which is which, but one gives just the executable name, one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all.
The latter case is disturbing. If the program name is not passed, it will be hard to skip the first argv element. Does it ever happens when you have non-empty set of options?
Also, I _distinctly_ remember something very whacky when I used unicode, I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth.
In fact, I'm not sure how to handle Unicode at all.
You may have a look at the MS runtime library sources, which are bundled with the development environments. Regards Hartmut
participants (4)
-
Ben Hutchings -
E. Scott Larsen -
HartmutKaiser＠t-online.de -
Vladimir Prus