Re: [EVEN MORE OFFTOPIC] Re: /etc/shells management
* 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.
or «local», which leads to nice and clean code like:
#! /bin/sh
# SunOS /bin/sh is broken wrt local. *sigh*
if test `uname -s` = SunOS -a $RUNNING_UNDER_BASH = ; then
RUNNING_UNDER_BASH=1
export RUNNING_UNDER_BASH
exec bash $0 $@
fi
hoping that bash is somewhere in the path.
| /rant
--
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Re: /etc/shells management
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 thing. See my other posting for a real world example of this particular construct which fails on a shell on a commercial system which claims to be a POSIX shell. It probably is compliant to an older version of the standard. But standards change over time and just by standing still you fall behind. This particular construct is not portable to that system regardless of the presence of standards. I am not saying that Debian dpkg scripts should worry about strange or non-standard systems, nor indeed any non-Debian systems at all. I am just talking about portable script style and advocating defensive programming in general. Bob pgpNm7Dq74zIX.pgp Description: PGP signature
Re: /etc/shells management
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. You are confusing standards with portability. They are not the same thing. See my other posting for a real world example of this particular construct which fails on a shell on a commercial system which claims to be a POSIX shell. It probably is compliant to an older version of the standard. But standards change over time and just by standing still you fall behind. This particular construct is not portable to that system regardless of the presence of standards. I am not saying that Debian dpkg scripts should worry about strange or non-standard systems, nor indeed any non-Debian systems at all. I am just talking about portable script style and advocating defensive programming in general. Since I'm talking exclusively about postinst scripts, though, I see absolutely no reason why we shouldn't use cleaner and more understandable POSIX interfaces where they're available. When programming specifically for Debian I do not want to worry about the vagaries of ancient non-free operating systems. Programming to standards is good enough. I'm not confusing standards with portability - I'm aware that certain legacy systems have problems with this construct - but I choose not to care in this instance. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
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 ]; 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 general, no. If the contents of $var are a test operator, you'll get a syntax error. POSIX requires this not to be the case, because of the argument-counting algorithm that 'test' is supposed to follow. See http://www.opengroup.org/onlinepubs/007904975/utilities/test.html. 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. My own preliminary tests leave this unclear. :) Probably not worth leaving to the vagaries of shell implementations, anyway. It's just too unpredictable to rely upon. Especially if $var can be a variable that is derived from user input without Stalinistic validation. 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 shell scripts by Ian Jackson, heh). test -n and -z exist for a reason, even if one has to come up with pretty dodgy mnemonics for remembering them. The other benefit to using test flags instead of a hand-rolled string test is that they're *documented in the manpage*. -- G. Branden Robinson|It may be difficult to to determine Debian GNU/Linux |where religious beliefs end and [EMAIL PROTECTED] |mental illness begins. http://people.debian.org/~branden/ |-- Elaine Cassel pgpbPx4cRVLaJ.pgp Description: PGP signature
Re: /etc/shells management
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 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 me.
I'd propose a Policy amendment dropping support for this long-obsolete
dpkg behavior, but I reckon I've lost my Policy-amendment-proposing
credentials in your eyes.
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 front as well. :)
--
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire
pgpz9zExvGGrY.pgp
Description: PGP signature
Re: /etc/shells management
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 nobody's crazy enough to try doing anything with a dpkg that old and current packages. It would likely fail in way much more spectacular than this, and we caution against it in the Release Notes. Do you think it would be a good idea to drop that clause from section 6.6 of Policy? I mean, in theory, Policy is supposed to document current practice, and until Manoj posted his snippet I'd never seen a Debian postinst script or portion there of that bothered to see if $2 could be 'unknown'. -- G. Branden Robinson| The National Security Agency is Debian GNU/Linux | working on the Fourth Amendment [EMAIL PROTECTED] | thing. http://people.debian.org/~branden/ | -- Phil Lago, Deputy XD, CIA pgpzyVLEYMQbW.pgp Description: PGP signature
Re: /etc/shells management
-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 me.
I'd propose a Policy amendment dropping support for this long-obsolete
dpkg behavior, but I reckon I've lost my Policy-amendment-proposing
credentials in your eyes.
I would support it.
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 its
purpose much faster than test -n or just [ $var ].
...but I remain open to being directed to a section of the Policy manual
that firmly establishes my wrongness on that front as well. :)
I don't think it should.
cu andreas
- --
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/XEfDHTOcZYuNdmMRApQzAJ90YSr5WW2NJZ8AuLtYtFaDyoiLDwCfW/jN
+YKZa6yx6JwJdllPjQfbCXg=
=hKAf
-END PGP SIGNATURE-
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (GNU/Linux)
mQGiBDgv4FIRBAC65xFoxM2TVvnrfgqU8sh7XcT/N1ifZOAmCVQb/mMmqCc4S9j5
qFL++Pa6tkH8A+SRORTSgziW565R3PborVFM7WbIjhXKPCbJ2FjcpK61n2d1Sg3B
pPefS0++nyd9HhJSK2RrAFeAfipdsPe4pd9F+traM4TmHWGDK4aJnCPYDwCgsRQk
wZqU4kmsxlM7VNevWcMlb8ED/R3F+yOe5Q9LO5zjvOj2uFCnIanZ+bdWCIWBO9po
EqhBQPettVTFqJjIIIGZyV2irBg+vQlYnDL/n4SBCPvmCsNhceuobUSTk4DNC1qL
0B+raRgGPMd2qizaFMnmVuT/JsGoh4gu0zsoyYhnODO8Sfp7oPy1VVCbRdz7m8ZU
DztxBACYjmLwqKKp5pF4z1s/1J2u0V/LBgthQ6Vu1LARS8JZzu2jjv97eKqC2v1L
5GmhM2Hi+hW2l5zhNQAe9It2uFAikwp8WRP7lQUQiuo05hyGZpSW2NeBRU/REYRt
57GOZ/Jv0ixJfVk4YTgzwbOUSxs5NhhufwmzLC36PA2K4LQSYbQ7QW5kcmVhcyBN
ZXR6bGVyIChwcml2YXRlIGtleSkgPGFtZXR6bGVyQGRvd25oaWxsLmF0LmV1Lm9y
Zz6IWAQTEQIAGAMLCgMDFQMCAxYCAQIXgAIZAQUCOC/gUwAKCRAdM5xli412Y9Bg
AJ9ZaCCY+CWFxtHeuni2YWApJ8ZsLACgoEPpM+h596oHH0WbSUbxG0KQWaOInAQQ
AQEABgUCOecRWQAKCRD175d9nvVQ4TSPBADDfppOzFhCsSvCfVcT1fiYY/0Uv+vw
hwsFpECBZXmEdVDvwzikwifDyNdA+kB2DP8hDi+eL/zRuFhXSpn/2lnzq/93mcZU
M1O/sUx7zVWoc4YSs3elCNL2vym9/1th8QuRL8OgTkEg/MV3FRznLktGx89kmj1F
ZznOAWFyrIcJ+4kAlQMFEDvYqYczdR0edTxGXQEByDkD/07XHDswLJMi1nZbQ7wD
yDQGFF1I4rj+bKOoExcqPCHmNBuqf5GurY752aFGaQnJshORkcl3yWFuaxJ/VRfz
ynf5ox5UjyMyhelwZgPbewogSWPKan/JVTsrKsy9QKsmn1DUf3IhOCB3X2fXK/g3
O8o3hE5QsHjGhEeBcDoy5BGViEYEEBECAAYFAjvYqYkACgkQfFYn/kwM9E9VtgCe
K/Y862yp4VWZ6PN2DFUqZgy/suUAoKXxvylXkkJ0qIGQFiPqX8NCqDxFiEYEEBEC
AAYFAjvYqY4ACgkQizJGFvc6Ki8WLgCgvCigBa7dLbKQrQWduLNZ5EcHeYgAniSs
+/lCbbl3zJih//kzS8pFAzpRiEYEEBECAAYFAjvYjCgACgkQipm9iJAT39/TdACe
OEwH1KhO/Y7lu+PsH4zVSqhasZoAmwVUaC7VbAhijFHAaeVtFgwmXpmuiEYEEBEC
AAYFAjvZBhAACgkQDF8aVkjSn7EU0ACfStWK92wLrZCDUGP2Zmn9vSIE620AoLWE
Z9QhsBWNZIONszc/xc73/R15iQEcBBABAgAGBQI72TBJAAoJEBbilLMFONd4HuwH
/ic7c+lt1QyQ4GAR3k6hSPeAzt/kU6y3zHvdo76Zxl6BqdZP3xBmmm8Vwqypst3H
dTEO8xgGtf8Doamh5ihzAQqD/m/vsYsJk9ZcsUFocdOZrByzCQ0hLIW2muFkPHyf
6QDXjFia7RNCMaNsmbIOC0WpGGDJ1TJi6IeWInG+gFFyMM0aOdrg2cbxTHtiEZgn
o/nCEUy5iKK3hOdNuYL+Zqym24hrnLrcJbyLmn1B0UdEJNpw6yHBou4nXZkxOsQX
EslXAsbgqeaXjS++dO3BImI/NX1wlyv9C/A0ulMxYSUEJMxJippje5y7h5ceVG6o
VDhi0ImFwNEA6pSEygEaFT+IRgQQEQIABgUCO9lXVAAKCRATQ3NImvnegrBOAJsH
R/pju3ps0S89OrVG16NQyaCfzQCeL9dFPiKnBdROwM+7rIMmGLI9MAmIRgQQEQIA
BgUCO9lXkwAKCRBqlnUR0RRTwnUSAKCRMEgSneGP2qcHHoYsCMlO2eMztgCg+n9m
UF5DfBaKNwkvWmfFCE8rcmSIRgQQEQIABgUCO9ms1AAKCRCp2TuhBdA56w8HAJ40
5lTDunwkvEw/ZEldGoBgEODVCwCfTIMpg/KB4dbk4HYHwHVuLexKdHWIRgQQEQIA
BgUCO9mPhQAKCRCI6X93R3r7kKHLAKCRqZYiD0iaJoslLYfK21STOieeRQCg/zh3
tEc3cJNCFTs8ImsR0A/7qIWIRgQQEQIABgUCO9sgpwAKCRB9n5GQbyq7LejsAJ0c
76k3DJ2PZhuVrK8KJ65snnQ4FgCfYroRQPdYgT31SwlUkauQO+5FiPGJAJUCBRA7
2ynBxZlFMVEPYUEBAQmRA/4/BgxsD4dUN/gFP64sovMUhrDGxbsfAqsCD6PtMfBx
/uzkWEN/VnLQdeoxH0Qd+VDmPeOIJIGvysF+WxeBZa+1Xm3zPafpLvDgjDCFJczu
+KDy4LgbqEa5sUbNLhdQnTC8rx2rVcsGBWFef7y3be+LjveH4rsxaOqj3vz6XAlh
34kA0AMFEDvbL7VS43pmszriqQEBsa4F1ArHZgR2vQLKATlGANBuz1u3KRGIB1QB
kzod6g5xvhJJV0onccetvBsSMCUcf84+CiWLC+9OAWZQ4cfBK6reQ8yBDnlOEwuy
J15dcjxzvAvmqYy+8GwDmPNRRIKfCxFM5prv5/U7Bgwv6HsbIaQxRiRUBkRDBDrm
6hNhUoro0lavCi8eSsfVkHQBtbWZOWXqstZ/nBkGxaq4AKaLBKaMhNc4EPj7RCOH
L41D9crbovtnzSU3PROecAnczsOJAJUCBRA72z7xVkrK5voTYfkBAe7ZBAC0jKyd
0K96mTU9dZyCqQgiG0kpfb12dPG49QtoKU/1EHLkEwChV37EK+DUy51LZK7sReqj
9sxA21TyNKfHEhds35Uqu9kxhFLux5Xyg6M69J46U0F1RFHFzHVtcYgAwEySCaHc
0Zc2jYMGduKkpDH7v3Zn3N69xrEtNPygqzvC8IhGBBARAgAGBQI72/hCAAoJENnm
PzGqUp1YFIMAoIJjalpdNgu2YIbalCDZqWBiW8SFAJ4uf9FhvC75I68zIrO+vRYk
Xky3RYhGBBARAgAGBQI729tjAAoJEISP81DRy1cGCjYAoINC23j2yuF3tEpQ6jDz
semB4JIzAKCrHfFczhnVPBiwAvh6Z7dhWxNqbIhGBBARAgAGBQI73CM9AAoJEAM9
TnY4KpMFioIAn3eeGPRscJgrxJg9i0HrNF1F2KYaAKC0qcVyXhof+zIXyZMEzgGF
g+AuM4g/AwUQO9xFcVbmlud7DA+mEQKwCwCdGFBKsR+CIrUtyeJSSpGixzt99nUA
oLdg2kYkwssmgZnv0NdOdZXIvGYDiQCVAgUQO9xGAMRGkei8OaXNAQEHYAQAosIP
Re: /etc/shells management
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. POSIX requires this not to be the case, because of the argument-counting algorithm that 'test' is supposed to follow. See http://www.opengroup.org/onlinepubs/007904975/utilities/test.html. 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. Whoa. You don't reflexively quote shell variables and have to think about when *not* to quote them? :) Certainly, if you leave the variables unquoted, 'test -n $var' is hardly any more reliable than just 'test $var', and I would trust neither against hostile input. -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
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 ; [ -n $a ] echo a is not empty
a is not empty
$ a=; [ -n $a ] echo a is not empty
$ unset a ; [ -n $a ] echo a is not empty
and:
$ unset a ; [ ${a+set} = set ] echo a is set
$ a=; [ ${a+set} = set ] echo a is set
a is set
$ a=1 ; [ ${a+set} = set ] echo a is set
a is set
IMO, [ -n $var ] is equivalent to [ ${var:+set} = set ].
The first form seems to be more readable and less error prone :)
PS: what is the simplest way to test if a variable is set?
--
Nekral
Re: /etc/shells management
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 that old and current packages. It would likely fail in way much more spectacular than this, and we caution against it in the Release Notes. Do you think it would be a good idea to drop that clause from section 6.6 of Policy? I mean, in theory, Policy is supposed to document current practice, and until Manoj posted his snippet I'd never seen a Debian postinst script or portion there of that bothered to see if $2 could be 'unknown'. It should probably be demoted to a historic footnote. -- 2. That which causes joy or happiness.
Re: /etc/shells management
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 shell scripts by Ian Jackson, heh). Probably because Ian learned shell scripting in the days (or from scripts written in those days) when [ $var = foo ] was likely to cause problems when $var was undefined. So we learned to do [ X$var = Xfoo ] which leads to using '[ X$foo = X ]' to test for empty. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: /etc/shells management
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. Whoa. You don't reflexively quote shell variables and have to think about when *not* to quote them? :) Certainly, if you leave the variables unquoted, 'test -n $var' is hardly any more reliable than just 'test $var', and I would trust neither against hostile input. People *should* quote their shell variables in general, yes. But this subthread is both about recommended practices and the Policy manual. It's not a Policy violation for someone to say if [ $var ], it's just a bad idea. :) -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpifysPlySmf.pgp Description: PGP signature
Re: /etc/shells management
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 its
purpose much faster than test -n or just [ $var ].
By readable, I mean exactly ease of discerning purpose.
My proposed method *is* the idiomatic way of using test(1) to check for
a non-null value. I don't defend test(1) as a miracle of clarity,
though. -h is a synonym for -L. Go figure. :-/
--
G. Branden Robinson|To Republicans, limited government
Debian GNU/Linux |means not assisting people they
[EMAIL PROTECTED] |would sooner see shoveled into mass
http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn
pgp5a35kAyv9u.pgp
Description: PGP signature
Re: /etc/shells management
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
Re: /etc/shells management
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 for options. The transition to -L did not come until much later. But by then all of the code that used BSD had implemented -h but never heard of -L. The implementation of -L has been playing catchup ever since. Today I can't find a system that does not implement 'test -L'. But I did find at least one commercial system that had not gotten around to documenting it that they had done it. So by reading the man page there you would still be thinking that it had not. Bob pgpHxmUdat8B0.pgp Description: PGP signature
Re: /etc/shells management
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 front as well.
:)
Now you are talking style issues.
I still code reflextively from days when the only portable way
was
if [ X$var != X ]; then foo; fi
Readability lies in the eye of the beholder; for me this is idiomatic
and eminently readable. I confess that I rarely use the ${var+set}
idiom, I don't remember why I used it in favour of the X$2 idiom
there.
manoj
--
The finest eloquence is that which gets things done.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
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, most-recently-configured-version, and so forth, did not occur to me. I'd propose a Policy amendment dropping support for this long-obsolete dpkg behavior, but I reckon I've lost my Policy-amendment-proposing credentials in your eyes. I would support it. Why? Policy does not ask you to cater to ancient versions of dpkg; it merely mentions historical behaviour, and you can't retroactively go back and change dpkg implementations from way back when. manoj who can see no reason to go back and edit working postinst scripts just to remove compatibility with improbably old versions of dpkg -- Knowledge, sir, should be free to all! Harry Mudd, I, Mudd, stardate 4513.3 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
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 to work around. -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
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 ]
...but I remain open to being directed to a section of the Policy
manual that firmly establishes my wrongness on that front as well.
:)
As Nicolas François pointed out, the difference is between an
empty, but set, variable, and an unset variable. (so, an empty $2
means no recently configured version, an unset $2 means this is an
ancient dpkg. Not that most people care for these distinctions
anymore).
manoj
glad to have reconstituted the logic behind the odd construct
--
Truth is the most valuable thing we have -- so let us economize
it. Mark Twain
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
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
Re: /etc/shells management
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, new-version, most-recently-configured-version, and so forth, did not occur to me. I'd propose a Policy amendment dropping support for this long-obsolete dpkg behavior, but I reckon I've lost my Policy-amendment-proposing credentials in your eyes. I would support it. Why? Hello, It is cruft and policy has over 300KB. Afaik policy's purpose is not to document historical behaviour in dpkg but technical requirements for packages in Debian. Policy does not ask you to cater to ancient versions of dpkg; it merely mentions historical behaviour, and you can't retroactively go back and change dpkg implementations from way back when. The simple fact that it is documented in policy without big fat markers Don't implement today, this is *ancient* dpkg, it is useless today makes it a suggestion. I recently modified some postinst and (following policy) added the nowadays completely useless test for 'unknown' because I did not check dpkg's changelog ATM. [o] Stupid [o] Overzealous [o] Avoidable who can see no reason to go back and edit working postinst scripts just to remove compatibility with improbably old versions of dpkg Removing the paragraph from policy would not force you to edit working postinst scripts. cu andreas
Re: /etc/shells management
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 fi var=-f Have you tried that? No POSIX shell will have a problem. -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
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 [ -n $var ]; then
fi
for this sort of thing. However, that does depend on a certain other
case you handle never happening:
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 maintainer scripts. It's
documented nowhere that I need to handle the argument 'unknown'.
Where did you come by this, and if it's something we should worry about,
why isn't it documented in Policy?
To me it looks like whoever wrote this code extrapolated too generously
from the output of dpkg -l on the name of a package that has been
purged. But I haven't gone grubbing around in dpkg's source code, so I
don't know for sure...
--
G. Branden Robinson| Don't use nuclear weapons to
Debian GNU/Linux | troubleshoot faults.
[EMAIL PROTECTED] | -- US Air Force Instruction 91-111
http://people.debian.org/~branden/ |
pgpYxPwDQKt14.pgp
Description: PGP signature
Re: /etc/shells management
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 maintainer scripts. It's documented nowhere that I need to handle the argument 'unknown'. Where did you come by this, and if it's something we should worry about, why isn't it documented in Policy? [...] Quoting policy 3.6.1.0 (3.5.6.1 is identical) | If there is no most recently configured version dpkg will pass a | null argument; older versions of dpkg may pass unknown (including | the angle brackets) in this case. Even older ones do not pass a | second argument at all, under any circumstances. However handling this seems to be pretty academic, the change happened in ancient times: dpkg (1.2.1); priority=MEDIUM [...] * postinst configure now gets null argument (not unknown or none) when there is no previously configured version. [...] -- Ian Jackson [EMAIL PROTECTED] Wed, 22 May 1996 01:26:31 +0100 cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: /etc/shells management
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 case you handle never happening: 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 maintainer scripts. It's documented nowhere that I need to handle the argument 'unknown'. Where did you come by this, and if it's something we should worry about, why isn't it documented in Policy? Look at section 6.6: If there is no most recently configured version dpkg will pass a null argument; older versions of dpkg may pass unknown (including the angle brackets) in this case. Even older ones do not pass a second argument at all, under any circumstances. -- Thomas Hood [EMAIL PROTECTED]
Re: /etc/shells management
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 general, no. If the contents of $var are a test operator, you'll get a syntax error. -- Steve Langasek postmodern programmer pgpoZEuNlPTZe.pgp Description: PGP signature
Re: /etc/shells management
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 a test operator, you'll get a syntax error. Not in a POSIX-compliant sh. -- Micha Politowski -- [EMAIL PROTECTED] Talking has been known to lead to communication if practised carelessly.
Re: /etc/shells management
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
Re: /etc/shells management
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 fi I hope that's kosher too; otherwise I have a few scripts to fix. In general, no. If the contents of $var are a test operator, you'll get a syntax error. POSIX requires this not to be the case, because of the argument-counting algorithm that 'test' is supposed to follow. See http://www.opengroup.org/onlinepubs/007904975/utilities/test.html. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
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 test ${2+set} != set; then
Man, that's ugly. I use:
if [ -n $var ]; then fi
*Shrug*.
for this sort of thing. However, that does depend on a certain
other case you handle never happening:
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 maintainer scripts. It's
documented nowhere that I need to handle the argument 'unknown'.
I think you actually need to go read that document.
6.6 Details of configuration
When we configure a package (this happens with dpkg --install and dpkg
--configure), we first update any conffiles and then call:
postinst configure most-recently-configured-version
No attempt is made to unwind after errors during configuration.
If there is no most recently configured version dpkg will pass a null
argument; older versions of dpkg may pass unknown (including the
angle brackets) in this case. Even older ones do not pass a second
argument at all, under any circumstances.
See the bit about older versions of dpkg?
Where did you come by this, and if it's something we should worry
about,
This is an excerpt from one of my postinst files, so it is
loosely derived from the scripts written by Charles Briscoe-Smith,
March-June 1998.
why isn't it documented in Policy?
It is. Why don't you try reading it more carefully?
To me it looks like whoever wrote this code extrapolated too
generously from the output of dpkg -l on the name of a package
that has been purged. But I haven't gone grubbing around in dpkg's
source code, so I don't know for sure...
No, whoever wrote this code (yours truly) actually read
policy, and is trying to hand craft packages that follow it.
manoj
--
A robin redbreast in a cage Puts all Heaven in a rage. Blake
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
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 and current packages. It would likely fail in way much more spectacular than this, and we caution against it in the Release Notes. -- 2. That which causes joy or happiness.
Re: /etc/shells management
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 ${2+set} != set; then
# We're being installed by an ancient dpkg which doesn't remember
# which version was most recently configured, or even whether there
# is a most recently configured version.
:
elif test -z $2 -o $2 = unknown; then
# The package has not ever been configured on this system, or was
# purged since it was last configured.
:
else
# Version $2 is the most recently configured version of this
# package.
Shell may be missing in /etc/shells because the sysadmin decided to
remove it (so be it) or the package has been removed but not purged
(add it again).
So create a file in the postinst that signifies the
/etc/shells is configured, and remove it on removal. This file is
not a conffile; it so, if it exists, do nothing, if it does not
exist, add.
Simple, huh?
:
fi ;;
manoj
--
pessimist: A man who spends all his time worrying about how he can
keep the wolf from the door. optimist: A man who refuses to see the
wolf until he seizes the seat of his pants. opportunist: A man who
invites the wolf in and appears the next day in a fur coat.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
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. This has the possibility of generating a syntax error if $var expanded to be something that started with a '-' and therefore looked like an option to the test operator. It is not portable to use that construct. This is heritage from the Bourne shell which also exists in the Korn shell which became the basis for the POSIX shell much later. For example on HP-UX: /bin/sh -c 'var=-f ; [ $var ] echo yes' /bin/sh: test: Specify a parameter with this command. Everywhere: /bin/sh -c 'var=-f ; [ -n $var ] echo yes' yes Bob pgppJ4M1i7MyQ.pgp Description: PGP signature
Re: /etc/shells management
[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 called by add-shell and remove-shell. kcr
Re: /etc/shells management
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 unconditionally run? add-shell is idempotent, so running add-shell /bin/bash3 add-shell /bin/bash3 results in only one /bin/bash3 in /etc/shells. So the postinst can run it unconditionally. kcr
Re: /etc/shells management
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 not purged? In the latter case it should be added again,
but not in the first one.
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
# We're being installed by an ancient dpkg which doesn't remember
# which version was most recently configured, or even whether
# there is a most recently configured version.
:
elif test -z $2 -o $2 = unknown; then
# The package has not ever been configured on this system, or was
# purged since it was last configured.
:
else
# Version $2 is the most recently configured version of this
# package.
:
fi ;;
manoj
--
Men ought to know that from the brain and from the brain only arise
our pleasures, joys, laughter, and jests as well as our sorrows,
pains, griefs and tears. ... It is the same thing which makes us mad
or delirious, inspires us with dread and fear, whether by night or by
day, brings us sleeplessness, inopportune mistakes, aimless anxieties,
absent-mindedness and acts that are contrary to habit... Hippocrates
The Sacred Disease
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
[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.
Re: /etc/shells management
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 initial install only, to allow a sysadmin to take it out again), run: i think the scripts should follow the update-X naming schema. bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 pgpMAjhnKJKE1.pgp Description: PGP signature
Re: /etc/shells management
* | 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 debian-devel-announce instead of just debian-devel? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: /etc/shells management
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, because the binary isn't there any longer. The Martin package is still in configured state. Now we install it again, 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 unconditionally run? Perhaps something like update-modules would help here? Regards, Isaac.
