Re: *PATH variables

[Nicola Pero]

> > First of all - Happy New Year, Steppers ;-)
> >
> > GNUstep.* "startup" are changing *PATH shell variables by
> > adding GNUstep paths before system. I don't think this is The
> > Right Thing(tm), since GNUstep tools can be named like system
> > utils. gsnd, for example - in GNUstep this is a sound service,
> > but gsnd also exists in ghostscript (gsnd - Run ghostscript
> > (PostScript and PDF engine) without display according to man
> > gsnd).
> >
> > I think it's better add entries to end of *PATH's. Something
> > like that:
> >
> > PATH="$PATH:/User:/Local:/Network:/System"
> >
> > instead of:
> >
> > PATH="/User:/Local:/Network:/System:$PATH"
> >
> > Patch for -make attached, but I'm nos sure if it's 100% right
> > for csh since i don't use it.
> 
> I'm not at all sure about this ...
> 
> It seems to me quite reasonable that GNUstep directories should be 
> inserted at the start of the path ... so the GNUstep tools will be 
> found in preference to other versions.  If you are running GNUstep that 
> seems quite likely to be what you want.
> 
> On the other hand, most GNUstep applications/tools should not be using 
> PATH, (they would use NSSearchPathForDirectoriesInDomains() instead), 
> so the PATH would only be relevant when starting things from the unix 
> command line.

I'm not sure.

I think the PATH is set in this way because if you are installing and
using GNUstep on an OpenStep (but non-GNUstep) system, then if you source
GNUstep.sh, you want GNUstep tools to take precedence over the OpenStep
(but non-GNUstep) ones with the same name.

For example, suppose you are able to compile and run gnustep-base on Mac
OS X.  Then, to look into your defaults, you want to use 'defaults read'.  
Now, Mac OS X has 'defaults read' too.  Depending on how the PATH is set
(appending or prepending to the existing one), gnustep-base's or Cocoa's
one will be found if you don't specify the full path.

The current GNUstep.sh assumes that if you source GNUstep.sh, then you are
using GNUstep and want gnustep-base's defaults to have the precedence over
Cocoa's one.

In the end, I'm not sure about making this change.


> Renaming gsnd is probably a good idea ... it doesn't seem too clever to 
> conflict with ghostscript.

Yes - I'm for slightly longer names, a name like 'gsnd' is too short, and
it's an acronym which could expand to anything, and could be used by
another project to mean something completely different.  Other names have
the same problem ... gdnc for example.

Maybe we should use a 'gnustep' namespace - "gnustep-snd" probably will
never conflict with anything :-), and people not extremely familiar with
gnustep might also appreciate when they look in 'ps' or 'top' - 'gsnd' is
quite obscure as a name, something like 'gnustep-snd' is more clearly a
gnustep server process.

This is only a suggestion - another name is probably as good.  Maybe I'd
choose "gnustep-sound" or even "gnustep-sound-daemon".