env variables

env variables

[Timothy Doyle]

Hi, Ive been unsuccessfully trying to solve a problem for a while now, and
finally thought to toss pride to the side and ask for help.

The problem seems to be that certain programs do not recognize the existence
of certain environment variables.  The programs are CVS, man, and JDK javac,
and the variables are CVSROOT, MANPATH, and CLASSPATH respectively.  I had
forgotten about the problem until I just recently changed shells at my new
job (from csh to zsh), effectively disabling both man and javac.  The
problem seems to be with variables previously (in csh) set with setenv.

I would love to hear any advice you have on this matter.

Timothy Michael Doyle
-----------------------------------------------
tdoyle@firstquadrant.com
626.683.4232 (work)
626.449.0181 (home)
107 South Chester Avenue #5, Pasadena, CA 91106

Re: env variables

[Nik Gervae]

> The problem seems to be that certain programs do not recognize the existence
> of certain environment variables.  The programs are CVS, man, and JDK javac,
> and the variables are CVSROOT, MANPATH, and CLASSPATH respectively.  I had
> forgotten about the problem until I just recently changed shells at my new
> job (from csh to zsh), effectively disabling both man and javac.  The
> problem seems to be with variables previously (in csh) set with setenv.

I've had this problem with the lowercase "cdpath" environment variable
too. A program here at work looks for it and under zsh it comes back
null. CDPATH exists, of course, but the program I mention doesn't look
for that....

--Nik
  Nothing is easy.

Re: env variables

[Geoff Wing]

Timothy Doyle <tdoyle@fqw.com> typed:
:Hi, Ive been unsuccessfully trying to solve a problem for a while now, and
:finally thought to toss pride to the side and ask for help.
:
:The problem seems to be that certain programs do not recognize the existence
:of certain environment variables.  The programs are CVS, man, and JDK javac,
:and the variables are CVSROOT, MANPATH, and CLASSPATH respectively.  I had
:forgotten about the problem until I just recently changed shells at my new
:job (from csh to zsh), effectively disabling both man and javac.  The
:problem seems to be with variables previously (in csh) set with setenv.
:
:I would love to hear any advice you have on this matter.

More information please.

In zsh, does

% export | egrep "(CVSROOT|MANPATH|CLASSPATH)"

list all three?  If not, make sure you're exporting them in one of your
startup files (e.g. ~/.zshenv) so that they're env vars rather than local
vars, with something like ``export CVSROOT=/path/to/my/cvs/root''
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: env variables

[Nik Gervae]

> More information please.

Here's some from me.



> In zsh, does
> % export | egrep "(CVSROOT|MANPATH|CLASSPATH)"
> list all three?

My problem is with cdpath (lowercase). I have modified my rc files to
do this:

    export cdpath=(. /usr/pic5 /usr/tmp)
    export CDPATH=${(j/:/)cdpath}

...so that both case-versions of the variable are defined. I noted that
when I set only cdpath, CDPATH wasn't automatically getting defined
as the documentation says it should. Hmm.

Anyway, cdpath still doesn't show up in my environment. This small
program gets NULL for "cdpath" but retrieves "CDPATH" just fine:

#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *env;

    if (argc < 1) exit(EXIT_FAILURE);


    env = getenv(argv[1]);
    printf("%s\n", argv[1]);
    printf("%s\n", env);
    exit(EXIT_SUCCESS);
}

This is all in version 3.0.5.

--Nik

Re: env variables

[Geoff Wing]

Nik Gervae <Nik@pdi.com> typed:
:> More information please.
:Here's some from me.
:> In zsh, does
:> % export | egrep "(CVSROOT|MANPATH|CLASSPATH)"
:> list all three?
:My problem is with cdpath (lowercase). I have modified my rc files to
:do this:
:    export cdpath=(. /usr/pic5 /usr/tmp)
:    export CDPATH=${(j/:/)cdpath}
:...so that both case-versions of the variable are defined. I noted that
:when I set only cdpath, CDPATH wasn't automatically getting defined
:as the documentation says it should. Hmm.
:Anyway, cdpath still doesn't show up in my environment. This small
:program gets NULL for "cdpath" but retrieves "CDPATH" just fine:
:This is all in version 3.0.5.

