weird zsh startup behavior

weird zsh startup behavior

[John M. Harres]

# pwd
/home/lsims
# zsh
lanshark# pwd
/home/sinclair

Does anyone know under what circumstances zsh will change directory on 
startup?  I was in root under sh, ran zsh, and zappo, switched directories, 
and not to root's home directory.  Both home directories are automounted.

Hohn Harres
harres@uwyo.edu

Re: weird zsh startup behavior

[Zoltan Hidvegi]

> # pwd
> /home/lsims
> # zsh
> lanshark# pwd
> /home/sinclair
> 
> Does anyone know under what circumstances zsh will change directory on 
> startup?  I was in root under sh, ran zsh, and zappo, switched directories, 
> and not to root's home directory.  Both home directories are automounted.

We can only fix this problem if you provide more details about the
problem.  What zsh version, OS, OS version, libc version, compiler are
you using?  Can you reproduce this with zsh -f?  If not, try to find the
command in you startup files which triggers the problem.

Zoltan

Re: weird zsh startup behavior

[John M. Harres]

On Fri 8 Aug 1997, Zoltan Hidvegi wrote:

> > Does anyone know under what circumstances zsh will change directory on 
> > startup?  I was in root under sh, ran zsh, and zappo, switched directories,
> > and not to root's home directory.  Both home directories are automounted.
> 
> We can only fix this problem if you provide more details about the
> problem.  What zsh version, OS, OS version, libc version, compiler are
> you using?  Can you reproduce this with zsh -f?  If not, try to find the
> command in you startup files which triggers the problem.

Sorry, brain on hold.  zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc
Sun ships withe Solaris 2.5.1.

Reproduced with zsh -f:

# pwd
/home/lsims
# zsh -f
lanshark:/home/sinclair# pwd
/home/sinclair

I've also checked to make sure both users have unique uid's and home dirs,
which both do.  Also, the auto_home file points correctly to two different
directories.

John Harres
harres@uwyo.edu

Re: weird zsh startup behavior

[Geoff Wing]

John M. Harres <harres@UWYO.EDU> typed:
:On Fri 8 Aug 1997, Zoltan Hidvegi wrote:
:> > Does anyone know under what circumstances zsh will change directory on 
:> > startup?  I was in root under sh, ran zsh, and zappo, switched directories,
:> > and not to root's home directory.  Both home directories are automounted.
:> We can only fix this problem if you provide more details about the
:> problem.  What zsh version, OS, OS version, libc version, compiler are
:> you using?  Can you reproduce this with zsh -f?  If not, try to find the
:> command in you startup files which triggers the problem.
:Sorry, brain on hold.  zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc
:Sun ships withe Solaris 2.5.1.
:Reproduced with zsh -f:

