Some of Koha's Perl scripts have filenames not ending in .pl. This just hit me badly because those are not handled by fix-perl-path.PL. Personally, I could just get away with pkgsrc's REPLACE_PERL feature, but maybe other people would benefit from correct interpreter paths too. So, is there any reason why not to change the following file names (and all references to them, of course)? ./misc/admin/koha-preferences ./misc/maintenance/borrowers-force-messaging-defaults ./misc/translator/translate ./opac/unapi ./reports/issues_by_borrower_category.plugin ./reports/itemtypes.plugin ./svc/bib_profile ./svc/bib ./svc/authentication ./svc/config/systempreferences ./svc/new_bib (there are, of course, *.t Perl scripts not listed here) debian/list-deps ist probably irrelevant as long as Debian keeps perl in /usr/bin. fix-perl-path.PL is special. acqui/pdfformat/layout[23]pages.pm have superflous shebang lines.
./opac/unapi
I can't comment on the rest, but I know that changing this publicly-accessible path would break any current usage that relies on it. I have non-Koha scripts that use unapi to pull data from Koha. If you change the path my scripts will break. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 30/07/11 20:51, Edgar Fuß wrote:
Some of Koha's Perl scripts have filenames not ending in .pl. This just hit me badly because those are not handled by fix-perl-path.PL.
There's no reason for a perl program to end in .pl beyond convention (and a discredited convention in some circles) I think its really a bug in fix-perl-path... One wonders id using /usr/bin/env perl might be better on the shebang line. It certainly makes testing with multiplr perls easier. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
There's no reason for a perl program to end in .pl beyond convention Yes, of course. But if you have nearly all of the scripts ending in .pl and a fix-perl-path.PL that seems to suggest all the scripts do end in .pl, that's confusing.
Let me elaborate on how this hit me: I was working for a fix to 6390, introducing a new syspref. Changing the syspref failed with ``internal server error'' (not the real one, the JavaScript popup). After hours of searching and tracing my web server, I found out that svc/config/systempreferences was not executed, but delivered, because a) I had configured my lighttpd to only execute .pl scripts and b) it had /usr/bin/perl, not /usr/pkg/bin/perl in it. So the problem was that this one script was different from the others. I was misled because I thought I had broken the setting of preferences with my patch, while really it never worked for me with this version of Koha. I just never tried since the upgrade.
There are reasons that these scripts lack that extension. koha-preferences doesn't have the extension since it's a utility intended to be run from the command line, as opposed to a cronjob or CGI script. Services just lack the extension to distinguish them from user-facing CGI scripts. Besides, if we're exposing APIs, it's nice to keep the underlying technology out of the URL. It's convention, not law, but it would be a bit of a pain to change it. 2011/7/31 Edgar Fuß <ef@math.uni-bonn.de>
There's no reason for a perl program to end in .pl beyond convention Yes, of course. But if you have nearly all of the scripts ending in .pl and a fix-perl-path.PL that seems to suggest all the scripts do end in .pl, that's confusing.
Let me elaborate on how this hit me: I was working for a fix to 6390, introducing a new syspref. Changing the syspref failed with ``internal server error'' (not the real one, the JavaScript popup). After hours of searching and tracing my web server, I found out that svc/config/systempreferences was not executed, but delivered, because a) I had configured my lighttpd to only execute .pl scripts and b) it had /usr/bin/perl, not /usr/pkg/bin/perl in it.
So the problem was that this one script was different from the others. I was misled because I thought I had broken the setting of preferences with my patch, while really it never worked for me with this version of Koha. I just never tried since the upgrade. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Jesse Weaver
It's convention, not law I think there's an additional benefit in having Perl scripts end in .pl: Automated queries. It's not only replacing the shebang line. Think of ``who used module Foo::Bar'' or ``does anyone still call Foo::Bar::deprecated''. You would otherwise need a manually maintained list for that.
On 01/08/2011 15:26, Edgar Fuß wrote:
It's convention, not law I think there's an additional benefit in having Perl scripts end in .pl: Automated queries. It's not only replacing the shebang line. Think of ``who used module Foo::Bar'' or ``does anyone still call Foo::Bar::deprecated''. You would otherwise need a manually maintained list for that.
For information, using an extension for a script in the system PATH must be avoided for a Debian package (see Policy 10.4) Regards, Vincent
participants (5)
-
Colin Campbell -
Edgar Fuß -
Jesse -
Owen Leonard -
Vincent Danjean