in reply to system() implementation on Windows (again)

Disclaimer: I don't have enough inside knowledge to answer your real question, nor do I have anything to prove my following notion.

What could also be the case is that msg.exe does its own command line argument parsing. On my machine (Windows XP, Dutch) I get this:

C:\>msg /?
Een bericht naar de gebruiker sturen.

MSG {gebruikersnaam | sessiennaam | sessie-ID | @bestandsnaam | *}
    [/SERVER:servernaam] [/TIME:seconds] [/V] [/W] [bericht]

[download]

Liberally translated, this says that msg.exe takes the following arguments:

  1. Either a user name, a session name, a session ID, a "@" + file name, or a "*"
  2. Optional /SERVER:, /TIME:, /V, and /W switches
  3. Optionally a message
I suspect that what happens here is that msg.exe looks at all arguments it gets, sees that there is a "/w" before the message1, and waits for user response.

1 Or, more precisely, that there is something that could be interpreted as a "/w" before the message, even though that wasn't the intended meaning.

Replies are listed 'Best First'.
Re^2: system() implementation on Windows (again)
by Anonymous Monk on Aug 18, 2011 at 13:03 UTC
    OK, I understand what you're saying. And it is an interesting observation, which I didn't take into account so far. On the other hand, I observed this behavior also with other executables. In fact, my actual problem is related to another (specific) program, and I used the msg.exe really just to have something simple to demonstrate the issue in a post in this forum. In particular, I noticed that double quotes characters inside one of the passed arguments can destroy the whole execution. Which makes me think, that there is "something" interpreting the arguments, instead of purely passing the argument string "as is" to the executable, at the desired argument position. Anyway, thanks for your feedback!
[reply]

      Which makes me think, that there is "something" interpreting the arguments, instead of purely passing the argument string "as is" to the executable, at the desired argument position.

      Yeah, its called 

      $ perl -V:sh
sh='cmd /x /c';

      [download]
[reply]
[d/l]
        Well... On a unix system it says: 
        $ perl -V:sh
sh='/bin/sh';

        [download]
        But that's exactly my point. This variable should not matter when using system() in the "argument array format". According to official perl documentation, when you use system() in the format: 
        system('command line with some args and special characters');

        [download]
        then this might involve calling a local shell. But when you call system() in the format: 
        system('executable', 'arg1', 'arg2', 'arg3');

        [download]
        then NO shell should be executed. Only the executable should be run getting the args as they are specified.

        As far as I know, on Unix the C-library function 'execv' gets called for this. And it works perfectly well. Even if any of the argN contains special characters or shell metacharacters.

        Now... I know that Windows is not Unix, and that on Windows there is no such thing as 'execv'. But even then, I would expect that something similar exists in the OS kernel, and that the Perl implementors (I mean: creators of Perl packages for Windows) are able to run the program, that I specify in the system() call, and pass it my arguments exactly as I specify them at their exact specified positions.

        So I'm wondering... Is system() implemented badly on windows ? Or is there really no way in Windows OS to achieve the same behaviour as on Unix (i.e. to make system() simply execute the executable and pass it a stack of arguments) ??

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom