in reply to Review of my script

Why so many print statements out there? I'd rather do like this:
sub Usage() { my $err = shift and select STDERR; print <<EOF; ------------------------------------------ -- Usage for the database backup script -- ------------------------------------------ --host Specify the host IP --engine Specify the database engine. This could be postgres or mysql. --password Give the password needed to connect with the database server --user Specify user to connect to the database server. The user must have permissions to connect to the database(s) --port If another port than the standard must be used to connect you co +uld specify this with the --port option EOF exit $err; }
It is more readable to my eyes.

Replies are listed 'Best First'.
Re^2: Review of my script
by Jackiejarvis (Novice) on May 15, 2013 at 08:54 UTC

    Thanks I put that in the script, I had never used that method.

Re^2: Review of my script
by Anonymous Monk on May 16, 2013 at 09:04 UTC

    FWIW, I never liked Usage messages on STDERR, and rarely find programs that do that

    exit code communicates error status well enough

    all printing Usage on STDERROR ever did for me is break paging, break  foo ... | pager

      When you type something like:

      find-junk | xargs rm -f

      ... and find-junk bails out with an error message, you don't want the error message piped to rm -f, do you?

      So a convention has arisen to provide usage instructions on STDERR if the program has been called incorrectly, but on STDOUT if the program has been called with an explicit --help.

      fisher's suggested code does precisely this. It only selects STDERR if $err is a true value.

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

        When you type something like

        That is a very specific case , I never do stuff like that (xargs + rm )

      Error messages should go to STDERR, Log to the log or STDERR if no log wanted/specified, and required/expected output to STDOUT.

      If you read that again, an expected usage message is something you want on STDOUT. e.g. when called with --help. My approach is always:

      sub usage { my $err = shift and select STDERR; print "usage: $0 [--options] ...\n"; exit $err; } # usage use Getopt::Long qw(:config bundling); my $opt_v = 0; GetOptions ( "help|?" => sub { usage (0); } # OK, STDOUT "v|verbose:1" => \$opt_v, "x|xfsgdft!" => \my $opt_x, ) or usage (1); # FAIL: STDERR

      As not all programmers are clean in that distinction, when I want help through a pager, I pipe STDOUT and STDERR together, which - in (t)csh is just a single extra character:

      > some_app --help |& less

      To return to the first point, when some script/app deals with lot of data, you absolutely want that separated! You want to see the analysis, and not store it between your data

      $ perl big_file.txt >excerpt.csv Opening file Analyzing columns Validating data Generating CSV 1 2 3 4 5 Done! $

      Imagine the validity of the generated file if the diagnostics were sent to STDOUT. And imagine the extra time it takes to wade through all the lines to find those messages.

      Enjoy, Have FUN! H.Merijn