Can you reproduce it with "zsh -f" and no /etc/zshenv?
-- 
Geoff Wing [mason@primenet.com.au]                   Phone    : +61-3-9818 2977 
 Technical Manager: PrimeNet Computer Consultants    Facsimile: +61-3-9819 3788 
 Web: <URL:http://www.primenet.com.au/>              Mobile   : 0412 162 441
        [ Boulderdash: <URL:http://ciips.ee.uwa.edu.au/~williams/bd/> ]

Re: weird zsh startup behavior

[John M. Harres]

On Sat 9 Aug 1997, Geoff Wing wrote:

> John M. Harres <harres@UWYO.EDU> typed:
> :On Fri 8 Aug 1997, Zoltan Hidvegi wrote:
> :> > Does anyone know under what circumstances zsh will change directory on 
> :> > startup?  I was in root under sh, ran zsh, and zappo, switched directori
> es,
> :> > and not to root's home directory.  Both home directories are automounted
> .
> :> We can only fix this problem if you provide more details about the
> :> problem.  What zsh version, OS, OS version, libc version, compiler are
> :> you using?  Can you reproduce this with zsh -f?  If not, try to find the
> :> command in you startup files which triggers the problem.
> :Sorry, brain on hold.  zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc
> :Sun ships withe Solaris 2.5.1.
> :Reproduced with zsh -f:
> 
> Can you reproduce it with "zsh -f" and no /etc/zshenv?

With no /etc/z* /.z* (I was running as root), still the same problem.

Further:

It seems to occur when I'm in any user's home directory who has a local home
directory (as opposed to those with remote automounted home directories) as
long as that home directory is automounted.

I've tried it on another virtually identical system, with similar, though not
quite the same, results:

ghidora% su                                                                   ~
Password:
# cd /home/bthomas
# zsh -f
ghidora:/home/harres# pwd
/home/harres

There is no consistency with the order of the auto_home file, nor the passwd
file for deriving the 'magic' user you end up in the home directory of.

Let me know if there's anything else I can provide.

John Harres
harres@uwyo.edu

Re: weird zsh startup behavior

[Todd Larason]

On Sat, Aug 09, 1997 at 05:11:53AM +0000, Geoff Wing wrote:
> John M. Harres <harres@UWYO.EDU> typed:
> :On Fri 8 Aug 1997, Zoltan Hidvegi wrote:
> :> > Does anyone know under what circumstances zsh will change directory on 
> :> > startup?  I was in root under sh, ran zsh, and zappo, switched directories,
> :> > and not to root's home directory.  Both home directories are automounted.
> :> We can only fix this problem if you provide more details about the
> :> problem.  What zsh version, OS, OS version, libc version, compiler are
> :> you using?  Can you reproduce this with zsh -f?  If not, try to find the
> :> command in you startup files which triggers the problem.
> :Sorry, brain on hold.  zsh 3.0.4, Solaris 2.5.1, gcc-2.7.2.2, whatever libc
> :Sun ships withe Solaris 2.5.1.
> :Reproduced with zsh -f:
> 
> Can you reproduce it with "zsh -f" and no /etc/zshenv?

Ack, I never wrote the list about this, did I?

I saw this on a similar setup - Solaris 2.4, home directories automounted,
zsh 3.0 betas I think.  I no longer have access to this system, so I can't
double check the details, but they're not terribly important.

The problem was an assumption made in zgetcwd(), which didn't hold with
the automounted home dirs.  I don't seem to have the patch I made, and I'm
going on foggy memory here I'm afraid.

Anything that caused a zgetcwd() would end up *changing* the current
directory.

Looking at zgetcwd, I'm thinking that the false assumption was that only
one mountpoint could have the same device number ("if (sbuf.st_dev == dev)
goto match;" around lines 178-179 in 3.0.4:compat.c).  With sun's
automounter, with multiple directories from the same device mounted into
the same directory, this wasn't true.  I assume my fix was to check the
inode too.

Sorry this is so vague and wishy washy, but hopefully it will save some
time tracking down the details.

Re: weird zsh startup behavior

[John M. Harres]

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

On Sun 10 Aug 1997, Todd Larason wrote:

> On Sat, Aug 09, 1997 at 05:11:53AM +0000, Geoff Wing wrote:
> > John M. Harres <harres@UWYO.EDU> typed:
> > > Does anyone know under what circumstances zsh will change directory on
> > > startup?  I was in root under sh, ran zsh, and zappo, switched directories,
> > > and not to root's home directory.  Both home directories are automounted.

> I saw this on a similar setup - Solaris 2.4, home directories automounted,
> zsh 3.0 betas I think.  I no longer have access to this system, so I can't
> double check the details, but they're not terribly important.
> 
> The problem was an assumption made in zgetcwd(), which didn't hold with
> the automounted home dirs.  I don't seem to have the patch I made, and I'm
> going on foggy memory here I'm afraid.
> 
> Anything that caused a zgetcwd() would end up *changing* the current
> directory.
> 
> Looking at zgetcwd, I'm thinking that the false assumption was that only
> one mountpoint could have the same device number ("if (sbuf.st_dev == dev)
> goto match;" around lines 178-179 in 3.0.4:compat.c).  With sun's
> automounter, with multiple directories from the same device mounted into
> the same directory, this wasn't true.  I assume my fix was to check the
> inode too.

Trying to look into this further, I'm getting further confused.  zgetcwd() 
appears to do some checks, then opens '..' scanning for the directory we are 
(were since there's a chdir()) in.  If that is not found, it then scans '.', 
but since we did a chdir("..") after opendir(".."), the second opendir should 
be opening the same directory as the first.

The second directory scan does not have the inode check, as you mentioned, but 
if it's there, the two loops look like they should either both succeed or 
fail, thus the second adds nothing.

What is the second loop intended to do?

I also don't understand when the first loop would fail.  It simply looks for
the dev & ino that match "." in the dirent's for "..".  What conditions will is
that trying to catch?

Sorry for my lack of understanding.  It's my first dive into the zsh source.

John


[-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --]

Re: weird zsh startup behavior

[Todd Larason]

On Tue, Aug 12, 1997 at 09:31:58AM -0600, John M. Harres wrote:
> The second directory scan does not have the inode check, as you mentioned, but 
> if it's there, the two loops look like they should either both succeed or 
> fail, thus the second adds nothing.

I'm not where I can look at the source right now, but my memory is that
the second one stat()s each file as it goes along, and used the dev number
from that;  I'm assuming that's intended to find mounted file systems --
readdir() gives info on the directory being mounted over, stat() gives
info on the mounted dir.

Re: weird zsh startup behavior

[John M. Harres]

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

Well, this rather trivial patch seems to work.  Please let me know if there's
anything I've done wrong.

I'm beginning to think the second loop is intended to handle the current 
directory being a symlink.  For that reason, I'm checking the lstat's results' 
inode rather than the directory entry's, although again, I'm not completely 
sure under what circumstances these will differ.

John

*** compat.c.old        Tue Dec 17 13:14:11 1996
--- compat.c    Tue Aug 12 09:56:21 1997
***************
*** 176,182 ****
                 (fn[1] == '.' && fn[2] == '\0')))
                continue;
            lstat(fn, &sbuf);
!           if (sbuf.st_dev == dev)
                goto match;
        }
        noholdintr();
--- 176,182 ----
                 (fn[1] == '.' && fn[2] == '\0')))
                continue;
            lstat(fn, &sbuf);
