Ongoing problem with PATH variable since v2.6-beta17

Ongoing problem with PATH variable since v2.6-beta17

[Mikhail Kuperblum]

Beginning with v2.6-beta17 when I run zsh in xterm window, it doesn't
inherit my PATH correctly.

# echo $PATH
/usr/progressive/bin:/etc:/usr/local/bin:/bin:/usr/bin:/tcb/bin:/usr/bin/X11:/us
r/lib/uucp/:/u/wp/shbin:/u/wp/wpbin:/u/dlc:/u/local/sound/bin:/usr/vsifax/bin:/u
sr/merge/dosroot/ubin
# export
export PATH, etc.
# zsh
[/] echo $PATH
/usr/lib/X11/IXI/XDesktop/bin /usr/lib/X11/IXI/XDesktop/bin/i3sc0322 /usr/progre
ssive/bin /etc /usr/local/bin /bin /usr/bin /tcb/bin /usr/bin/X11 /usr/lib/uucp/
 /u/wp/shbin /u/wp/wpbin /u/dlc /u/local/sound/bin /usr/vsifax/bin /usr/merge/do
sroot/ubin

Firstly, there is no ":" between "PATH" elements so it looks like "path"
variable and simply doesn't work and there are two extra components 
that weren't there before (I have no idea where they're coming from):

/usr/lib/X11/IXI/XDesktop/bin /usr/lib/X11/IXI/XDesktop/bin/i3sc0322

Why my PATH breaks like that? All pre-v2.6-beta17 worked (and still do)
perfectly. Something must have changed somewhere. BTW, there is no problem 
in the character mode. (my OS is SCO OSE 5).

To anyone who might reply: please Cc to mikhail@klm.com since I'm
not a member of this mlist. Thanks!

-- 
mikhail

Re: Ongoing problem with PATH variable since v2.6-beta17

[Mikhail Kuperblum]

Thanks for replying. Unfortunately, it's not that easy. The first 
thing I did when I discovered this problem was getting all my init
files out of the way. It doesn't help!

[/] echo $PATH
/usr/progressive/bin:/etc:/usr/local/bin:/bin:/usr/bin:/tcb/bin:/usr/bin/X11:/us
r/lib/uucp/:/u/wp/shbin:/u/wp/wpbin:/u/dlc:/u/local/sound/bin:/usr/vsifax/bin:/u
sr/merge/dosroot/ubin
[/] zsh -f
klm# echo $PATH
/usr/progressive/bin /etc /usr/local/bin /bin /usr/bin /tcb/bin /usr/bin/X11 /us
r/lib/uucp/ /u/wp/shbin /u/wp/wpbin /u/dlc /u/local/sound/bin /usr/vsifax/bin /u
sr/merge/dosroot/ubin

But things get even more weird!

[/] PATH=
[/] echo $PATH

Re: Ongoing problem with PATH variable since v2.6-beta17

[Mikhail Kuperblum]

[Note: this is an encore, my previous message got cut off in the middle.
Sorry! BTW, to answer your question, I do not have /etc/zshenv]

Thanks for replying. Unfortunately, it's not that easy. The first
thing I did when I discovered this problem was getting all my init
files out of the way. It doesn't help!

[/] echo $PATH
/usr/progressive/bin:/etc:/usr/local/bin:/bin:/usr/bin:/tcb/bin:/usr/bin/X11:/us
r/lib/uucp/:/u/wp/shbin:/u/wp/wpbin:/u/dlc:/u/local/sound/bin:/usr/vsifax/bin:/u
sr/merge/dosroot/ubin
[/] zsh -f
klm# echo $PATH
/usr/progressive/bin /etc /usr/local/bin /bin /usr/bin /tcb/bin /usr/bin/X11 /us
r/lib/uucp/ /u/wp/shbin /u/wp/wpbin /u/dlc /u/local/sound/bin /usr/vsifax/bin /u
sr/merge/dosroot/ubin

But things get even more weird!

[/] PATH=
[/] echo $PATH
 .
[/] /usr/local/bin/zsh -f
klm# echo $PATH
/usr/progressive/bin /etc /usr/local/bin /bin /usr/bin /tcb/bin /usr/bin/X11 /us
r/lib/uucp/ /u/wp/shbin /u/wp/wpbin /u/dlc /u/local/sound/bin /usr/vsifax/bin /u
sr/merge/dosroot/ubin

Let me repeat that this behavior begun with v2.6-beta17. All previous
versions still work fine.

On Mon, Jun 10 ( 9:18pm), Zoltan Hidvegi wrote:

> Does this happen when you invoke zsh with the -f option (I'm quite sure it
> doesn'n).  In that case, try to locate the piece of code which causes this
> in your stratup files.  First locate the startup script that causes the
> problem.  This can be done by invoking zsh -f, than sourcing the various
> startup files with the source builtin (the name of the startup files and
> the order of sourcing is described in the zsh manual page).
> 
> If you located the offending script, edit it (eg. start emace in a separate
> window), and stick in a return statement somewhere near the middle of the
> file.  Then start zsh -f, and source it.  If the bug is still there try to
> move the return statement towards the beginning of the file untill the bug
> disappears, otherwise move return toward the end until the bug appears.
> Locate the line which causes the problem, and try to execute is alone.
> 
> Conclusion: try to invoke zsh with the -f option and reproduce the bug with
> the smallest possible number of the commands.  If any assumption is made
> about the environment (eg. that some files or directories exist or not
> exist) you should describe it.  Note that /etc/zshenv is always executed so
> it's best if the bug can be reproduced with /etc/zshenv removed.

-- 
mikhail