PATH variable case-insensitive?

PATH variable case-insensitive?

[Koch]

Using zsh 5.0.2 (x86_64-pc-linux-gnu) with the following file contents in 
./test.zsh:

PATH=bar
path=omg
echo $PATH

and running zsh ./test.zsh outputs:
omg

Is this a bug? It's certainly not my intention to have this meaning attached to 
this program, since it goes against POSIX.

Re: PATH variable case-insensitive?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

That is not a bug. It's a feature. See the discussion of "typeset -T" in
"man zshbuiltins". The lower-case version of PATH is an array parameter
bound to the scalar upper-case parameter. The CDPATH parameter has a
similar binding. You can create your own with "typeset -T".

Personally, I like the feature as it allows for more readable and easier to
maintain dot files. For example, in my $HOME/.zshenv I have

_PATH="$PATH"  # save the original path for diagnostic purposes
typeset -U path  # note that -T is implicit for PATH/path
path=(
    ${HOME}/bin
    ${HOME}/sbin
    ${HOME}/symlinks
    /usr/local/bin
    /usr/local/go/bin
    /usr/local/sbin
    /usr/bin
    /usr/sbin
    /bin
    /sbin
    /opt/X11/bin
    )

typeset -U cdpath # note that -T is implicit for CDPATH/cdpath
cdpath=(
    ${HOME}/projects/personal
    ${HOME}/projects/3rd_party
    .
)


On Thu, Feb 5, 2015 at 7:56 AM, Koch <omgoch@gmail.com> wrote:

> Using zsh 5.0.2 (x86_64-pc-linux-gnu) with the following file contents in
> ./test.zsh:
>
> PATH=bar
> path=omg
> echo $PATH
>
> and running zsh ./test.zsh outputs:
> omg
>
> Is this a bug? It's certainly not my intention to have this meaning
> attached to this program, since it goes against POSIX.
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: PATH variable case-insensitive?

[Peter Stephenson]

On Thu, 5 Feb 2015 16:56:00 +0100
Koch <omgoch@gmail.com> wrote:
> Using zsh 5.0.2 (x86_64-pc-linux-gnu) with the following file contents in 
> ./test.zsh:
> 
> PATH=bar
> path=omg
> echo $PATH
> 
> and running zsh ./test.zsh outputs:
> omg
> 
> Is this a bug? It's certainly not my intention to have this meaning
> attached to this program, since it goes against POSIX.

In addition to what Kurtis said, if you're expecting zsh run in the
default fashion to be strictly POSIX-compatible, you're in for a *lot*
of surprises.  There are ways of making it so but generally speaking
unless you're comfortable with zsh's own way of doing things, bash is
your friend.

pws

Re: PATH variable case-insensitive?

[Peter Stephenson]

On Thu, 5 Feb 2015 16:38:28 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> ...if you're expecting zsh run in the
> default fashion to be strictly POSIX-compatible, you're in for a *lot*
> of surprises.

We really ought to be upfront about this at the start of the manual (hi,
Manuel)... we say it's "not completely compatible" with ksh, but that's
a bit weaselly.  The Sourceforge page puts this a bit better.  We should
probably say something like...

diff --git a/Doc/Zsh/manual.yo b/Doc/Zsh/manual.yo
index 5184928..f9aa700 100644
--- a/Doc/Zsh/manual.yo
+++ b/Doc/Zsh/manual.yo
@@ -5,7 +5,8 @@ texitop(The Z Shell Manual)
 texiifinfo(\
 This Info file documents Zsh, a freely available UNIX command interpreter
 (shell), which of the standard shells most closely resembles the Korn shell
-(ksh), although it is not completely compatible.
+(ksh), although it is not completely compatible.  Zsh is able to emulate
+POSIX shells, but its default mode is not POSIX compatible, either.
 
 cindex(version)
 Version version(), last updated date().

pws

Re: PATH variable case-insensitive?

[ZyX]

05.02.2015, 19:10, "Koch" <omgoch@gmail.com>:
> Using zsh 5.0.2 (x86_64-pc-linux-gnu) with the following file contents in
> ./test.zsh:
>
> PATH=bar
> path=omg
> echo $PATH
>
> and running zsh ./test.zsh outputs:
> omg
>
> Is this a bug? It's certainly not my intention to have this meaning attached to
> this program, since it goes against POSIX.

If you want  POSIX emulation in zsh, do use either `emulate -L sh` at the top of the script or run it with symlink named sh (i.e. rather use `sh` as the last component of the program name*)`.

Strict POSIX compatibility was never a goal of zsh in its “native” mode. For interactive uses this feature is rather convenient. In scripts I myself have run several times into the effective inability to use `path` variable in e.g. `for path in foo/*` until learned this thing though.

* Like this with execve, see the beginning of execve argument:

        % echo 'int main(int argc, char **argv, char **environ) { execve("/bin/zsh", (const char *[]) {"/bin/sh", "-c", "echo path:$path PATH:$PATH", 0}, environ); }' | tcc -run -
        path: PATH:/bin:/usr/bin:/usr/ucb:/usr/local/bin
        % echo 'int main(int argc, char **argv, char **environ) { execve("/bin/zsh", (const char *[]) {"/bin/zsh", "-c", "echo path:$path PATH:$PATH", 0}, environ); }' | tcc -run 
        path:/bin /usr/bin /usr/ucb /usr/local/bin PATH:/bin:/usr/bin:/usr/ucb:/usr/local/bin

  (It actually appears that tcc does not support 3-argument form of main() (this is not my actual $PATH setting). But the point can be seen in any case since shell is able to get $PATH setting somewhere. Use `gcc -xc - && ./a.out && rm ./a.out` in place of `tcc -run -` to see your actual $PATH setting.)