Re: gnustep-make experiment

[Richard Frith-Macdonald]

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.