From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: [9fans] Globbing
Date: Fri, 19 Mar 2004 16:59:58 +0200 [thread overview]
Message-ID: <ce6cb00ea1f805982bdc92b17424872c@proxima.alt.za> (raw)
For the record, I have no trouble agreeing with dvd, although I'm
speaking from a weak position: I have not explored all the possible
consequences of changing the globbing rules to remove duplications.
I think forsyth put his agnostic view rather well, but in my opinion
applying a uniqueness filter would be esthetically preferable.
As for consequences, here are a few data points.
* I don't think there are any advantages to retaining duplicates, they
just clutter scripts that have to deal with them.
* It isn't always possible and it is never clean to apply filtering to
the output of the globbing operation. At least, to the best of my
knowledge. We are talking about the command line, here. A
particular ugly case would be
> x*
just to stir the pot a little further. But of course that could be
taken as an argument in favour of either standpoint.
* It is a change in the league of another similarly controversial
difference between rc and the traditional Unix shells (or is it
exec(2)?). Lack of a leading /, ./ or ../ allows rc to use the "path"
variable to determine the origin of an executable, whereas the
presence of a slash anywhere in the command name suppresses this
behaviour in traditional Unix shells.
You should have seen the confusion, consternation and outright
resentment a question on this last subject caused on a NetBSD mailing
list. It didn't help that I used the term "absolute" to describe a
pathname starting with /, ./ or ../ and "relative" for one that
didn't.
++L
PS: One NetBSD contributor suggested making up a version of the shell
with behaviour more similar to rc's. I refrained from pointing out
that rc was as good as I needed, in that case.
next reply other threads:[~2004-03-19 14:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-19 14:59 lucio [this message]
2004-03-19 15:05 Tiit Lankots
2004-03-19 15:13 ` lucio
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=ce6cb00ea1f805982bdc92b17424872c@proxima.alt.za \
--to=lucio@proxima.alt.za \
--cc=9fans@cse.psu.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.
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).