Le 18/09/2014 03:51, Robin Sheat a écrit :
There's been talk of making a few conventions for the parameters to
command-line scripts.
(a little bit late answer...)
I've 2 strong opinions:
* if the script does something that can't be rolled back, there
*must* be a of validation. for example "delete_bibs_without_items.pl"
must not delete anything without warning. This warning can be something
like "you're about to delete 100000 bibliographic records. Are you sure
Y/N", unless the script is run with a parameter
(delete_bibs_without_items.pl -y)
* we must choose an option, and make it valid for all scripts.
Outside from those 2 things, I've no preference. I tend to be on Owen
side : no parameter = small help -ie: explicit parameter needed to run
the script)
Additional question: some CLI are made for being run from cron. In this
case, no information should be printed unless something goes wrong. SO:
by default, should scripts be silent:
* no parameters = silent mode
* -v = some informations
* -vv (or -v 2, or --very-verbose, I don't care ;-) ) = verbose mode
or should there be an explicit "silent mode":
* -s parameter = silent mode
* no parameter = some informations
* -v = verbose mode
something for a future technical meeting and improved coding guidelines ?
The initial discussion was dealing with "test mode" where it runs
through all the actions but doesn't actually do anything, i.e. you know
if it'll complete successfully.
1. There are two directions for this:
I. By default the action will be performed, unless you add
an argument (--dry-run for example.)
II. By default the action will not be performed, unless you
add an argument (--commit for example.)
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.
3. Are there any other conventions we should deal with at the same
time?
While I have your attention, we should be more careful about how the dry
run stuff is actually done. I've found one script that gives you a
different count if you're in dry run mode (e.g. it'll say "0 actions
done") which is strictly correct, but means you don't know if it's 0
because something's wrong, or because it's in dry run mode. Unless
there's a good reason, it's best to do everything in a commit, so
something like:
$dbi->begin_work;
...do stuff...
print "$count actions done.\n";
if ($dry_run) {
$dbi->rollback;
print "Changes NOT committed.\n";
} else {
$dbi->commit;
}
This also has the side effect that if your program crashes in any mode,
you're not left with an inconsistent result. But mostly it means
that /everything/ will happen in exactly the same way no matter what,
except the results just won't be saved.
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
--
Paul Poulain, Associé-gérant / co-owner
BibLibre, expert du logiciel libre pour les bibliothèques
BibLibre, Open Source software for libraries expert
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
