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