Bug#218530: Suboptimal conditional rune for initscripts
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
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
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
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
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
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
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.