Bug report: PWD environment variable broken!

Bug report: PWD environment variable broken!

[Martin Buchholz]

On some platforms, the PWD environment variable is not being properly
updated after a cd.  This is the environment variable, not the
internal PWD variable.

Here is some output on a variety of systems for this command sequence:

uname -a; echo $ZSH_VERSION; cd ~/x/build;  env | grep PWD | grep -v OLDPWD

Conclusions:  3.1 Seems to be broken on Linux and BSDI.  A serious bug.

I tried to downgrade to 3.0.5.

3.0.5 on BSDI coredumps on invocation. 

On Linux 3.0.5 failed to build:

gcc -c -I.. -I. -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2 builtin.c
builtin.c:4279: macro `dup' used with just one arg

:-(

It's sad to see my favorite shell so buggy!

-------------- etlindy11 ----------------
IRIX etlindy11 6.2 03131015 IP22
3.1.5
PWD=/usr/users/martin/x/build
-------------- etlsui2  ----------------
HP-UX etlsui2 B.10.20 A 9000/780 2004436110 two-user license
3.1.5
PWD=/usr/users/martin/x/build
-------------- mongkok  ----------------
Linux mongkok 2.0.34 #5 Tue Feb 16 17:22:05 JST 1999 i586 unknown
3.1.2-debian
PWD=/usr/users/martin
-------------- mule     ----------------
SunOS mule 4.1.4 2 sun4m
3.1.5
PWD=/usr/users/martin/x/build
-------------- etlken   ----------------
SunOS etlken 5.6 Generic_105181-08 sun4u sparc SUNW,Ultra-2
3.1.5
PWD=/usr/users/martin/x/build
-------------- gneiss   ----------------
OSF1 gneiss.etl.go.jp V4.0 1091 alpha
3.1.5
PWD=/usr/users/martin/x/build
-------------- yuenlong ----------------
export DISPLAY=mulelab:0.0
uname -a; echo $ZSH_VERSION; cd ~/x/build;  env | grep PWD
FreeBSD yuenlong.etl.go.jp 2.2.8-RELEASE FreeBSD 2.2.8-RELEASE #0: Mon Nov 30 06:34:08 GMT 1998     jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC  i386
3.0.5
PWD=/usr/users/martin/x/build
-------------- kowloon  ----------------
export DISPLAY=mulelab:0.0
uname -a; echo $ZSH_VERSION; cd ~/x/build;  env | grep PWD
BSD/OS kowloon.etl.go.jp 4.0 BSDI BSD/OS 4.0 Kernel #0: Tue Jul 28 15:56:54 MDT 1998     polk@demiurge.BSDI.COM:/rel/proto/4.0-i386/usr/src/sys/compile/GENERIC  i386
3.1.5
PWD=/usr/home/martin
-------------- mulelab  ----------------
SunOS mulelab 5.5.1 Generic_103640-05 sun4u sparc SUNW,Ultra-2
3.1.5
PWD=/usr/users/martin/x/build

Re: Bug report: PWD environment variable broken!

[Peter Stephenson]

Martin Buchholz wrote:
> On some platforms, the PWD environment variable is not being properly
> updated after a cd.  This is the environment variable, not the
> internal PWD variable.

This was fixed in zsh-workers/4589 (however, there have been various other
pwd-related patches).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Bug report: PWD environment variable broken!

[Bart Schaefer]

On Feb 20,  9:31pm, Martin Buchholz wrote:
} Subject: Bug report:  PWD environment variable broken!
}
} I tried to downgrade to 3.0.5.
} 
} 3.0.5 on BSDI coredumps on invocation. 

Try picking up <ftp://ftp.brasslantern.com/pub/zsh/patch-3.0.5-ext-2> and
see if that fixes you up.

Note that for some reason, very recent versions of the "patch" program
fail when they reach the second hunk of globals.h.  It works fine with
"patch" version 2.1, but at some point since then the FSF broke things.

} On Linux 3.0.5 failed to build:
} 
} gcc -c -I.. -I. -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2 builtin.c
} builtin.c:4279: macro `dup' used with just one arg

That's very odd, it builds fine for me all the time.  And `dup' shouldn't
be a macro, it's a system call.  You should try to find out where that
macro is coming from, I think your gcc installation must be strange.

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

2 patches included to fix configure brokenness

[Martin Buchholz]

>>>>> "Bart" == Bart Schaefer <schaefer@brasslantern.com> writes:

Bart> On Feb 20,  9:31pm, Martin Buchholz wrote:
Bart> } Subject: Bug report:  PWD environment variable broken!
Bart> }
Bart> } I tried to downgrade to 3.0.5.
Bart> } 
Bart> } 3.0.5 on BSDI coredumps on invocation. 

Bart> Try picking up <ftp://ftp.brasslantern.com/pub/zsh/patch-3.0.5-ext-2> and
Bart> see if that fixes you up.

Tried that.  No help.

zsh configuration
-----------------
zsh version           : 3.0.5-ext-2
host operating system : bsdi4.0
source code location  : .
compiler              : gcc
compiler flags        :  -Wall -Wno-implicit -Wmissing-prototypes -O2
binary install path   : /usr/local/bin
man page install path : /usr/local/man
info install path     : /usr/local/info

(martin@kowloon) ~/ex/src/zsh-3.0.5-ext-2/Src $ ./zsh
zsh: segmentation fault (core dumped)  ./zsh

