Bug#747320: Mandate "type" in /bin/sh
Package: debian-policy Version: 3.9.5.0 I came across this in /etc/init.d/exim4: OLDIFS="$IFS" IFS=: for p in $PATH; do if [ -x "$p/$UPEX4CONF" ]; then IFS="$OLDIFS" $p/$UPEX4CONF $UPEX4OPTS return 0 fi done IFS="$OLDIFS" I imagine that this kind of thing is found in many other places. It seems to me that given that dash and bash both provide `type', and the underlying functionality necessarily exists in the shell, it would be better to mandate that the shell expose it. I therefore propose that the following should be added to the list of additional features listed in policy 10.4: * The XSI extension `type' must be supported . It must exit zero iff the command is found. The output format is not specified and scripts must not rely on it; scripts should rely only on the exit code using a construct such as if type foo >/dev/null 2>&1; then ... Thanks, Ian. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21354.13815.337486.179...@chiark.greenend.org.uk
Bug#747320: Mandate "type" in /bin/sh
On Wed, May 07, 2014 at 02:32:39PM +0100, Ian Jackson wrote: > I therefore propose that the following should be added to the list of > additional features listed in policy 10.4: > > * The XSI extension `type' must be supported . It must exit > zero iff the command is found. The output format is not > specified and scripts must not rely on it; scripts should > rely only on the exit code using a construct such as >if type foo >/dev/null 2>&1; then ... As the author of the original shell incarnation of what's now /usr/bin/which, and having worked around the lack of a policy-authorised in-process idiom for this in a number of places, I would also like to see such an extension in policy. It's been a long-standing irritation to have to duplicate this code everywhere for the sake of strict conformance. We should, though, survey the set of shells in Debian (excluding posh, which should follow policy in this regard) to find out if any of them lack "type" and if not make sure that they're extended appropriately. mksh seems to have it. I haven't checked any others. We need to say something about options. POSIX simply says "none". dash treats all of its arguments as names regardless of whether they begin with an option. bash has a number of options and the GNU-style "--" end-of-options indicator. Policy therefore probably ought to say that the behaviour of "type" with any arguments beginning with "-" is not specified (so you can't use bashisms like "type -P" to force a PATH search). -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507140925.ga2...@riva.ucam.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
block 720777 by 613143 block 720778 by 613143 block 720780 by 613143 thanks On Fri, Sep 23, 2011 at 10:18:05AM +0200, Bill Allombert wrote: > On Thu, Sep 22, 2011 at 05:08:33PM -0500, Jonathan Nieder wrote: > > Tollef Fog Heen wrote: > > > ]] Steve Langasek > > > > > | How do we square that with the FHS, then? The FHS says: > > > | > > > | If directories /lib or /usr/lib exist, the equivalent > > > | directories must also exist in /usr/local. > > > | > > > | That seems to require /usr/local/lib64 even if we *don't* include > > > | /usr/lib64, right? Should we amend policy to take this exception to the > > > | FHS? Please open a bug report on policy if you think we should. > > > > > > I think this is a bug in the FHS that we need to work around in Debian > > > policy. > > > > libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem > > described in bug#612000 no longer exists and there's no reason to want > > a /usr/local/lib64 symlink any more. We're left in the less worrisome > > situation Steve described, with the question of whether to create a > > (useless) /usr/local/lib64 directory. > > > > So now I can wholeheartedly endorse your proposed change. > > > > > --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 > > > +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 > > > @@ -5993,6 +5993,13 @@ > > >to get access to kernel information. > > > > > > > > > + > > > + > > > + The requirement for > > > /usr/local/lib> > > + to exist if /lib or > > > + /usr/lib exists is removed. > > > + > > > + > > > > > > > > > > > > > Seconds? > > Seconded. The whole lib64 business was completly backward from the start. Ping! How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/lib to be created if /lib exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507234242.ga27...@volta.rr44.fr
Processed: Re: Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Processing commands for cont...@bugs.debian.org: > block 720777 by 613143 Bug #720777 [libc6-x32] libc6-x32: /usr/local/libx32 (required by FHS) doesn't exist 720777 was not blocked by any bugs. 720777 was not blocking any bugs. Added blocking bug(s) of 720777: 613143 > block 720778 by 613143 Bug #720778 [libc6-i386] libc6-i386: /usr/local/lib32 (required by FHS) doesn't exist 720778 was not blocked by any bugs. 720778 was not blocking any bugs. Added blocking bug(s) of 720778: 613143 > block 720780 by 613143 Bug #720780 [libc6] libc6:amd64: /usr/local/lib64 (required by FHS) doesn't exist 720780 was not blocked by any bugs. 720780 was not blocking any bugs. Added blocking bug(s) of 720780: 613143 > thanks Stopping processing here. Please contact me if you need assistance. -- 720777: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720777 720778: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720778 720780: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720780 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.139950618314577.transcr...@bugs.debian.org
