[Koha-devel] Conventions for CLI scripts

[Robin Sheat]

Mark Tompsett schreef op do 18-09-2014 om 09:29 [-0400]:
> not indicative of DB modifications. I suspect you are thinking about 
> checkNonIndexedBiblios.pl which only runs if you include -c, much like point 
> 1 subsection II. The name doesn't suggest default modifications. 

Well the solution to that is to fix the name. It's not checking, it's
modifying. To be fair, fsck (filesystem check) also modifies :)

> In this 
> case, you have to add the -z which will then insert the non-indexed Biblios 
> into the zebra queue. This is like the second method. Can we have a mix? 
> Does a mix make any sense?

A mix sounds like the worst of both possible worlds. I don't have strong
opinions about it (though ceteris paribus would prefer having "commit"
by default), but it's the sort of case where consistency would be good.

> This kind of reminds me of the help for scripts issues I was wondering 
> about. I see a script name, other than reading the code, how do I get a 
> sample use page? Do we force help on users if no parameters are passed? Do 
> we expect a particular letter or 
> phrase? --help -h --usage --examples --something-else? 
> checkNonIndexedBiblios.pl does it both ways.

If a script requires arguments in order to do its function, then it
should present with a help synopsis. If it doesn't, then it might go
forth and do its thing. This is the UNIX way.

If you want help, you use -h or --help. This is the GNU way, which is
mostly the POSIX way, which is mostly the UNIX way. I also tend to use
--man for providing the full manual, but I'm not sure where I got that
idea from.

--version is also more or less a GNU requirement, but it's perhaps not
so important for us.

> 
> 
> >     2. What do we want to call the options, whichever way is picked?
> >             I. Keeping in mind that some things (-c for example) can
> >                conflict with other conventions.
> 
> Are there different conventions to choose from? How does Debian (Ubuntu, 
> etc.) do it?

I did a bit of pottering around, and while there are many different
things, the most common I saw was -c for config file. So it'd probably
be best to avoid that. Other things are fair game (except --help and
--version I guess.)

My suggestion is that we use --dry-run|-d if we have an option to
activate that mode, or --run|-r if we require an option to commit
changes.

Note that no matter what is decided, the
"delete_everything_and_burn_it_all_down" script should require a
parameter to commit changes. Perhaps '--screw-it-lets-do-it-live'. 

> >        $dbi->begin_work;
> 
> Actually, I guess that is a nicer way of doing this?
> 
> # Start transaction
> $dbh->{AutoCommit} = 0;
> $dbh->{RaiseError} = 1;

It wasn't really a complete example. RaiseError should always be 1
unless you have a reason, I think starting a transaction turns off
AutoCommit for the duration of the transaction anyway.

-- 
Robin Sheat
Catalyst IT Ltd.
✆ +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140919/764862af/attachment.pgp>