The easiest option usually involves engaging a Koha consultant or consulting
company. There is a list on the website - Paid Support.
Sent from Samsung Mobile
-------- Original message --------
From: Vijaya Kumar <[email protected]>
Date:20/09/2014 11:36 (GMT+05:30)
To: [email protected]
Subject: Re: [Koha-devel] Koha-devel Digest, Vol 106, Issue 27
GOOD MORNING KOHA USERS,
KINDLY ARRANGE TO SEND EASY METHOD RELATAED TO HOW TO INSTALL KOHA SOFTWARE
ON LINUX PLATFORM.
THANKING YOU YOU,
YOURS SINCERELY
DR.J.VIJAYA KUMAR
On Fri, Sep 19, 2014 at 3:30 PM, <[email protected]>
wrote:
Send Koha-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Re: Conventions for CLI scripts (Mark Tompsett)
2. Re: Conventions for CLI scripts (Owen Leonard)
3. Koha Developer IRC meeting 23 September 2014 at 15:00 and
22:00 UTC (Tomas Cohen Arazi)
4. Re: Conventions for CLI scripts (Robin Sheat)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Sep 2014 09:29:42 -0400
From: "Mark Tompsett" <[email protected]>
To: "Koha Devel" <[email protected]>
Subject: Re: [Koha-devel] Conventions for CLI scripts
Message-ID: <[email protected]>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
Greetings,
> 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.)
If you run a script called DestroyTheDatabase, you would expect the default
action to be complete and utter deletion. I think a dry-run flag would make
sense for this type of script. The problem is those scripts whose name is
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. 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?
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.
> 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?
> 3. Are there any other conventions we should deal with at the same
> time?
None of which I am aware.
[SNIP]
+1 on the turning off auto-commit, so dry runs do the same as actual runs.
+1 on the explicit rollback or commit.
> $dbi->begin_work;
Actually, I guess that is a nicer way of doing this?
# Start transaction
$dbh->{AutoCommit} = 0;
$dbh->{RaiseError} = 1;
GPML,
Mark Tompsett
------------------------------
Message: 2
Date: Thu, 18 Sep 2014 09:37:33 -0400
From: Owen Leonard <[email protected]>
To: Koha Devel <[email protected]>
Subject: Re: [Koha-devel] Conventions for CLI scripts
Message-ID:
<CAO4qe2PLYna57wQqeFX56KXK=rs_235bdf2ysvnd03wo063...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Do we force help on users if no parameters are passed?
As a non-expert in command line things, this is what I would expect.
At the very least a brief help, with the suggestion that passing
--help would give more.
-- Owen
--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
------------------------------
Message: 3
Date: Thu, 18 Sep 2014 12:05:23 -0300
From: Tomas Cohen Arazi <[email protected]>
To: koha-devel <[email protected]>
Subject: [Koha-devel] Koha Developer IRC meeting 23 September 2014 at
15:00 and 22:00 UTC
Message-ID:
<CABZfb=x94ca854xgq0enhsj+4iemd1ez1zm3s_99nru2b8s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm calling for a dev meeting next week, dedicated to DBIC discussions.
We'll have DBIC's Peter Rabbitson on the IRC channel to hear his POV too.
He can attend 15:00 UTC only though.
I'll be happy to have all positions explicitly stated, and discussed. If we
can make a decision, that's bonus points.
Please send me your POV so I can put that on the wiki to sumarize what we
already discussed. Otherwise, i'll do my best to be impartial.
--
Tom?s Cohen Arazi
Prosecretar?a de Inform?tica
Universidad Nacional de C?rdoba
? +54 351 5353750 ext 13168
GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.koha-community.org/pipermail/koha-devel/attachments/20140918/06a86435/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 19 Sep 2014 11:19:34 +1200
From: Robin Sheat <[email protected]>
To: [email protected]
Subject: Re: [Koha-devel] Conventions for CLI scripts
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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-0001.pgp>
------------------------------
_______________________________________________
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/
End of Koha-devel Digest, Vol 106, Issue 27
*******************************************
--
Dr.J.Vijaya Kumar
Engineering College Library
Andhra University
Visakhapatnam- 530 003
Andhra Pradesh
India.
E-Mail Address:
[email protected]
[email protected]
[email protected]_______________________________________________
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/
