The first time you use $day is to do a numeric comparison. But you haven't yet made _sure_ that the value is a number. Perhaps you could check first, by doing something like:
if( $days =~ m/^\d+$/ ) {
~ ~ all your code that depends on $days being numeric
} else {
~ ~ print nicely nasty message about bad input
}
| [reply]
[d/l] |
Can you explain to me what the translation of m/^\d+$/ ) means? I am totally new to perl and I have read about the m/ to some degree.
| [reply] |
Okay, but first, the others are correct in having you check for your 'q' quit action first.
The '^' character says start matching from the very first character in the string. This is called an 'anchor', because you're saying the match starts at a specific place.
The '\d' means match only number characters. The translation is '[0123456789]' also seen as '[0-9]'. There are many of these shortcuts and it is worth your while to learn them (see perlre doc).
The '+' means "one or more of the preceding". So we're saying there has to be at least one numeric digit and maybe more (but contiguous - nothing in-between).
And the '$' is like '^', an anchor, saying the match ends after the last character in the string. (There's a footnote about newline chars, but look that up later).
So altogether we're saying that the entire string (because of the '^' and '$' anchors) must contain only numeric characters and there must be at least one of those, and nothing else is allowed.
Other people have mentioned playing with '+' or '-' signs and that's reasonable. It gets into the topic "what do you think a number looks like?" I know there's good discussions in lots of books. I found a bit of one in perlretut under "Building a Regexp". There's probably others in the docs.
With REs it is only a question of "How much fun can you stand at any one time?" Learn just what you need at the time and keep adding on!
| [reply] |
Check out perldoc -q whole, or an online version. It contains a few other regular expressions, some of which may be more applicable to the problem at hand. It also mentions looks_like_number from Scalar::Util, which may be a nice alternative to regular expression checks.
| [reply]
[d/l]
[select] |
The while test on the value of days is made after the conversion to seconds is done so when you enter q you are trying to convert it to seconds. you could do a few things, here is one that keeps a while loop...
#!/usr/local/bin/perl -w
use strict;
while (1) {
print
"Please enter a single positive integer that represents a number of da
+ys, that you wish to convert into seconds. ,(enter q to quit): ";
chomp (my $days = <STDIN>);
$days =~ s/\+//; # allow them to enter +12
if ($days eq "q") {
last;
} elsif (($days =~ /[^\d]/) or ($days eq "")) {
# days contains an non digit character or is empty
print "\n!!! You must enter a positive integer.\n\n";
} else {
my $seconds = $days * 86400;
my $plural = ($days == 1) ? '' : 's';
print "\n$days day$plural = $seconds seconds.\n\n";
}
}
print "Goodbye\!\n\n";
update to catch entry of 0
Change the elsif check to this if you want to prevent them from entering zero days
} elsif (($days =~ /[^\d]/) or (not $days)) {
Cheers,
R. | [reply]
[d/l]
[select] |
Random_Walk,
A minor nit. If I've understood the code correctly, you've used a substitution...
$days = s/+//;
...where a transliteration would be "better"...
$days = tr/+//d; # Note transobliteration modifier
...and a lot faster (not that this is really an issue in this case.)Unless you wanted to allow only a leading + in which case...
$days = s/^+//;
Elgon
It is better wither to be silent, or to say things of more value than silence. Sooner throw a pearl at hazard than an idle or useless word; and do not say a little in many words, but a great deal in a few.
Pythagoras (582 BC - 507 BC)
| [reply]
[d/l]
[select] |
| [reply]
[d/l] |
Here's an alternative idea to simplify your code: instead of making the user type "q" to quit, they could either use "^C" to halt execution when they're done, or use the appropriate "eof" control character ("^Z" on windows, "^D" on unix), which will cause perl to "close" STDIN.
With that, the basic structure of the application could be done like this -- and I'll add an "extra feature":
use strict;
$| = 1; # turn off output buffering
if ( @ARGV and $ARGV[0] =~ /^\d+$/ and ! -f $ARGV[0] ) {
show_sec( @ARGV );
}
else {
while (<>) # read a line from STDIN (or from a named file)
{
chomp;
show_sec( $_ );
}
}
sub show_sec
{
for ( @_ ) {
if (/^\d+$/) {
my $sec = $_ * 86400;
my $s = ( $_ == 1 ) ? '':'s';
print "[$_] day$s = [$sec] seconds\n";
} else {
warn "$_ is not a positive integer; I'll ignore that.\n";
}
}
}
Let's suppose I call this script "d2s" (for "days to seconds"). If it's written like that, I can use it in any of the following ways:
- The same way you use your version: I run it with no command line args (just "d2s") and it works interactively: I type in one number at a time, but I don't see any prompts -- I just have to know what to do without being told every time -- and I finish by hitting ^C or ^D/^Z (eof).
- Putting one or more values for days on the command line (e.g. "d2s 1 3 4 6"): it immediately does the conversion on each element of @ARGV, and exits.
- Putting one or more data file names on the command line, where each file contains one or more values for days, one per line (e.g. "d2s list1 list2"): each file that exists is read in turn one line at a time, and for each line that is acceptable, a coversion is printed.
- Piping a stream of numbers, one per line, to the script (e.g. "grep '^[0-9]*$' list* | d2s"): just like running it interactively, except now STDIN is read from the upstream process, rather than being read from the keyboard. When the upstream process finishes its output, d2s sees this as "eof" and exits.
In all cases, each input string is always handled the same way: if it is a positive integer it is converted to seconds, otherwise it is ignored, with a message that says so. (0 days is converted to 0 seconds, which seems okay to me.)
The while (<>) loop provides all that flexibility. Also, when you use "warn" instead of "print" to deliver error messages about unusable input, those messages go to STDERR, so you can then redirect valid output (i.e. STDOUT) to a file to save the results for later re-use (e.g. "d2s > my_d2s.txt") -- there are many reasons for having the "good output" and "bad output" going to different file handles.
(Special note: the way @ARGV is handled there, if you have a data file called "12345" and give that name as the first arg, the script will read from that file, rather than using "12345" as a number to be converted. Basically, if the first arg is a number and is not a file, then all args are expected to be numbers to convert, otherwise they're all treated as files to be read.) | [reply]
[d/l]
[select] |
You could trap warnings for not numerics
use warnings;
my $days = 'oops';
eval {
local $SIG{__WARN__} = sub { die "not numeric" };
$days += 0;
};
if ($@) {
# at this point $days will be zero
# and $@ will be "not numeric"
}
| [reply]
[d/l] |
I tend to be lazy and just cast to an int when I want one. You could use a matching regex instead though.
#!/usr/bin/perl
use strict;
my $days;
do {
print "Enter a positive, non-zero integer ('q' to quit).\n> ";
$days = <STDIN>;
my $num = int $days;
if($num > 0) {
print "good '$num'\n";
} else {
print "'$num' is not > 0\n";
}
} while(! ($days =~ m/^q/) );
| [reply]
[d/l] |