!           if (sbuf.st_dev == dev && sbuf.st_ino == ino)
                goto match;
        }
        noholdintr();



[-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --]

zgetcwd patch?

[John M. Harres]

I never heard a response to the patch I sent to compat.c.
Does it appear correct?

I'm also curious under what circumstances these two operations differ (aside
from the obvious chdir side effect):

1. opendir( ".." );

2. chdir( ".." );
	opendir( "." );

Thanks,
John Harres
harres@uwyo.edu

Re: zgetcwd patch?

[Bart Schaefer]

On Aug 15,  7:15am, John M. Harres wrote:
} Subject: zgetcwd patch?
}
} I never heard a response to the patch I sent to compat.c.

Just so you know someone's paying attention ...

} Does it appear correct?

It doesn't look wrong to me, but I'm not sure why it wasn't used in the
first place, so I can't say for certain.  My guess is that there was an
assumption of at most one mount of the same device in any given directory,
so the second loop is (before your patch) finding any mount point matching
the device and assuming that must be the one.

Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

} I'm also curious under what circumstances these two operations differ (aside
} from the obvious chdir side effect):
} 
} 1. opendir( ".." );
} 
} 2. chdir( ".." );
} 	opendir( "." );

It could have something to do with crossing NFS mount points.  I can't
figure out precisely what, though, as I don't have any NFS-mounted
filesystems to try it on.

More likely, though, it's just expediency.  The chdir("..") is done so
that lstat() can be called directly on de->d_name.  There's probably no
reason that
	closedir(dir);
	dir = opendir(".");
could not be replaced by
	rewinddir(dir);
unless maybe there's some implementation of the directory library out
there that doesn't have rewinddir().

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

Re: zgetcwd patch?

[John M. Harres]

On Sun 17 Aug 1997, Bart Schaefer wrote:

> It doesn't look wrong to me, but I'm not sure why it wasn't used in the
> first place, so I can't say for certain.  My guess is that there was an
> assumption of at most one mount of the same device in any given directory,
> so the second loop is (before your patch) finding any mount point matching
> the device and assuming that must be the one.
> 
> Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

