[gobolinux-users] Re: Resources/Environment problems
lijon at kymatica.com
Thu Aug 11 23:41:49 GMT 2005
On Thu, 11 Aug 2005 17:42:19 -0300
Hisham Muhammad <hisham.hm at gmail.com> wrote:
> On 8/11/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
> > On Thu, 11 Aug 2005 15:25:48 -0300
> > Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > > On 8/11/05, André Detsch <detsch at gmail.com> wrote:
> > > > On 8/11/05, Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > > > > What do you think about files that looked like:
> > > > >
> > > > > Resources/Environment/QTDIR.set
> > > > > Resources/Environment/KDEDIRS.append
> > > > > Resources/Environment/TEXINPUTS.prepend
> > > > >
> > > > > The "environment cache generator" would only need to be a tiny
> > > > > bit
> > > > smarter.
> > > >
> > > > In order to link the files in /S/L/Environment, we need a naming
> > > > scheme like the used by now, in order to avoid conflicts (e.g.,
> > > > many programs may have KDEDIRS.append).
> > > > Prepending the program name--version is ok?
> > > >
> > > > /S/L/Environment/KDE-Toys--3.3.0--KDEDIRS.append ->
> > > > /Programs/KDE-Toys/Current/Resources/Environment/KDEDIRS.append
> > >
> > > Looks good to me. Also, testing if Resources/Environment is a file
> > > or a directory is a good way to test for backward compatibility
> > > for a while.
> > Sounds very good, except that I thought the Environment file was a
> > nice way to have a modular /etc/zshrc =)
> > i.e. you could use shellcode in them, etc... some cases could need
> > special intelligence, like "if $FOO is unset, set BAR to this else
> > set FOO to that".
> Yeah, but adding zsh-specific stuff in Environment is not nice. I
> don't think we really need arbitrary shell code in there, though maybe
> things like `uname -r` might come up -- is that "portable enough"?
Isn't Scripts already quite zsh dependant?
My point is that it could be nice if programs could add stuff to your
shell startup code...
> > Another way would be to have script functions to append, prepend or
> > set a PATH-like variable:
> > in /Programs/Foo/Current/Resources/Environment:
> > prepend FOOPATH $ThisProgram/lib/foo_stuff
> I don't think this is too different from
> export FOOPATH=$ThisProgram/lib/foo_stuff:$FOOPATH
Yes it is different, the equivalent would be:
[ "$FOOPATH" ] && export FOOPATH="$FOOPATH:$1" || export FOOPATH="$1"
And I don't think there should be any "set" action, becouse if there is
a need to override a potentially already existing variable, we still
don't know in what order the Environment files are executed! (which
means we don't know what is overriding what...)
> but you raise a valid point: I think it's important to have something
> like $ThisProgram (to be resolved during cache generation) to abstract
> the path away from the Environment file.
That would be nice.
/Jonatan -=( http://kymatica.com )=-
More information about the gobolinux-users