On Thu, 2020-03-12 at 11:11 +0900, John Crawley wrote: > On 2020-03-02 07:12, jnq...@gmail.com wrote: > > Package: live-build > > Version: 1:20191221 > > Owner: jnq...@gmail.com > > Severity: minor > > > > there are lots of checks being done that tools are available and > > executable. this is done with a mixture of use of `which` and fixed > > paths, redirection of output to /dev/null (`2>/dev/null`) and > > redundant > > executability tetsing on top of `which` checks (which already does > > such > > a check). > > > > this can be tidied up and robustified. > > - we can move everything to `which` and drop fixed paths, thus > > robustifying things should a bin every move (you never know). > > - we can drop performing pointless `-x` testig on top of `which` > > use, > > since `which` already performs this and signals such in its exist > > code > > (returns 1 if nonexistant or nonexecutable). > > - we can drop the `2>/dev/null` redirection which in my testing > > seemed > > to make no difference. > > > > proposal: switch to conditionals of the form: > > ``` > > if [ $(which dpkg) ]; then > > #whatever > > fi > > ``` > > The use of 'which' is not universally regarded as robust: depending > on > the environment it can return true even if the executable does not > exist, and may also output an error message, breaking the above test.
oh really. that's disappointing :/ > POSIX has 'command -v <command>' which should work under the > #!/bin/sh > shebang that live-build scripts use: > if command -v dpkg >/dev/null > then > echo "we have dpkg" > fi > > See: https://mywiki.wooledge.org/BashFAQ/081 yeah I actually came across the `command -v` solution a few days ago but with the `which` based solution already in place saw little value in reworking it. if `which` is flakey though, then perhaps its important that we do change. i've got rather a lot of stuff still to work on on live-build already never mind anything else. would you have time to submit a patch yourself?