I'm not sure.  I originally made the test de->d_ino == ino instead of 
sbuf.st_ino == ino, and this made both loops the same, thus either both failed
or both succeeded.  I decided to try the second, since the info was there as
well, and it worked.

> 
> } I'm also curious under what circumstances these two operations differ (asid
> e
> } from the obvious chdir side effect):
> } 
> } 1. opendir( ".." );
> } 
> } 2. chdir( ".." );
> } 	opendir( "." );
> 
> It could have something to do with crossing NFS mount points.  I can't
> figure out precisely what, though, as I don't have any NFS-mounted
> filesystems to try it on.
> 
> More likely, though, it's just expediency.  The chdir("..") is done so
> that lstat() can be called directly on de->d_name.  There's probably no
> reason that
> 	closedir(dir);
> 	dir = opendir(".");
> could not be replaced by
> 	rewinddir(dir);
> unless maybe there's some implementation of the directory library out
> there that doesn't have rewinddir().

I'm almost convinced that the second loop could be avoided with some careful
if'ing.  On the other hand, the first loop may be to handle the most common
case, and the second to handle that rare case that was biting me.  This might
save performance-wise, as it skips the lstat in most cases, only resorting to
it if it fails to find the current directory without it.

At this point, I'm satisfied leaving it alone, since it works.

Thanks!
John

Re: zgetcwd patch?

[Todd Larason]

On Sun, Aug 17, 1997 at 10:05:53PM -0700, Bart Schaefer wrote:
> It doesn't look wrong to me, but I'm not sure why it wasn't used in the
> first place, so I can't say for certain.  My guess is that there was an
> assumption of at most one mount of the same device in any given directory,
> so the second loop is (before your patch) finding any mount point matching
> the device and assuming that must be the one.
> 
> Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

My understanding was that the first loop would find the parent if it was
in the same filesystem as the child; the second would find the place the
child was mounted, in the only other case.

The problem is that it was assumed that a filesystem can only be mounted
one place, and that the device number identifies filesystems.

In this situation, there's /home on filesystem one, /home/a and /home/b
are both automounted directories from filesystem 2.

for a and b, de->d_ino is the inode of the mountpoint directory in /home,
in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in
filesystem 2.

> } I'm also curious under what circumstances these two operations differ (aside
> } from the obvious chdir side effect):
> } 
> } 1. opendir( ".." );
> } 
> } 2. chdir( ".." );
> } 	opendir( "." );

These do the same thing; the only important difference is that the second
lstat()s and compares that info instead of the directory info.

These could be combined into one loop, but you don't really want to stat
unless you have to.

From zsh-workers-request@math.gatech.edu Mon Aug 18 20:21:04 1997
Return-Path: <zsh-workers-request@math.gatech.edu>
Delivered-To: mason@primenet.com.au
Received: (qmail 14552 invoked from network); 18 Aug 1997 20:21:02 -0000
Received: from euclid.skiles.gatech.edu (HELO euclid.math.gatech.edu) (root@130.207.146.50)
  by coral.primenet.com.au with SMTP; 18 Aug 1997 20:21:02 -0000
Received: (from list@localhost)
	by euclid.skiles.gatech.edu (8.8.5/8.8.5) id PAA09012;
	Mon, 18 Aug 1997 15:50:17 -0400 (EDT)
Resent-Date: Mon, 18 Aug 1997 15:50:17 -0400 (EDT)
Message-ID: <19970818124801.25766@molehill.org>
Date: Mon, 18 Aug 1997 12:48:01 -0700
From: Todd Larason <jtl@molehill.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: "John M. Harres" <harres@ghidora.uwyo.edu>, zsh-workers@math.gatech.edu
Subject: Re: zgetcwd patch?
References: <199708151315.HAA24323@ghidora.uwyo.edu> <970817220553.ZM23929@candle.brasslantern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76e
In-Reply-To: <970817220553.ZM23929@candle.brasslantern.com>; from Bart Schaefer on Sun, Aug 17, 1997 at 10:05:53PM -0700
Resent-Message-ID: <"30PCq2.0.iC2.uTA-p"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3448
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

On Sun, Aug 17, 1997 at 10:05:53PM -0700, Bart Schaefer wrote:
> It doesn't look wrong to me, but I'm not sure why it wasn't used in the
> first place, so I can't say for certain.  My guess is that there was an
> assumption of at most one mount of the same device in any given directory,
> so the second loop is (before your patch) finding any mount point matching
> the device and assuming that must be the one.
> 
> Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

My understanding was that the first loop would find the parent if it was
in the same filesystem as the child; the second would find the place the
child was mounted, in the only other case.

The problem is that it was assumed that a filesystem can only be mounted
one place, and that the device number identifies filesystems.

In this situation, there's /home on filesystem one, /home/a and /home/b
are both automounted directories from filesystem 2.

for a and b, de->d_ino is the inode of the mountpoint directory in /home,
in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in
filesystem 2.

> } I'm also curious under what circumstances these two operations differ (aside
> } from the obvious chdir side effect):
> } 
> } 1. opendir( ".." );
> } 
> } 2. chdir( ".." );
> } 	opendir( "." );

These do the same thing; the only important difference is that the second
lstat()s and compares that info instead of the directory info.

These could be combined into one loop, but you don't really want to stat
unless you have to.

From zsh-workers-request@math.gatech.edu Tue Aug 19 00:52:25 1997
Return-Path: <zsh-workers-request@math.gatech.edu>
Delivered-To: mason@primenet.com.au
Received: (qmail 15686 invoked from network); 19 Aug 1997 00:52:23 -0000
Received: from euclid.skiles.gatech.edu (HELO math.gatech.edu) (root@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 19 Aug 1997 00:52:23 -0000
Received: (from list@localhost)
	by euclid.skiles.gatech.edu (8.8.5/8.8.5) id PAA09012;
	Mon, 18 Aug 1997 15:50:17 -0400 (EDT)
Resent-Date: Mon, 18 Aug 1997 15:50:17 -0400 (EDT)
Message-ID: <19970818124801.25766@molehill.org>
Date: Mon, 18 Aug 1997 12:48:01 -0700
From: Todd Larason <jtl@molehill.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: "John M. Harres" <harres@ghidora.uwyo.edu>, zsh-workers@math.gatech.edu
Subject: Re: zgetcwd patch?
References: <199708151315.HAA24323@ghidora.uwyo.edu> <970817220553.ZM23929@candle.brasslantern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76e
In-Reply-To: <970817220553.ZM23929@candle.brasslantern.com>; from Bart Schaefer on Sun, Aug 17, 1997 at 10:05:53PM -0700
Resent-Message-ID: <"30PCq2.0.iC2.uTA-p"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3448
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

On Sun, Aug 17, 1997 at 10:05:53PM -0700, Bart Schaefer wrote:
> It doesn't look wrong to me, but I'm not sure why it wasn't used in the
> first place, so I can't say for certain.  My guess is that there was an
> assumption of at most one mount of the same device in any given directory,
> so the second loop is (before your patch) finding any mount point matching
> the device and assuming that must be the one.
> 
> Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?

My understanding was that the first loop would find the parent if it was
in the same filesystem as the child; the second would find the place the
child was mounted, in the only other case.

The problem is that it was assumed that a filesystem can only be mounted
one place, and that the device number identifies filesystems.

In this situation, there's /home on filesystem one, /home/a and /home/b
are both automounted directories from filesystem 2.

for a and b, de->d_ino is the inode of the mountpoint directory in /home,
in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in
filesystem 2.

> } I'm also curious under what circumstances these two operations differ (aside
> } from the obvious chdir side effect):
> } 
> } 1. opendir( ".." );
> } 
> } 2. chdir( ".." );
> } 	opendir( "." );

These do the same thing; the only important difference is that the second
lstat()s and compares that info instead of the directory info.

These could be combined into one loop, but you don't really want to stat
unless you have to.

Re: zgetcwd patch?

[Bart Schaefer]

On Aug 18, 12:48pm, Todd Larason wrote:
} Subject: Re: zgetcwd patch?
}
} On Sun, Aug 17, 1997 at 10:05:53PM -0700, Bart Schaefer wrote:
} > It doesn't look wrong to me, but I'm not sure why it wasn't used in the
} > first place, so I can't say for certain.  My guess is that there was an
} > assumption of at most one mount of the same device in any given directory,
} > so the second loop is (before your patch) finding any mount point matching
} > the device and assuming that must be the one.
} > 
} > Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?
} 
} My understanding was that the first loop would find the parent if it was
} in the same filesystem as the child; the second would find the place the
} child was mounted, in the only other case.

