zsh-workers
 help / color / mirror / code / Atom feed
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


  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).