Bug#218530: Suboptimal conditional rune for initscripts

2003-11-02 Thread Ian Jackson
Mark Baker writes (Re: Bug#218530: Suboptimal conditional rune for 
initscripts):
 I think it's debatable whether searching the path for a command in an 
 init script is a good thing, but if we don't search the path for the 
 test we shouldn't do it when we actually execute the command, so the 
 code you quote is wrong either way.

Quite so.

I'm convinced that searching the path is the right answer, because it
allows the sysadmin to replace binaries by modifying the path or
putting them in /usr/local, without having to use dpkg-divert (and, if
they want different commands at different times, without having to do
weird hacks with environment variables or anything ...)

Ian.



Bug#218530: Suboptimal conditional rune for initscripts

2003-11-02 Thread Ian Jackson
Herbert Xu writes (Re: Bug#218530: Suboptimal conditional rune for 
initscripts):
 You'd better make that simply type so that it will work with
 POSIX shells other than bash.  Besides, there is no reason to
 rule out aliases/functions/builtins since when invoke-rc.d is
 actually run those things will all be considered by the shell.

Err, you're quite right.

Ian.



Bug#218530: Suboptimal conditional rune for initscripts

2003-11-02 Thread Branden Robinson
On Sat, Nov 01, 2003 at 04:55:36PM +, Ian Jackson wrote:
 Branden Robinson writes (Re: Bug#218530: Suboptimal conditional rune for 
 initscripts):
  Ah, I see the reason:
 ...
  [127] [EMAIL PROTECTED]:~ % ash
  $ type ls
  ls is /bin/ls
 
 But you don't, because it has a nonzero exit status if the command is
 not found - and foundness is the only thing the maintscript is
 interested in.

Ah, right.

Well, then, type and which seem to be equivalent.  which seems far
more intiutitive to me, but then I grew up using TCSH and am accustomed
to most shells having it as a built in.

-- 
G. Branden Robinson| Never attribute to malice that
Debian GNU/Linux   | which can be adequately explained
[EMAIL PROTECTED] | by stupidity.
http://people.debian.org/~branden/ | -- Hanlon's Razor


signature.asc
Description: Digital signature


Bug#218530: Suboptimal conditional rune for initscripts

2003-11-02 Thread Bob Proulx
Mark Baker wrote:
 Ian Jackson wrote:
 
 Package: debian-policy
 Version: 3.6.1.0
 
 While trying to merge an NMU to my package, I spotted an idiom
 obviously copied from the policy manual:
 
if [ -x /usr/sbin/invoke-rc.d ] ; then
  invoke-rc.d package action
else
  /etc/init.d/package action
  fi
 
 This would be better expressed as
 
  if type -p invoke-rc.d /dev/null 21; then
  ...
 
 I think it's debatable whether searching the path for a command in an 
 init script is a good thing, but if we don't search the path for the 
 test we shouldn't do it when we actually execute the command, so the 
 code you quote is wrong either way.

Additionally using 'type -p' is bash specific.  Therefore it should
not be used in /bin/sh scripts.  Instead POSIX standard /bin/sh syntax
such as 'command -v' should be used.  I will rewrite the example for
clarity.

if command -v invoke-rc.d /dev/null 21 ; then
invoke-rc.d package action
...

-- 
Bob Proulx [EMAIL PROTECTED]
http://www.proulx.com/~bob/



Bug#218530: Suboptimal conditional rune for initscripts

2003-11-02 Thread Herbert Xu
Ian Jackson [EMAIL PROTECTED] wrote:
 
 This would be better expressed as
 
if type -p invoke-rc.d /dev/null 21; then
...
 
 This latter form will detect accurately whether invoke-rc.d is
 available _on the current PATH_ as set by the sysadmin, and will
 therefore allow somewhat greater flexibility to admins (eg, to install
 invoke-rc.d separately in /usr/local before upgrading).

You'd better make that simply type so that it will work with
POSIX shells other than bash.  Besides, there is no reason to
rule out aliases/functions/builtins since when invoke-rc.d is
actually run those things will all be considered by the shell.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



Bug#218530: Suboptimal conditional rune for initscripts

2003-10-31 Thread Ian Jackson
Package: debian-policy
Version: 3.6.1.0

While trying to merge an NMU to my package, I spotted an idiom
obviously copied from the policy manual:

if [ -x /usr/sbin/invoke-rc.d ] ; then
invoke-rc.d package action
else
/etc/init.d/package action
fi

This would be better expressed as

if type -p invoke-rc.d /dev/null 21; then
...

This latter form will detect accurately whether invoke-rc.d is
available _on the current PATH_ as set by the sysadmin, and will
therefore allow somewhat greater flexibility to admins (eg, to install
invoke-rc.d separately in /usr/local before upgrading).

Ian.



Bug#218530: Suboptimal conditional rune for initscripts

2003-10-31 Thread Mark Baker

Ian Jackson wrote:


Package: debian-policy
Version: 3.6.1.0

While trying to merge an NMU to my package, I spotted an idiom
obviously copied from the policy manual:

   if [ -x /usr/sbin/invoke-rc.d ] ; then
invoke-rc.d package action
   else
/etc/init.d/package action
fi

This would be better expressed as

if type -p invoke-rc.d /dev/null 21; then
...
 

I think it's debatable whether searching the path for a command in an 
init script is a good thing, but if we don't search the path for the 
test we shouldn't do it when we actually execute the command, so the 
code you quote is wrong either way.