Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Windows System Command

by Anonymous Monk
on Jun 26, 2012 at 21:14 UTC ( #978513=note: print w/replies, xml ) Need Help??

in reply to Windows System Command

I'm not an expert on cmd.exe, but I suspect your argument list is wrong. It should be:

system("C:\\Program\ Files\\HP\ Remote\ System\ Management\\hprsmcli", + "-s", "", "-u", "getinfo", "-p", "pass");

It would be really odd for this tool's command parser to expect "-u getinfo" in argv[2], "-p pass" in argv[3], etc. It is much more standard practice to have the switch (-p) and the value (pass) in different slots in argv.

Replies are listed 'Best First'.
Re^2: Windows System Command
by Ransom (Beadle) on Jun 27, 2012 at 12:55 UTC
    All that's required is that -p follows -u which follows -s. I've removed several other optional switches for this example. All these have been tested outside of perl. I find it really odd that arg slots would matter.
      I find it really odd that arg slots would matter.

      The Anonymonk is correct in that traditionally on *nix systems, command lines are broken up on whitespace and each whitepsce delimited token is passed to the process in a separate entry in the char *argv[] array.

      So, what you view as the (single) parameter -p pass, actually gets passed into the process as two separate strings in successive entries in argv[].

      However, all that is by the by on windows systems because Windows passes the entire command line to the process as a single string. Essentially, exactly as the user typed it with some obscure, minor exceptions.

      And traditionally on *nix, when passing parameters to system as a list, each item in the list is placed into a element of argv[] uninspected. Which means that if what you pass is; "-p pass" as a single item in the list, that is how the process will receive it. The trouble is, when the program processes that, it will see the '-p' in (say) argv[5], and then inspect the next item argv[6] looking for "pass" and not find it.

      But when you use the list form of system on Windows, the Perl runtime has to concatenate all the items together into a single string in order to pass it to the program being started. The Perl runtime makes some attempts to do this intelligently, but it often gets it wrong.

      Which is why I advocate not using the list form of system on Windows. It is usually much easier to cut an actually command line -- tested and known to work -- from a console session and paste it into q[].

      Of course, sometimes, some elements of the command line used are not constants and it becomes necessary to interpolate (or concatenate) them with the constant bits to form the command line. In that case, a little more effort is required.

      Using your example, say that user, pass and the IP needed to be derived from variables. I'd do it this way. I'd start by getting the command right on the command line:

      "C:\\Program\ Files\\HP\ Remote\ System\ Management\\hprsmcli" -s 143. +207.48.60 -u user -p pass

      Then I paste that into the program and quote the various bits individually and join then with spaces:

      system( join ' ', '"C:\\Program\ Files\\HP\ Remote\ System\ Management\\hprsmcli"', '-s', '', '-u', 'user', '-p', 'pass' );

      Note the use of single quotes, avoiding accidental interpolation and allowing the retention of the required double quotes around the program path without escaping.

      Having checked that it works with the parameters hardcoded, it then becomes a simple step to replace the constants with variables where applicable:

      system( join ' ', '"C:\\Program\ Files\\HP\ Remote\ System\ Management\\hprsmcli"', '-s', $ip, '-u', $user, '-p', $pass );

      Now, the only thing left to deal with is parameters that themselves can contain spaces, like filepaths. Example:

      system( join ' ', '"C:\\Program\ Files\\HP\ Remote\ System\ Management\\hprsmcli"', '-s', $ip, '-u', $user, '-p', $pass, '--log', qq["$logfile"] );

      Note: There are various other ways of quoting the path, including using backslashed quotes inside double quotes or using concatenation, but qq[] is what I find the clearest for this.

      For shorter commands, I would use qq[] alone when necessary:

      qq[ "c:\\perl 64\bin\perl.exe" -nle"/this/ and print" "..\some file wi +th spaces.txt" ];
      but that can get unweildy for long commands.

      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".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        Well I'm back in my place :) Thanks for this extended response. It's really helping my understanding of some of this underlying material.

        However, all that is by the by on windows systems because Windows passes the entire command line to the process as a single string.

        You know, as a *nix person, I found the function signature for CreateProcess shocking. "How is that better than fork()? It's not going to be easy to make it do anything similar!"

        (I was trying to write an IPC test program and had the bright idea of putting the two halves in the same .exe. Which would not be any problem whatsoever on *nix.)

        Ah well, WINAPI is strange and alien to me.

      I find it really odd that arg slots would matter.

      I know how to translate that :) "I didn't grok perldoc -f system"

        ++ ;)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://978513]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2018-05-21 15:36 GMT
Find Nodes?
    Voting Booth?