From: Masahiro Yamada
> Sent: 03 June 2019 12:45
> On Mon, Jun 3, 2019 at 8:16 PM David Laight <David.Laight@xxxxxxxxxx> 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)
