[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSUser and paths generally

From: David Ayers
Subject: Re: NSUser and paths generally
Date: Wed, 17 Dec 2003 11:44:20 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

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 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/ 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
(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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]