* Steve Greenland
|
|
| 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 «l
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
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 no
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 [
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 "ol
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"
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
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
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-con
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 wrongne
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
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
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
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 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
> featu
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 w
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
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.
-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 no
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 be
Sorry to give offense, Manoj. I should have grepped the whole chapter
before wondering about "", 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 sh
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:
> > > >
> >
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
syste
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:
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 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-cas
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
> >
> >
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, 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 conte
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 scr
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 o
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" = ""; then
> file:///usr/share/doc/debian-policy/policy.html/ch-maintainerscripts.html
> is my Bible when I'm writing/editing
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 us
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
> remove
> > "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
>
> [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 g
[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.
> "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>
*
| 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-an
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.
So:
/etc/shells is no longer a config file, but is
41 matches
Mail list logo
