[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSUser and paths generally
Re: NSUser and paths generally
Wed, 17 Dec 2003 11:44:20 +0100
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Sheldon Gill wrote:
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.
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
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 :-) ).
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?)
/etc/profile is _not_ a packaging option here.
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.
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.)
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.
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.
Yet how would you stop a user from using LD_LIBRARY_PATH & co. to
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.
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:
This _requires_ having -make installed. It also means problematic behaviour
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
Ah! I had misunderstood. Thanks for clarifying.