From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
zsh-workers@sunsite.auc.dk
Subject: Re: Btw.: glob-qualifier
Date: Wed, 27 Jan 1999 21:35:29 -0800 [thread overview]
Message-ID: <990127213530.ZM31239@candle.brasslantern.com> (raw)
In-Reply-To: <199901261102.MAA20746@beta.informatik.hu-berlin.de>
On Jan 26, 12:02pm, Sven Wischnowsky wrote:
} Subject: Btw.: glob-qualifier
}
} effect of `(o<oct>)' is to match only files whose modes (all twelve
} bits) exactly match `<oct>'. Shouldn't we either document this or
} first make it a bit more usable and then document it?
Yes.
} E.g. we could
} make it take the next four characters which should be octal digits
} or `.'s, where `.' means that in this three-bit group any value is
} accepted
Oof. If you're going to make it usable, then REALLY make it usable.
At the risk of further abusing the already over-used parentheses, how
about (o(ug=w,o+r)) for "user and group must have exactly the write
bit set, and other must have at least r" and (o(u+x,go-w)) for "user
must have at least the execute bit set, and group and other must not
have write" and so on.
While I'm on the subject, why do we still have to use *numeric* group
and user IDs for the u and g qualifiers? Useless for portable scripts,
except possibly for (u0).
(I know, I know, it's slow and unpleasant to do passwd and groups file
lookups, and it's undefined what to do for names that don't exist.
Grumble.)
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-01-28 5:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-26 11:02 Sven Wischnowsky
1999-01-28 5:35 ` Bart Schaefer [this message]
[not found] <199901280754.IAA05492@beta.informatik.hu-berlin.de>
1999-01-28 8:36 ` Bart Schaefer
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=990127213530.ZM31239@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/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).