Personally I avoid global_opt_spec and instead use a base class for all commands. Let's say my app is called MyApp, then I'll do it like this:

{
  package MyApp::Command; # abstract
  use strict;
  use App::Cmd::Setup-command;
  
  sub opt_spec {
    return (
      [ 'someopt'  => 'This is a global option' ],
    );
  }
  
  # you can also define any helper methods you like here
  # and all your commands will have easy access to them.
}

{
  package MyApp::Command::foo;
  use strict;
  use MyApp-command;
  
  sub opt_spec {
    my $self = shift;
    return (
      $self->SUPER::opt_spec(@_),
      [ 'otheropt'  => 'This is another option' ],
    );
  }
}
[download]

Hi tobyink,

thank you for the fast reply.

Am I right, that all these "base" options would show up as command options?

Do you know a way to solve my initial problem if I really want the distinction between global and command specific options?

Best regards
McA

Hi all,

I just found out, that calling script commands shows the global options. Only script help doesn't show them.

So, my initial question is answered by myself. Does this raise my reputation? ;-)

Best regards
McA