On 3/22/22 6:57 AM, Ottavio Caruso wrote:
> I mean, if an executable is not there, the shell will still complain,
I think it's important to define where "there" means /explicitly/. E.g.
what if the command you want is in /usr/bin instead of /bin. There is
also a possibility that /bin is a sym-link to /usr/bin, but earlier in
> but I would like to make sure that users of my script have the "right"
What defines the "right" vs "wrong" executable?
What if it's the version that you are wanting but it's located in ~/bin
instead of the system's (/usr(/local))/bin directory? E.g. GNU tools on
a *BSD system existing in ~/bin.
> for example not aliases, custom functions, etc. Or should I just
> leave the shell do its job?
Why do you want to ignore user preferences?
I could be arrogant and ask "what gives you the audacity to specify
which `ls` is run on /my/ system?
Especially if you don't provide the version you want run.
Also, aliases tend to be interactive and don't function in
non-interactive execution of scripts. Functions are their own critter.
> A template would be like this:
> for each of $PROGRAMS LIST
> check if $PROGRAM it's installed in $PATH and it's not an alias
> && echo $PROGRAM has been found at $LOCATION
> || echo $PROGRAM has not been found; exit (which code?)
So you aren't differentiating between /bin/bla, /usr/bin/bla,
/usr/local/bin/bla. So which of those is the right version of bla?
That also fails to take into account ~/bin being the first directory in
> and so on.
> (I'm using "for each" not literally here, it's not a csh script)
> I am experimenting with "which" but I am having random results.
> "command -v" is too tolerant and will accept aliases, which I don't want.
Try using a full path to the command that you want or prefixing commands
with a backslash to disable alias support.
Again, alias / function support in interactive shells is different than
in non-interactive scripts.
Grant. . . .
unix || die