if (@ARGV) {
  # you have command line args
} else {
  # ya don't!
}
[download]

Your best bet is to put input into a variable, and test from here. That avoids icky little "but I didn't mean to read twice!" bugs. Also, direct comparisons are going to be problematic unless you remove the trailing newline that comes with the input. E.g.,

  my $input = <>;
  chomp($input);   # remove trailing \n
  if ( $input eq "" ) { ... }
[download]

But none of that helps when you need to be looking at @ARGV instead.

You don't want to test the diamond operator, you want to test whether any command line arguments were supplied:

if ( @ARGV == 0 )
{
   print "Something useful\n";
}
[download]

/J\

If you get a line from a file and test it as in your examples, you will no longer have that line to play with. You want to fetch it into a variable and then do your tests, etc.

Assuming the scriptname is called file_parse.pl, and you're trying to pass it single file only:

if ($#ARGV != 0) {
   print "Usage: file_parse.pl [filename] \n";
   exit(1);
}
[download]

This code scares me. If you want to see if there is one argument, use @ARGV in a scalar context, comparing it to one. I could easily imagine people reading this code and not remembering that $#ARGV is one less than the number of arguments, and being very confused.

My rule is, use @ARGV when you want to talk about the number of elements, and reserve $#ARGV for getting the ending index for ranges.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

My rule is, use @ARGV when you want to talk about the number of elements, and reserve $#ARGV for getting the ending index for ranges.

Thanks, merlyn... It's one of those things I learned to do one way when I was first learning Perl, and have never gone back and revisted it...

There's just so few things I can help people with in Perl, that I get excited when I see one I *can* answer :) Guess I'm destined to remain an acolyte for the foreseeable future :)

I'll make a note for future development

Trek

# Test if the is an argument
if(!@ARGV)
        {
        die "My help message\n";
        }

# Test if the argument is a file
if(! -e $ARGV[0])
        {
        print "File $ARGV[0] does not exist\n";
        }
[download]

Edited by Chady -- code tags, escaped a [

# Test if the is an argument 

if(!@ARGV) 
   { 
   die "My help message\n"; 
   } 

# Test if the argument is a file 
if(! -e $ARGV[0]) 
   { 
   print "File $ARGV0 does not exist\n"; 
   }
[download]

I have done this in the past, and it seems to work fine:

my $file = $ARGV[0] ? $ARGV[0] : die "USAGE:  prog.pl file_pathname\n";
open(FILE,"$file") or die "Unable to open file $file\n";

I have to say that I hate your use of the trinary operator there. You're expressing that you want to assign die's result to $file. Instead:

my $file = $ARGV[0] or die "Usage: prog.pl file_pathname\n";
[download]

(as a bonus, you don't have the redundant mention of $ARGV[0]).
Better, if the filename might be zero:

@ARGV or die "Usage: prog.pl file_pathname\n";
my $file = $ARGV[0];
[download]

---

We're not really tightening our belts, it just feels that way because we're getting fatter.

 # name one file:
  my_script.pl  input.file

 # name multiple files:
  my_script.pl  first.file  second.file  ...

 # use redirection from a file to STDIN:
  my_script.pl < some.file

 # use a pipeline to STDIN:
  other_process  |  my_script.pl
    # e.g.:
  cat *.file | my_script.pl
[download]

(The default behavior does not let you do both: if files are named as args, the plain, empty diamond operator reads the files and does not read STDIN.)

Anyway, the reason why you have to check @ARGV first, and not test the diamond operator, is that when @ARGV is empty, the script will wait until there is either input data (i.e. one whole line) or an EOF condition on STDIN, and you won't be able to check the result of the diamond operator until one of those things happens.

#!/usr/bin/perl

my $lines;
my @lines;

print ("\@ARGV: @ARGV, \$\#ARGV: $#ARGV\n");

if (!@ARGV){
   print("No command line parameters present");
}

chomp(@lines = <>);

foreach $lines (@lines){
   print("$lines\n");
}
[download]

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.

Ah, thank you very much.

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

Thanks for the explanation!