Arrays aren't exported, because there's no standard or de facto method of
exporting arrays, so nothing would understands them.  Only strings are
exported.  From your example, CDPATH is a string, cdpath is an array.
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: env variables

[Nik Gervae]

> Arrays aren't exported, because there's no standard or de facto method of
> exporting arrays, so nothing would understands them.  Only strings are
> exported.  From your example, CDPATH is a string, cdpath is an array.

Hmm. That sounds slightly fishy in that csh happily exports array
variables, but then csh is bogus in so many ways.... I've managed
to get access to the source code for the program that's causing me
the trouble, though, so I'll just fix that!

--Nik

Re: env variables

[Geoff Wing]

Nik Gervae <Nik@pdi.com> typed:
:> Arrays aren't exported, because there's no standard or de facto method of
:> exporting arrays, so nothing would understands them.  Only strings are
:> exported.  From your example, CDPATH is a string, cdpath is an array.
:Hmm. That sounds slightly fishy in that csh happily exports array
:variables, but then csh is bogus in so many ways.... I've managed

Not as arrays.  In fact, I can't see it doing it at all.
% csh -f
% set | fgrep "(" | cut -f1
argv
path
% env | egrep -i "^(argv|path)" | cut -f1 -d=
PATH

    but PATH is a colon separated string.  path is a space separated string
    which is pretending to be an array.  You could export it as such but it
    would be useless.  What happens when an element in the array has a space
    in it?

% set l=(a b "c d")
% foreach i ($l)
? echo $i
? end
a
b
c
d
% zsh -f
% l=(a b "c d")
% foreach i ($l); echo $i; end
a
b
c d

-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: env variables

[Bart Schaefer]

On May 4,  3:39am, Geoff Wing wrote:
} Subject: Re: env variables
}
} Nik Gervae <Nik@pdi.com> typed:
} :> Arrays aren't exported, because there's no standard or de facto
} :> method of exporting arrays, so nothing would understands them
} :Hmm. That sounds slightly fishy in that csh happily exports array
} :variables, but then csh is bogus in so many ways....
}
} Not as arrays. In fact, I can't see it doing it at all.

The problem is not really with exporting arrays ... the problem is with
exporting a variable whose name happens to be the same as one of zsh's
special array variables.

In the case in question, some program wants a variable named "cdpath" to
be in the environment.  It probably expects that to be a colon-separated
string, but it doesn't really matter what it expects, because zsh won't
put a variable named "cdpath" in the environment.  It actively removes
such a variable from the environment if it happens to be there when the
shell starts up.

This is one reason I've always preferred csh's model of keeping local
and environment variables in completely separate namespaces.  (The icky
bit about the csh model is that you still refer to both with $xxx, so
you can't tell what namespace you're referencing.)  (No, zsh should not
change models.)

The only workaround is to export the variable for a single command only,
like so:

	cdpath=$CDPATH printenv

In older versions of zsh, that would have clobbered both cdpath and CDPATH
for the current shell, but fortunately that's fixed in current releases
so you can use it safely.

Hmm; hey, Peter, another FAQ entry?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: env variables

[Nik Gervae]

Geoff Wing writes:
> Nik Gervae <Nik@pdi.com> typed:
> :> Arrays aren't exported, because there's no standard or de facto method of
> :> exporting arrays, so nothing would understands them.  Only strings are
> :> exported.  From your example, CDPATH is a string, cdpath is an array.
> :Hmm. That sounds slightly fishy in that csh happily exports array
> :variables, but then csh is bogus in so many ways.... I've managed
> 
> Not as arrays.  In fact, I can't see it doing it at all.
> [...]
>     but PATH is a colon separated string.  path is a space separated string
>     which is pretending to be an array.  You could export it as such but it
>     would be useless.  What happens when an element in the array has a space
>     in it?

That's exactly right. csh happily exports the variable as it would print its
contents, minus the parentheses. At this point I'm more inclined to think
that the program that's getting such an environment variable is making a
serious mistake than to think that zsh is defective.

--Nik

Re: env variables

[Nik Gervae]

I just thought of something with regard to csh exporting arrays as
space-separated strings. What if your PATH environment variable contains a
directory name with a colon in it? Same problem, no? Might it make sense
given this to export array values with spaces in between?

--Nik