No; both loops are looking for the child's entry in the parent.  The
first looks for entries with the same inode number, then uses lstat to
see if the device number is also the same.  If no entry has the same
inode and device, the second loop uses lstat to look for any entry that
has the same device number as the child.

} The problem is that it was assumed that a filesystem can only be mounted
} one place, and that the device number identifies filesystems.

That part, I believe to be a correct description.

} In this situation, there's /home on filesystem one, /home/a and /home/b
} are both automounted directories from filesystem 2.
} 
} for a and b, de->d_ino is the inode of the mountpoint directory in /home,
} in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in
} filesystem 2.

In that case I also believe John's zgetcwd patch to be correct.  I think
the process could be sped up a bit by replacing the closedir() + opendir()
with a rewinddir(), as I mentioned before.

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

Re: zgetcwd patch?

[Zoltan Hidvegi]

> I never heard a response to the patch I sent to compat.c.
> Does it appear correct?
> 
> I'm also curious under what circumstances these two operations differ (aside
> from the obvious chdir side effect):
> 
> 1. opendir( ".." );
> 
> 2. chdir( ".." );
> 	opendir( "." );

Sorry for my silence about this.  Zsh-3.1.1 already had a fix for this
promlem, here is the patch for zsh-3.0.4.  It avoids the double scan you
noticed.

Zoltan


*** compat.c.3.0.4	Tue Dec 17 15:14:11 1996
--- compat.c	Mon Aug 25 00:58:18 1997
***************
*** 115,122 ****
      struct stat sbuf;
      struct dirent *de;
      DIR *dir;
!     ino_t ino, rootino = (ino_t) ~ 0;
!     dev_t dev, rootdev = (dev_t) ~ 0;
  
      holdintr();
      buf2[0] = '\0';
--- 115,122 ----
      struct stat sbuf;
      struct dirent *de;
      DIR *dir;
!     ino_t ino, pino, rootino = (ino_t) ~ 0;
!     dev_t dev, pdev, rootdev = (dev_t) ~ 0;
  
      holdintr();
      buf2[0] = '\0';
***************
*** 127,146 ****
  	rootdev = sbuf.st_dev;
      }
  
      for (;;) {
- 	if (stat(".", &sbuf) < 0) {
- 	    chdir(buf0);
- 	    noholdintr();
- 	    return ztrdup(".");
- 	}
- 	ino = sbuf.st_ino;
- 	dev = sbuf.st_dev;
  	if (stat("..", &sbuf) < 0) {
  	    chdir(buf0);
  	    noholdintr();
  	    return ztrdup(".");
  	}
! 	if ((sbuf.st_ino == ino && sbuf.st_dev == dev) ||
  	    (ino == rootino && dev == rootdev)) {
  	    chdir(buf0);
  	    noholdintr();
--- 127,153 ----
  	rootdev = sbuf.st_dev;
      }
  
+     if (stat(".", &sbuf) < 0) {
+ 	noholdintr();
+ 	return ztrdup(".");
+     }
+ 
+     pino = sbuf.st_ino;
+     pdev = sbuf.st_dev;
+ 
      for (;;) {
  	if (stat("..", &sbuf) < 0) {
  	    chdir(buf0);
  	    noholdintr();
  	    return ztrdup(".");
  	}
! 
! 	ino = pino;
! 	dev = pdev;
! 	pino = sbuf.st_ino;
! 	pdev = sbuf.st_dev;
! 
! 	if ((ino == pino && dev == pdev) ||
  	    (ino == rootino && dev == rootdev)) {
  	    chdir(buf0);
  	    noholdintr();
***************
*** 160,194 ****
  		(fn[1] == '\0' ||
  		 (fn[1] == '.' && fn[2] == '\0')))
  		continue;
! 	    if ((ino_t) de->d_ino == ino) {
  		lstat(fn, &sbuf);
! 		if (sbuf.st_dev == dev)
! 		    goto match;
  	    }
  	}
  	closedir(dir);
! 	dir = opendir(".");
! 	while ((de = readdir(dir))) {
! 	    char *fn = de->d_name;
! 	    /* Ignore `.' and `..'. */
! 	    if (fn[0] == '.' &&
! 		(fn[1] == '\0' ||
! 		 (fn[1] == '.' && fn[2] == '\0')))
! 		continue;
! 	    lstat(fn, &sbuf);
! 	    if (sbuf.st_dev == dev)
! 		goto match;
  	}
- 	noholdintr();
- 	closedir(dir);
- 	return ztrdup(".");
-       match:
- 	strcpy(buf3, de->d_name);
  	if (*buf2)
  	    strcat(buf3, "/");
  	strcat(buf3, buf2);
  	strcpy(buf2, buf3);
- 	closedir(dir);
      }
  }
  
