http://qs321.pair.com?node_id=1033639


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;
}

[download]
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.

[reply]
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

[reply]
[d/l]

      When you type something like:

      find-junk | xargs rm -f

      [download]

      ... 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
[reply]
[d/l]
[select]

        When you type something like

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

[reply]

      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

      [download]

      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

      [download]

      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 foo.pl big_file.txt >excerpt.csv
Opening file …
Analyzing columns …
Validating data …
Generating CSV … 1 2 3 4 5
Done!
$

      [download]

      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
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom