in reply to Re^2: system call windows
in thread system call windows

Besides that, Windows doesn't provide anything like the Unix execve(2) syscall accepting an array of arguments. Instead, if has functions as CreateProcess which take the full command line as a single argument. When perl runs a multi-argument system call, it has to quote and join the arguments into a single line.

Unfortunately, in Windows the command line parsing is handled by the application itself and so there isn't a unique and standard set of quoting rules as different language runtimes use slightly different sets of rules and so, there are corner cases where perl may fail to quote command arguments properly. That has security implications too.

See for instance How a Windows program splits its command line into individual arguments.

Note that I am not advocating against the use of using the multi-argument system and related builtins on Windows, just pointing out that things are not straightforward as when using them on Linux or UNIX systems.

Replies are listed 'Best First'.
Re^4: system call windows
by BrowserUk (Patriarch) on Mar 08, 2019 at 14:18 UTC
    Note that I am not advocating against the use of using the multi-argument system and related builtins on Windows,

    I never do it, because of the reasons you cite.

    And I never understood the predilection *nix people have for "avoiding the shell".

    It seems to me that all of the justifictions I've read -- the bad guys can replace the shell with their program, or insert their program earlier in the search path and variations thereof -- could equally be done to the program you ask the shell to run on your behalf.

    And if they can do either, your system is pretty much owned anyway.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]
      And I never understood the predilection *nix people have for "avoiding the shell". It seems to me that all of the justifictions I've read ... could equally be done to the program you ask the shell to run on your behalf.

      The major issue I see with it is interpolating user input into the shell command. If one uses fixed strings, or one makes sure that any variables interpolated into the command are always sanitized, then I have no problem with using the shell. The problem arises when people aren't aware of the potential security issues, do the escaping wrong, or when scripts start out with "safe" use of the shell but are later modified to accept different user input and the maintainer forgets to properly sanitize the inputs accordingly. Hence my usual advice to just avoid the shell in the first place, and only use it if one knows what one is doing.

[reply]
        Hence my usual advice to just avoid the shell

        Hm. Sounds a little like advising people to wear condoms at all times rather than just when appropriate.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]

In Section Seekers of Perl Wisdom