Bart> Note that for some reason, very recent versions of the "patch" program
Bart> fail when they reach the second hunk of globals.h.  It works fine with
Bart> "patch" version 2.1, but at some point since then the FSF broke things.

Patch version 2.2 seemed to work fine.

Bart> } On Linux 3.0.5 failed to build:
Bart> } 
Bart> } gcc -c -I.. -I. -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2 builtin.c
Bart> } builtin.c:4279: macro `dup' used with just one arg

Bart> That's very odd, it builds fine for me all the time.  And `dup' shouldn't
Bart> be a macro, it's a system call.  You should try to find out where that
Bart> macro is coming from, I think your gcc installation must be strange.

Debian GNU Linux 2.0 seems to come with /usr/include/libc.h, which has:

(martin@mongkok) ~ $ g -w dup /usr/include/**/*.h
/usr/include/asm/fcntl.h:20:#define F_DUPFD		0	/* dup */
/usr/include/asm/unistd.h:279:static inline _syscall1(int,dup,int,fd)
/usr/include/fcntlbits.h:48:#define F_DUPFD		0	/* dup */
/usr/include/libc.h:10:#define	dup(a,b)			dup2(a,b)
/usr/include/linux/net.h:92:  int	(*dup)		(struct socket *newsock, struct socket *oldsock);
/usr/include/unistd.h:329:extern int dup __P ((int __fd));

libc.h is completely bogus.  It has this copyright notice:

/* Copyright (c) 1992 AT&T - All rights reserved. */

	/* Plan 9 C library interface */


<flame on>
I don't know what moron came up with the idea of including ANOTHER
operating system's headers with Debian Linux.  When people talk about
code reuse, I don't think this is what they had in mind.
<flame off>


Here's a patch that work for me, but I'm not sure what other systems
require libc.h.  It's a non-standard header, no system should need it anymore.

--- system.h.orig	Sun Feb 21 14:38:52 1999
+++ system.h	Sun Feb 21 14:40:37 1999
@@ -48,8 +48,10 @@
 # define _(Args) ()
 #endif
 
-#ifdef HAVE_LIBC_H     /* NeXT */
+#ifdef __NeXT__
+#ifdef HAVE_LIBC_H
 # include <libc.h>
+#endif
 #endif
 
 #ifdef HAVE_UNISTD_H


Also, on this system, domainname is in libc, and yp_all is in libnsl.

cd Src && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H' CFLAGS='-Wall -Wno-implicit -Wmissing-prototypes -O2' LDFLAGS='' LIBS='-lcurses' prefix='/usr/local' exec_prefix='/usr/local' bindir='/usr/local/bin' infodir='/usr/local/info' mandir='/usr/local/man' manext='1'
make[1]: Entering directory `/amd/wanchai/root/export1/xemacs/src/zsh-3.0.5-ext-2/Src'
gcc  -o zsh builtin.o compat.o cond.o exec.o glob.o hashtable.o hist.o init.o input.o jobs.o lex.o linklist.o loop.o math.o mem.o params.o parse.o signals.o subst.o text.o utils.o watch.o zle_bindings.o zle_hist.o zle_main.o zle_misc.o zle_move.o zle_refresh.o zle_tricky.o zle_utils.o zle_vi.o zle_word.o -lcurses
zle_tricky.o: In function `maketildelist':
zle_tricky.o(.text+0x2aeb): undefined reference to `yp_all'
collect2: ld returned 1 exit status

Here's a real live tested patch that fixes it right.

--- configure.in.orig	Fri Jan  1 01:01:00 1999
+++ configure.in	Fri Jan  1 01:01:00 1999
@@ -353,6 +353,11 @@
   AC_CHECK_LIB(nsl, getdomainname)
 fi
 
+AC_CHECK_FUNCS(yp_all)
+if test $ac_cv_func_yp_all = no; then
+  AC_CHECK_LIB(nsl, yp_all)
+fi
+
 dnl I am told that told that unicos reqire these for nis_list
 if test `echo $host_os | sed 's/^\(unicos\).*/\1/'` = unicos; then
   LIBS="-lcraylm -lkrb -lnisdb -lnsl -lrpcsvc $LIBS"



configure output fragment:

checking for getdomainname... yes
checking for yp_all... no
checking for yp_all in -lnsl... yes


Oh, I guess you want a ChangeLog entry too:

1999-02-21  Martin Buchholz  <martin@xemacs.org>

	* Src/system.h: Only #include <libc.h> on NeXT systems.

	* configure.in: Check for domainname and yp_all separately.


After all these trials and tribulations, I managed to upgrade the zsh
on most of my systems to zsh-ext-2 and the PWD bug is gone!

Keep on saving the world,

Martin

Re: 2 patches included to fix configure brokenness

[Peter Stephenson]

Martin Buchholz wrote:
> Here's a real live tested patch that fixes it right.
> 
> --- configure.in.orig	Fri Jan  1 01:01:00 1999
> +++ configure.in	Fri Jan  1 01:01:00 1999
> @@ -353,6 +353,11 @@
>    AC_CHECK_LIB(nsl, getdomainname)
>  fi
>  
> +AC_CHECK_FUNCS(yp_all)
> +if test $ac_cv_func_yp_all = no; then
> +  AC_CHECK_LIB(nsl, yp_all)
> +fi
> +

This is already there in configure.in for 3.1.5: it replaces the
getdomainname() test --- presumably, unless that only got added to 3.0,
which has been known to happen.  The libc change is new.  Is it certain
that no-one apart from NeXT needs libc.h?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy