koha-* scripts revisited
Hi, I'm working on providing a bash-completion script for koha commands, so we have that handy tool for our commands. I'm doing this on a per-koha-script basis. For the task I'm revisiting each koha-* command to avoid messing with option switches combinations. I've already found some tiny problems (mostly poor error handling). There's an omnibus bug for rewriting those scripts and make them able to recover from errors and handle them gracefuly [1]. I'd like you to (1) tell me if its ok that I patch them in bash (which is what they are written in) and (2) if you have the time, discuss here the current and desired semantics for those commands, including the option switches. As of (1) I've already started working that way (provided patches for koha-list and koha-enable already[2]). But I will understand I "should have asked first". Looking for your helpfull response! (and possitive feedback on (1), no pressure heh). To+ [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4876 [2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10094 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10101
Hi, On Tue, Apr 23, 2013 at 8:24 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
I'm doing this on a per-koha-script basis. For the task I'm revisiting each koha-* command to avoid messing with option switches combinations. I've already found some tiny problems (mostly poor error handling).
Thanks for taking this on.
I'd like you to (1) tell me if its ok that I patch them in bash (which is what they are written in) and (2) if you have the time, discuss here the current and desired semantics for those commands, including the option switches.
bash is fine, unless they get so complicated that they would be easier to understand in Perl. :)
As of (1) I've already started working that way (provided patches for koha-list and koha-enable already[2]). But I will understand I "should have asked first".
That's fine -- a patch can serve as a nicely concrete way of asking a question. It's only an issue if the submitter *demands* that the answer is always going to be yes (i.e., that the patch is accepted and pushed).
[2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10094
What you propose for koha-list seems reasonable to me.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10101
Ditto for koha-enable. My biggest desideratum for these scripts is that koha-create be atomic -- in other words, that it either completely succeed, or if it fails, completely clean up after itself so that it can be re-run cleanly after the underlying problem is fixed. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Greetings,
My biggest desideratum for these scripts is that koha-create be atomic -- in other words, that it either completely succeed, or if it fails, completely clean up after itself so that it can be re-run cleanly after the underlying problem is fixed.
(+1)* AMEN! and AMEN! -- When I first started tinkering with package installations, I had a koha-create nightmare happen for me. It was fixable and all, but it was a pain. GPML, Mark Tompsett
On Tue, Apr 23, 2013 at 3:14 PM, Galen Charlton <gmc@esilibrary.com> wrote:
My biggest desideratum for these scripts is that koha-create be atomic -- in other words, that it either completely succeed, or if it fails, completely clean up after itself so that it can be re-run cleanly after the underlying problem is fixed.
As Robin states on bug 4876, the goal is that commands rollback when something breaks. koha-create is the most complex. I left koha-create at the bottom of my tasks list because of that, and am sure is the one the bigger discussions will start. Thanks for your reply, and I'll let those bugs+patches talk. To+
Tomas Cohen Arazi schreef op di 23-04-2013 om 12:24 [-0300]:
I'd like you to (1) tell me if its ok that I patch them in bash (which is what they are written in) and (2) if you have the time, discuss here the current and desired semantics for those commands, including the option switches.
My feeling about bash vs. perl for these scripts is basically that if you're not making sweeping changes, bash is fine. If you're more or less rewriting it (which you're not really), then consider doing it in perl. For new things, if it's something trivial, bash is fine. If it's more complex (like koha-create is), perl would be preferred. I've had a quick look at what you've got so far, and it looks fine. My feelings on making koha-create more atomic are that this might require a rewrite in Perl to really do it. Ideally for every operation performed, we would store the undo operation onto a list. If we encounter a failure, we play back the undo operations to get everything back to the initial state. It probably won't be perfect, but I think it'll be a huge improvement. However, this would be hard to implement nicely in bash, I suspect. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On Wed, Apr 24, 2013 at 11:36:09AM +1200, Robin Sheat wrote:
My feelings on making koha-create more atomic are that this might require a rewrite in Perl to really do it. Ideally for every operation performed, we would store the undo operation onto a list. If we encounter a failure, we play back the undo operations to get everything back to the initial state. It probably won't be perfect, but I think it'll be a huge improvement.
I would like koha-remove to be able to deal with partially removed instances, currently it runs as `set -e` meaning if any of the remove operations fail it will give up on the rest. This may be as simple as removing the `set -e` flag. Once this is done dealing with a koha-create failure is as simple as running koha-remove on the instance you just failed to created, it may also be possible for koha-create to automatically call koha-remove on such an error by using the trap feature of bash. The disadvantage to this approach is that it could remove files that were not created by koha-create, although such files would most likely be stomped over by koha-create anyway so I am not sure if this would be an issue or not. Cheers, ~Chris Hall
participants (5)
-
Chris Hall -
Galen Charlton -
Mark Tompsett -
Robin Sheat -
Tomas Cohen Arazi