From: Masahiro Yamada > Sent: 03 June 2019 12:45 > On Mon, Jun 3, 2019 at 8:16 PM David Laight <david.lai...@aculab.com> wrote: > > > > From: Masahiro Yamada > > > Sent: 03 June 2019 11:49 > > > > > > To print the pathname that will be used by shell in the current > > > environment, 'command -v' is a standardized way. [1] > > > > > > 'which' is also often used in scripting, but it is not portable. > > > > All uses of 'which' should be expunged. > > It is a bourne shell script that is trying to emulate a csh builtin. > > It is doomed to fail in corner cases. > > ISTR it has serious problems with shell functions and aliases. > > OK, I do not have time to check it treewide. > I expect somebody will contribute to it. > > > > BTW, I see yet another way to get the command path. > > 'type -path' is bash-specific.
'type' itself should be supported by all shells, but the output format (esp for errors) probably varies. > Maybe, we should do this too: > > diff --git a/scripts/mkuboot.sh b/scripts/mkuboot.sh > index 4b1fe09e9042..77829ee4268e 100755 > --- a/scripts/mkuboot.sh > +++ b/scripts/mkuboot.sh > @@ -1,14 +1,14 @@ > -#!/bin/bash > +#!/bin/sh /bin/sh might be 'dash' - which is just plain broken in so many ways. Try (IIRC) ${foo%${foo#bar}} It might even be the original SYSV /bin/sh which doesn't support $((expr)) or ${foo#bar} - but that may break too much, but $SHELL might fix it. dash probably has the rather obscure bug in stripping '\n' from $(...) output that I found and fixed in NetBSD's ash may years ago. Try: foo="$(jot -b "" 130)" All 130 '\n' should be deleted. Mostly it fails to delete all the '\n', but it can remove extra ones! David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)