* Steve Greenland
| rant
|
| Except Solaris, whose /bin/sh doesn't support ~. Or aliases. Or brace
| expansion. Or the pattern matching expansions (i.e. ${VAR%foo} and
| friends). Or return outside of functions. Or shell arithmetic with let.
| Or '-p' for prompting on read. Etc. and so forth.
Colin Watson wrote:
Adam Heath wrote:
Guido Guenther wrote:
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
var=-f
Have you tried that? No POSIX shell will have a problem.
You are confusing standards with portability. They are not the same
On Mon, Sep 08, 2003 at 11:18:44PM -0600, Bob Proulx wrote:
Colin Watson wrote:
Adam Heath wrote:
Guido Guenther wrote:
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
var=-f
Have you tried that? No POSIX shell will have a problem.
On Sun, Sep 07, 2003 at 06:59:18PM +0100, Colin Watson wrote:
On Sun, Sep 07, 2003 at 11:58:03AM -0500, Steve Langasek wrote:
On Sun, Sep 07, 2003 at 06:08:06PM +0200, Thomas Hood wrote:
On Sun, 2003-09-07 at 17:23, Branden Robinson wrote:
Man, that's ugly. I use:
if [ -n $var
Sorry to give offense, Manoj. I should have grepped the whole chapter
before wondering about unknown, and I should have mentioned that I
really just use section 6.4 most of the time (because I *think* I
remember what each of the cases are for).
The fact that a non-version-number string literal
On Sun, Sep 07, 2003 at 09:42:40PM +0200, Josip Rodin wrote:
On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote:
Where did you come by this, and if it's something we should worry about,
why isn't it documented in Policy?
It is, but you shouldn't worry about it anyhow because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Branden Robinson [EMAIL PROTECTED] wrote:
[...]
The fact that a non-version-number string literal with shell redirection
operators in it was a valid value of old-version, new-version,
most-recently-configured-version, and so forth, did not occur to
On Mon, Sep 08, 2003 at 03:42:06AM -0500, Branden Robinson wrote:
On Sun, Sep 07, 2003 at 06:59:18PM +0100, Colin Watson wrote:
On Sun, Sep 07, 2003 at 11:58:03AM -0500, Steve Langasek wrote:
In general, no. If the contents of $var are a test operator, you'll get
a syntax error.
On Mon, Sep 08, 2003 at 03:48:37AM -0500, Branden Robinson wrote:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
both are not equivalent:
the first one test if var is empty or unset
the second one test if var is unset
with bash:
$ a=1 ;
On Mon, Sep 08, 2003 at 03:50:38AM -0500, Branden Robinson wrote:
Where did you come by this, and if it's something we should worry about,
why isn't it documented in Policy?
It is, but you shouldn't worry about it anyhow because nobody's crazy enough
to try doing anything with a dpkg
On 08-Sep-03, 03:42 (CDT), Branden Robinson [EMAIL PROTECTED] wrote:
I personally stongly advocate -n and -z over [ $var ] and really
horrible tests like:
if [ x$var = x ]
and
if [ x$var != x ]
Those just strike me as obscurantist (which might explain why they
feature prominently in
On Mon, Sep 08, 2003 at 10:10:34AM +0100, Colin Watson wrote:
On Mon, Sep 08, 2003 at 03:42:06AM -0500, Branden Robinson wrote:
But if $var contains more than one shell word...
You might get different results dependening on whether you remember to
quote the shell variable or not.
On Mon, Sep 08, 2003 at 11:11:34AM +0200, Andreas Metzler wrote:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
I agree, but usually use »[ x${var} != x ]« for no particular
reason but the fact that when reading it later I can discern
Branden Robinson wrote:
test -n and -z exist for a reason, even if one has to come up with
pretty dodgy mnemonics for remembering them.
-n Nonzero size string
-z Zero size string
Dodgy mnemonics? I find them very mnemonic!
Bob
pgpJpoX4Xwb2h.pgp
Description: PGP signature
Branden Robinson wrote:
I don't defend test(1) as a miracle of clarity, though. -h is a
synonym for -L. Go figure. :-/
I think you can blame BSD for that one. IIRC test -h was the original
option used to test for a symlink. Whoever wrote that test probably
did not like upper case letters
On Mon, 8 Sep 2003 03:48:37 -0500, Branden Robinson [EMAIL PROTECTED] said:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
...but I remain open to being directed to a section of the Policy
manual that firmly establishes my wrongness on that
On Mon, 08 Sep 2003 11:11:34 +0200, Andreas Metzler [EMAIL PROTECTED] said:
Branden Robinson [EMAIL PROTECTED] wrote: [...]
The fact that a non-version-number string literal with shell
redirection operators in it was a valid value of old-version,
new-version,
On Mon, Sep 08, 2003 at 10:14:46AM -0600, Bob Proulx wrote:
Today I can't find a system that does not implement 'test -L'.
Solaris' /bin/sh didn't do so at least up to 2.9. Of course, it's not a
POSIX shell in other ways anyway: for example, the lack of 'test -e' is
far more annoying and harder
Hi,
[I apologize for following up to this mail a second time;; I
should not post before I have had coffee]
On Mon, 8 Sep 2003 03:48:37 -0500, Branden Robinson [EMAIL PROTECTED] said:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set
On Sun, 7 Sep 2003, Guido Guenther wrote:
On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote:
if [ -n $var ]; then
fi
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
fi
var=-f
Manoj Srivastava [EMAIL PROTECTED] wrote:
On Mon, 08 Sep 2003 11:11:34 +0200, Andreas Metzler [EMAIL PROTECTED] said:
Branden Robinson [EMAIL PROTECTED] wrote: [...]
The fact that a non-version-number string literal with shell
redirection operators in it was a valid value of old-version,
On Mon, Sep 08, 2003 at 12:59:24PM -0500, Adam Heath wrote:
On Sun, 7 Sep 2003, Guido Guenther wrote:
On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote:
if [ -n $var ]; then
fi
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
On Sat, Sep 06, 2003 at 03:32:58PM -0500, Manoj Srivastava wrote:
case $1 in
configure)
# Configure this package. If the package must prompt the user for
# information, do it here.
# There are three sub-cases:
if test ${2+set} != set; then
Man, that's ugly. I use:
if [
Branden Robinson [EMAIL PROTECTED] wrote:
[postinst configure]
On Sat, Sep 06, 2003 at 03:32:58PM -0500, Manoj Srivastava wrote:
[...]
elif test -z $2 -o $2 = unknown; then
file:///usr/share/doc/debian-policy/policy.html/ch-maintainerscripts.html
is my Bible when I'm writing/editing
On Sun, 2003-09-07 at 17:23, Branden Robinson wrote:
Man, that's ugly. I use:
if [ -n $var ]; then
fi
I have been using
if [ $var ]; then
fi
I hope that's kosher too; otherwise I have a few scripts to fix.
for this sort of thing. However, that does depend on a certain other
On Sun, Sep 07, 2003 at 06:08:06PM +0200, Thomas Hood wrote:
On Sun, 2003-09-07 at 17:23, Branden Robinson wrote:
Man, that's ugly. I use:
if [ -n $var ]; then
fi
I have been using
if [ $var ]; then
fi
I hope that's kosher too; otherwise I have a few scripts to fix.
In
On Sun, 7 Sep 2003 11:58:03 -0500, Steve Langasek wrote:
On Sun, Sep 07, 2003 at 06:08:06PM +0200, Thomas Hood wrote:
[...]
I have been using
if [ $var ]; then
fi
I hope that's kosher too; otherwise I have a few scripts to fix.
In general, no. If the contents of $var are
On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote:
if [ -n $var ]; then
fi
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
fi
-- Guido
pgpeYjAwFH0tB.pgp
Description: PGP signature
On Sun, Sep 07, 2003 at 11:58:03AM -0500, Steve Langasek wrote:
On Sun, Sep 07, 2003 at 06:08:06PM +0200, Thomas Hood wrote:
On Sun, 2003-09-07 at 17:23, Branden Robinson wrote:
Man, that's ugly. I use:
if [ -n $var ]; then
fi
I have been using
if [ $var ]; then
On Sun, 7 Sep 2003 10:23:15 -0500, Branden Robinson [EMAIL PROTECTED] said:
On Sat, Sep 06, 2003 at 03:32:58PM -0500, Manoj Srivastava wrote:
case $1 in configure)
# Configure this package. If the package must prompt the user for
# information, do it here. There are three sub-cases:
if
On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote:
Where did you come by this, and if it's something we should worry about,
why isn't it documented in Policy?
It is, but you shouldn't worry about it anyhow because nobody's crazy enough
to try doing anything with a dpkg that old
On Sun, 7 Sep 2003 07:24:42 +0200, Martin Godisch [EMAIL PROTECTED] said:
On Sat, Sep 06, 2003 at 15:32:58 -0500, Manoj Srivastava wrote:
case $1 in configure)
# Configure this package. If the package must prompt the user for
# information, do it here. There are three sub-cases:
if test
Guido Guenther wrote:
Branden Robinson wrote:
if [ -n $var ]; then
I always prefer this myself too. It is portable.
Just of out curiosity, is this in any way different from the shorter:
if [ $var ]; then
For Debian, no. But for those of us trying to program portably across
systems, yes.
[Bastian Blank]
i think the scripts should follow the update-X naming schema.
Because update-foo usually has different semantics, i.e. rebuilding a file
(like /etc/modules.conf) from a directory of file.
There might be an update-shells that does this someday; if there is, it
will probably get
Martin == Martin Godisch [EMAIL PROTECTED] writes:
Martin and the entry in /etc/shells should be added again, since it was
Martin there when we begun. How does the postinst know that this is no
Martin upgrade? Why doesn't add-shell care for this, so the postinst
Martin can
On Sat, 6 Sep 2003 20:56:00 +0200, Martin Godisch [EMAIL PROTECTED] said:
My question is: How does the postinst know whether it is an initial
install? How does it know, whether the entry is missing because the
sysadmin took it out, or because it was removed when the package was
removed but
[Bastian Blank]
i think the scripts should follow the update-X naming schema.
I agree. That would make it consistent of most of the Debian packages
providing such hooks.
On Fri, Aug 22, 2003 at 10:56:22PM -0400, [EMAIL PROTECTED] wrote:
/etc/shells is no longer a config file, but is maintained by the
add-shell and remove-shell programs. So, if a package contains
something that the maintainer thinks ought to be a valid login shell,
it's postinst should, (on
*
| I just uploaded a version of shadow that provides scripts for the
| maintenance of /etc/shells. I decided very quickly when I became the
| shadow maintainer that I didn't want to (and probably wasn't qualified to
| be) an arbiter of acceptable shells.
Why wasn't this sent to
Martin == Martin Godisch [EMAIL PROTECTED] writes:
Martin What's the preferred way to do this check? Consider, some shell
Martin is installed with its appropriate entry in /etc/shells. Now, we
Martin remove it: the entry will be deleted from /etc/shells, which
Martin makes sense,
I just uploaded a version of shadow that provides scripts for the
maintenance of /etc/shells. I decided very quickly when I became the
shadow maintainer that I didn't want to (and probably wasn't qualified to
be) an arbiter of acceptable shells.
So:
/etc/shells is no longer a config file, but
41 matches
Mail list logo
