[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: gnustep-make experiment
From:
Richard Frith-Macdonald
Subject:
Re: gnustep-make experiment
Date:
2007年2月13日 09:35:54 +0000
On 12 Feb 2007, at 16:47, Nicola Pero wrote:
IIRC we had some extensive discussions on the mailing lists that
.sh/.csh should only be used for scripts that are sourced. But since
GNUStep.sh is referenced so often in the archives, I'm having a hard
time finding the discussion.
I don't remember that discussion, but it's plain obvious that
gnustep-make is
not following that convention! There are lot of .sh files in
gnustep-make
that are not supposed to be sourced (eg, clean_cpu.sh, clean_os.sh,
fixpath.sh,
etc).
We could change gnustep-make to follow the convention though if it
can be argued that
it is a good one - most of the scripts are only used internally in
gnustep-make,
so we should be able to rename them fairly easily. :-)
Anyway, for a start I did change gnustep-config.sh to be gnustep-
config.
I don't remember that discussion either ... perhaps it was on another
mailing list or a private email converstion?
To the best of my knowledge, the standard convention is that a '.sh'
extension indicates a shell script and that implies no distinction
between one intended to be sourced and one intended to be executed.
The distinction between a script intended to be executed and one
intended to be sourced is normally made by file permissions ... one
is made readable and executable but the other is made read only.
Incidentally, GNUstep.sh has the wrong permissions (0755 rather than
0111) when installed by default on my system.
On unix-like systems, the '#!/bin/sh' at the start of a script is
enough to ensure that the script is executed properly when simply
run. However, the '.sh' extension is important if you expect people
to interpret a script with a specific shell (eg. they know to do 'sh
foo.sh' rather than 'csh foo.sh').
So, if some discussion concluded that we should create a new
convention to distinguish between executable and sourceable scripts
by whether there is an extension or not ... I think it was wrong.