From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Zsh Hackers <zsh-workers@math.gatech.edu>
Subject: Re: PATCH: 3.1.5: ``***'' symlink follow broken
Date: Thu, 12 Nov 1998 09:21:46 -0800 [thread overview]
Message-ID: <981112092146.ZM11912@candle.brasslantern.com> (raw)
In-Reply-To: <9811121410.AA34177@ibmth.df.unipi.it>
On Nov 12, 3:10pm, Peter Stephenson wrote:
} Subject: Re: PATCH: 3.1.5: ``***'' symlink follow broken
}
} Geoff Wing wrote:
} > ``***'' recursive globbing with symlink follow has been broken
}
} It's amazing how the shell can totally break down without anyone
} noticing.
I must sheepishly admit that I only really use 3.1.x when I'm playing
with it or changing its code. The machine I use most of the day at
work has 3.0.5-extended installed.
} > This patch is probably suboptimal (possibly wrong)
}
} It works fine, but there's one minor tweak: you can still reject
} things that aren't directories (the test correctly uses stat(), not
} lstat(), so it may be a link to a directory), but the link count test
} doesn't apply when the directory could contain only symbolic links.
Yes, that's exactly the problem ... but ...
} The following patch is a replacement which does that. I can't imagine
} the difference is that important -- in fact, since the opendir() will
} fail if the thing isn't a directory, it's hard to see that the stat()
} at this point gains much at all. Unless someone knows something
} sinister about opendir()?
I *think* what's going on here is that `dirs' means the *next* level of
comparison needs to match directories inside which the final files may
reside. The stat() is intended to short-circuit the search when there
are no such subdirectories, before iterating through the entries in the
`while (zreaddir())' loop that follows. It's only a bonus that it also
avoids calling opendir() on a non-directory, and it's useless if the
link count test is invalid.
So *unless* somebody knows of a reason not to do opendir() on something
that isn't a directory, I think Geoff's patch is actually better [on the
assumption that a failed opendir() is faster than a successful stat()].
Late last night I was of the opinion that `closure' mattered more than
did `q->follow', but I've since revised that opinion.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1998-11-12 17:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-12 6:20 Geoff Wing
1998-11-12 10:04 ` Bart Schaefer
1998-11-12 14:10 ` Peter Stephenson
1998-11-12 14:58 ` Bruce Stephens
1998-11-12 17:21 ` Bart Schaefer [this message]
1998-11-13 8:55 ` Peter Stephenson
1998-11-13 6:59 ` Geoff Wing
1998-11-13 17:15 ` PATCH: */* broken (Re: PATCH: 3.1.5: ``***'' symlink follow broken) Bart Schaefer
1998-11-14 12:38 ` Geoff Wing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=981112092146.ZM11912@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).