Re: NSUser and paths generally

[David Ayers]

Sheldon Gill wrote:

> On Wed, 17 Dec 2003 02:25, David Ayers wrote:
>  
>
> > NSUser.m contains functions associated with the user and his environment
> > defined in NSPathUtilities.h.  There is no such thing an NSUser class.
> > You are effectively proposing to rename NSUser.m to NSPathUtilities.m.
> > I'd think thrice before dealing with the issues realted to obtaining the
> > CVS history for these file just for the functions to be "more at home".
> > (OTOH, I was the one who moved all the header files a while back :-) )
> >    
>
> I was thinking of leaving the user name and such login functions in NSUser and 
> moving the path discovery to NSPathUtilities. The correspondence between 
> header and source makes life a little easier but that's not the sole reason 
> for the change.
>
> Currently, there are file system dependancies/assumptions in many different 
> places throughout the code. My aim is to consolidate them as far as possible 
> and 'clean' things up somewhat. This will pave the way for behaviour 
> improvements.
>
>  
Increasing the locality of filesystem dependancy is good, but it seems 
orthogonal to moving functions from one *.m file to another.  The 
username and login functions are also declared in NSPathUtilites.h, so 
/if/ we have a good reason to move any of the functions to have a 
*./h-*.m correspondance then please let's be consistent about it.

> > I guess some administrators may not want users to be able to change the
> > behavior of their apps by tweaking environment variables, yet
> > introducing new static search locations like /etc/GNUstep doesn't add to
> > GNUstep's portability (even if it's ignored when it diesn't exist, we'd
> > still need an analogous mechanism for other platforms like MinGW other
> > distros that don't have /etc).
> >    
>
> The right answer for Win32 is HKLM\Software\GNU\GNUstep\ with string keys 
> equal to the environment variables.
>  
OK, this would need to be documented (if not implemented :-) ).

> /etc/profile is _not_ a packaging option here.
Hmm.  I'm not sure, I'm following the implication of this assertion.... 
Do you simply mean that once we have such a mechanism for all platforms, 
that we would require it to exist even if empty?  Or must it contain 
entries? (i.e. obsoleting the environment variables?)

> Requiring a bourne-shell 
> compatible program installed and run on start-up isn't very friendly either.
>  
Well, I'm not sure what compatibility level is truely required but 
agreed, it would be nice to have a way to drop this requirement.  Yet 
I'm not sure at what price though...

> I made this suggestion in relation to 'packaging' rather than 'portability'. 
> Implementing this would mean that GNUstep system configuration for most *nix 
> would be in /etc/GNUstep which is consistent with what other packages do, 
> especially WindowMaker. Make life easier for sys admins.
>
> It would also mean you could run GNUstep applications without sourcing 
> GNUstep.sh. Plus, you lose the -make dependancy. I see win, win here. Break 
> nothing and add important functionality.
>
>  
Wouldn't it require every process to parse that .plist?  I'm not sure 
that the performance hit would be for simple tools.  But then I guess it 
could somehow be done lazily for tools that ex/implicitly request search 
paths.  (Which may be effectively all useful tools, but then again we 
may already effectively allways parse time zone information.  Then it 
might not make much of a difference.)

> > Yet how would you stop a user from using LD_LIBRARY_PATH & co. to
> > manipulate behavior?
> >    
>
> LD_ & co are concerns for administration and security more generally. There 
> are various approaches to this problem which is really beyond the scope of 
> this discussion. (and, I feel, of gnustep itself)
> Providing an alternative behaviour opens the door for such pursuits.
>
>  
It is out of scope, I just had the feeling that the same principals 
apply.  If we want to rely on parsing a plist, we kind of move towards 
an /etc/ld.so.conf mechanism.  But unlike LD_ & co. you're suggesting 
that the environment variables would be overriden by the configuration 
file, and that is also a point which is making me uneasy... but as Adam 
and Richard have jumped in, I'll try to keep a low profile for here on.

> > I the available ./configure options of -make together with GNUstep.sh
> > (sourced by /etc/profile) should give you some freedom to setup a custom
> > the environment.  Yet this does not include putting apps and libraries
> > in to places not defined by:
> > http://www.gnustep.org/resources/documentation/filesystem.ps
> >    
>
> This _requires_ having -make installed. It also means problematic behaviour 
> with su.
>
> I'm not advocating putting GNUstep applications or libraries in places not 
> defined by GFSH. Adding these paths to the search path return means 
> applications can find things in /lib or /bin using the same mechanism as 
> everything else.
>  
Ah!  I had misunderstood. Thanks for clarifying.

Cheers,
David