Actually you should check that the argument is defined instead of its truth, you can do either:
my $in1 = defined $ARGV[0] ? $ARGV[0] : ''; or my $in1 = $ARGV[0] // '';, I personally prefer to check that the number of arguments is correct first : my $in = (@ARGV > 0) ? shift : ''; (actually I often check the number of arguments first, so that I can ouput a warning when needed)
Note that after this point, $in1 will always be defined, because an undefined value will be replaced by the empty string (but 0 will be kept as is, and not turned to the empty string as in your code).

I don't know what you do exactly of your input, but I'm not sure you actually need the empty string when your argument is invalid, undef seems to be what you expect. There's of course more than one way to do it, so feel free to adapt this to your needs with a ternary operator, statment modifier or whatever will make this look better to you:

my $input = undef;
if (@ARGV > 0 && $ARGV[0] !~ /\D/)
{
  $input = shift;
}
[download]

Edit: s/expecy/expect/ as pointed out by MidLifeXis :)

Sorry I should have given more info.

The script takes 2 input arguments, both of which are numbers. The second argument is a time period in seconds so 0 will be an invalid choice.

The first input argument which is the one that CAN be 0 is later used in the script as part of a system command input option (-Dhw:$in1).

If by "number" you mean an integer device number, the following technique for getting a list of results for regex captures should help. It is documented among other places here: http://perldoc.perl.org/perlrequick.html#Extracting-matches

use warnings;
use strict;

my ($device) = defined($ARGV[0]) ? $ARGV[0] =~ /^\s*(\d+)\s*$/ : '';
print "Device #$device\n";
[download]

Ron

I know I can validate that the input argument was there via the following bit of code:

chomp(my $in1 = $ARGV[0] || '');
if (defined $in1) {
    #Validate;
}
[download]

Have you ever encountered a case where $in1 was not defined?

Maybe you want to directly check the number of arguments in @ARGV or look at what the || operator does?

Maybe the following code helps you analyze what happens better:

my $in1 = $ARGV[0] || 'user-did-not-pass-an-argument');
print $in1;
[download]

Run the above code with

perl -w myscript.pl # no argument
perl -w myscript.pl "" # empty argument
perl -w myscript.pl 0 # zero argument
perl -w myscript.pl something-else # other argument
[download]

Thanks for this. I just noticed I put "||" in my post instead of "//" which is what I have in my script. I know how they differ but thanks for pointing it out.

I have now figured out it was a combination of using the // operator and also chomp. The code now looks something like:

my $in1 = $ARGV[0];
chomp(my $in2 = $ARGV[1] // '');

if (defined $in1) {
   $in1 =~ s/\s+//g; # Remove all whitespace instead of chomp
   if ($in1 =~ /\D+/) {
      print "Input invalid. Only numbers are allowed\n";
   }
} else {
   print "No valid input given\n";
}
[download]

$in1 =~ s/\s+//g;

Although your comment suggests you are aware, I will still point out that s/\s+//g will remove all spaces, including spaces between digits/other characters, not just leading and trailing spaces.

While unlikely to be a problem with your program, it is still possible to feed an unexpected value:

yourprog "1 2"

would result in $in1 being 12 and $in2 being empty

This is why you should copy/paste code instead of retyping it in your post.

Both more accurate and faster as well! :)

I guess you want something like this:

#!/usr/bin/env perl

use strict;
use warnings;
use Getopt::Long;
use Pod::Usage;
use Data::Dump;

my %options;

# Getopt::Long::Configure("no_ignore_case"); # perhaps you need it...

GetOptions( \%options, "device=i" );

pod2usage( -exitstatus => 0, -verbose => 2 ) unless defined $options{d
+evice};

dd \%options;

# stuff...

__END__

=pod

=head1 USAGE

Something went wrong.

=cut
[download]

Please see also Re: throw a warning if no argument were passed, Re: GetOpt Organization and Getopt::Long

Regards, Karl

use strict;
use warnings;
# More Realistic values are required for these constants.
my $VALID_DATE_FORMAT = qr{\d\d/\d\d/\d\d\d\d};
my $MAX_DEVICE_NUMBER = 17;

if (!@ARGV or @ARGV>2){
    die "Usage:...\n";
}

my ($device, $date) = @ARGV;
$device =~ s/\s//g;
$date //= q();

if ($device =~ m/\D/ or $device < 0  or  $device > $MAX_DEVICE_NUMBER)
+{
    warn "Invalid device number - Must be an integer < $MAX_DEVICE_NUM
+BER\n";
}
if ($date and $date !~ /$VALID_DATE_FORMAT/) {
    warn "Invalid date - Must be mm/dd/yyyy\n";
}
print "device: $device\ndate: $date\n";
[download]

use strict;
use warnings;
my $foo;
my $bar = 0;
my $baz = '0';
for my $arg ( $baz, $bar, $foo ){
    use Data::Dump;
    dd( $arg );
    print qq{ the $arg\n };
}
__END__
0
 the 0
 0
 the 0
 undef
Use of uninitialized value $arg in concatenation (.) or string at - li
+ne 9.
 the
[download]

So there you have it 0 is a perlnumber, your problem is that you don't have 0, you have under

Your problem is the part that says:   || ''.

In a test for truthiness, zero is False.   As demonstrated by these two one-liners:

perl -e 'my $foo="0"; print "\""; print ($foo || "X"); print "\" is th
+e word.\n";'
"X" is the word.

perl -e 'my $foo=0; print "\""; print ($foo || "X"); print "\" is the 
+word.\n";'
"X" is the word.
[download]

Just to make the foregoing abundantly clear:   the difference between the two examples is that, in the first, $foo is a string, while in the second, it is integer.   Perl silently performs the data-type conversion, regarding both as “zero.”   In both cases, Perl concludes that the value, being zero, is False.   Therefore, the expression ($foo || "X") evaluates to its right-hand side:   “X.”   Which is definitely not what you wanted.

I agree that you should be testing the number of arguments first, and die()ing with a message to the effect that the number is incorrect.   Then, if necessary, test the arguments against a regex pattern to be certain that each consists of one-or-more digits, giving another (different) message if this is not the case.   Do not test arguments for “truthiness” because, as you just found out, this relies on what the values actually are.   (Also do not rely on exists, because that does not care what they actually are.)

Several years from now, your successor’s successor’s successor ... who is trying to debug a process of which your script is a tiny part (until s/he, too, can get-the-hell out of there) ... will thank you for your diligence and attention to detail.   ;-)