[Ohrrpgce] Windows Shell substitute

[Ralph Versteegen]

On 26 October 2010 06:45, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 26 October 2010 06:18, Mike <caron.mike at gmail.com> wrote:
>> I'm not at home at the moment, so I can't review the existing code. However, I should point out that command line parsing is the responsibility of the app. In practice, this is handled by the C/++ runtime being linked against.
>>
>> I can't speak for mingw's library, but in my experience, VC++ parses command lines like such:

Also, I don't think mingw includes a C library. It has C++ and Obj-C
runtime libraries, but I don't see libc anywhere. Mingw C executables
link to msvcrt.dll.

>> 1. Command line arguments are separated by spaces
>> 2. If an argument contains a space, it must be surrounded by quotes (you can't escape the space)
>> 3. Since quotes are illegal in paths, there's no reason not to quote all paths unconditionally.
>>
>> Cmd.exe, the command line processor, uses the caret (^) as an escape character (NOT backslash), but I do not think the VC++ runtime recognizes it.
>
> Really? Interesting.
>
>> My reccomendation (and, what I will do when I get home later) is to write a program that just lists its arguments and exits. If that shows as correct, but the other utilities still have problems, then its a bug in their end (unlikely as it is).
>
> No need, I figured out the problem 9 months ago, and told everyone
> here on the mailinglist. How could you forget! SHELL calls system()
> which calls cmd.exe, and cmd.exe has some bizarre rules for
> interpreting quotes in its command line which date back to some
> ancient version of MS-DOS.
>
>> Anyway, digression asside, the win32 equivalent to SHELL is... Shell. Or, preferredly, ShellEx. I can't imagine why SHELL wouldn't be a wrapper around it.
>>
>> If we opt to use it directly, it shouldn't be that big a change.
>> --
>> Mike Caron
>
> Oh, hey. Good idea. I can't actually find this Shell function in the
> WinAPI at the moment though, just in Visual Basic. The VB version
> sounds like exactly what we need: a function that does not wait for
> the program to finish, and preferably allows us to kill it if the user
> cancels.
>
>
> ....
> Argh, I just found another bug in MP3 import: I can't replace one
> imported MP3 file with another without first importing a different
> file format, including OGG, overtop first.
>