http://qs1969.pair.com?node_id=373430


in reply to Re: Testing <> for undefined
in thread Testing <> for undefined

When you invoke the perl interpreter (i.e. "perl") on the command line, and give it the name of a script file to load and execute, then any command-line args that follow the name of the script file are passed directly to the script as the contents of @ARGV. If nothing follows the name of the script file, then the script gets an empty @ARGV.

If the script file itself is treated by the shell/OS as an executable file, so that the name of the script file can be the first thing on the command line, the behavior is the same: any args following the name of the script file are provided to the script in @ARGV.

Of course, if the things that follow the script name happen to have special meaning to the shell, like a redirection operator (< or >), logic/process-control operator (& or vertical bar), or other things (depending on your shell), then the shell will do what it is supposed to do with such args before working out the strings to be passed to your script as @ARGV.

So in a command like  myscript.pl < my.input (or the version that uses "perl" at the beginning), the angle bracket and the arg after it are treated by the shell as things to be handled by the shell, and these are not passed on to the perl script's @ARGV. This is why, if your script is set up to accept args that contain such characters, you need to quote or escape them on the command line, so that the shell will pass them to the script verbatim rather than acting on them itself.

Replies are listed 'Best First'.
Re^3: Testing <> for undefined
by jdavidboyd (Friar) on Jul 12, 2004 at 13:32 UTC
    Ah, thank you very much.

    I hypothetically knew this, but I had never really internalized it.

    Thanks for the explanation!