--- 167,189 ----
  		(fn[1] == '\0' ||
  		 (fn[1] == '.' && fn[2] == '\0')))
  		continue;
! 	    if (dev != pdev || (ino_t) de->d_ino == ino) {
  		lstat(fn, &sbuf);
! 		if (sbuf.st_dev == dev && sbuf.st_ino == ino) {
! 		    strcpy(buf3, de->d_name);
! 		    break;
! 		}
  	    }
  	}
  	closedir(dir);
! 	if (!de) {
! 	    noholdintr();
! 	    return ztrdup(".");
  	}
  	if (*buf2)
  	    strcat(buf3, "/");
  	strcat(buf3, buf2);
  	strcpy(buf2, buf3);
      }
  }
  

zsh-3.0.4 blessed patches (was Re: zgetcwd patch?)

[Mark Borges]

>> On Mon, 25 Aug 1997 01:06:54 -0400 (EDT),
>> Zoltan Hidvegi(ZH) wrote:
[...]
ZH> Sorry for my silence about this.  Zsh-3.1.1 already had a fix for
ZH> this promlem, here is the patch for zsh-3.0.4.  It avoids the
ZH> double scan you noticed.

I'm running the stock zsh-3.0.4. I've noticed there have been a few
patches since it's been released, and I lost track of which ones are
"must haves". Can someone (Zoltan?) suggest a list of "blessed"
patches? Alternatively, are there plans for a 3.0.5 release (I'm not
ready to install 3.1.1 here yet).

Thanks.

-- 
  -mb-

Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?)

[Zoltan T. Hidvegi]

Mark Borges wrote:
> patches? Alternatively, are there plans for a 3.0.5 release (I'm not
> ready to install 3.1.1 here yet).

Yes, there will be a zsh-3.0.5 release.

Zoltan

Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?)

[Geoff Wing]

hzoli@VNET.IBM.COM <hzoli@VNET.IBM.COM> typed:
:Mark Borges wrote:
:> patches? Alternatively, are there plans for a 3.0.5 release (I'm not
:> ready to install 3.1.1 here yet).
:Yes, there will be a zsh-3.0.5 release.

Any timeline on that?  I just got half way through sending in another bug
report last night til I remembered seeing something similar and grep'd through
the list for it.  Lucky I keep all the old messages :-)
-- 
Geoff Wing [mason@primenet.com.au]                   Phone    : +61-3-9818 2977 
 Technical Manager: PrimeNet Computer Consultants    Facsimile: +61-3-9768 2909
 Web: <URL:http://www.primenet.com.au/>              Mobile   : 0412 162 441
        [ Boulderdash: <URL:http://ciips.ee.uwa.edu.au/~williams/bd/> ]

Re: zsh-3.0.4 blessed patches (was Re: zgetcwd patch?)

[Zoltan Hidvegi]

> :Yes, there will be a zsh-3.0.5 release.
> 
> Any timeline on that?  I just got half way through sending in another bug
> report last night til I remembered seeing something similar and grep'd through
> the list for it.  Lucky I keep all the old messages :-)

I hope this week.  The (ab#)# glob bug will probably not be fixed in
the 3.0 series, since I suspect that this will require a lot of
changes in the glob code.

Zoltan