I'll rephrase my earlier post, as resident jobsworths and unnecessary
nitpickers have deranged my OP.

I have a list of applications (say: perl, php, mysql, git) that MUST be
present on the system if the script is expected to run. However, they
must be interpreted and rewritten for their presence in $PATH.

Example:

perl

1) is it in $PATH? Yes, then $PERL becomes `which perl`? No, shout loud
and exit.

2) Wash rinse and repeat for all programs in my list.

The problem I'm having with `which $PROGRAM` is that it reports exit 0
(successful) even if it's not found.

I've checked the above in both /bin/sh (which on my system is a symlink
to dash) and /bin/bash.

"command -v" is really not good for me, because it reports successful if
the application is in an alias and I DO NO WANT THAT.

Arrogance? Maybe, but I need to make sure has a "real" program, not a
mickey mouse alias pointing to a fake perl, php, etc.

[I hope but don't expect that the resident Arschloch in chief won't
derange this thread again.]

Have a wonderful day.

--
Ottavio Caruso

In article <t1f5if$vme$1@dont-email.me>,
Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:
>I'll rephrase my earlier post, as resident jobsworths and unnecessary
>nitpickers have deranged my OP.

Nice. I learned a new word today. Good article about it in Wikipedia.
Here's an excerpt:

* Jobsworth:
* A jobsworth is a person who uses the authority of their job in a
* deliberately uncooperative way, or who seemingly delights in acting in an
* obstructive or unhelpful manner. It characterizes one who upholds petty
* rules even at the expense of effectiveness or efficiency.

This is, in fact, a very good description of many/most posters to these
technical newsgroups. They just love whining on and on about and quoting
to each other obscure sh*t from the standards documents that nobody gives a
cr*p about. But they love it.

>I have a list of applications (say: perl, php, mysql, git) that MUST be
>present on the system if the script is expected to run. However, they
>must be interpreted and rewritten for their presence in $PATH.

First, I don't think you need to worry about aliases. Aliases are not
expanded in shell scripts unless you explicitly ask for them to be; there
is an obscure option in bash to turn this on (which you should, of course,
never do). Functions, though, might be an issue (but see below).

I've had best luck with "type" instead of "command" or "which" or anything
else. "type" will return a non-zero exit status if the command is not
found, or a string describing where it was found. You should be able to
parse that output and figure out if it (the location of the command) meets
your requirements.

As long as you don't use the "-a" option, it seems to work the same in dash
and bash (the two shells of interest these days).

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/ItsTough

In our last episode, the evil Dr. Lacto had captured our hero,
Ottavio Caruso <ottavio2006-usenet2012@yahoo.com>, who said:
> I have a list of applications (say: perl, php, mysql, git) that MUST be
> present on the system if the script is expected to run. However, they
> must be interpreted and rewritten for their presence in $PATH.

> The problem I'm having with `which $PROGRAM` is that it reports exit 0
> (successful) even if it's not found.

Odd. It doesn't for me:

$ which perl
/usr/local/bin/perl
$ echo $?
0 $ which fooz
which: no fooz in (/home/hymie/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:
/usr/lib64/qt/bin:/usr/share/texmf/bin:/usr/local/nmh/bin:
/usr/X11/local/bin:/usr/X11/bin)
$ echo $?
1

--hymie! http://nasalinux.net/~hymie hymie@nasalinux.net

On 23.03.2022 13:58, Ottavio Caruso wrote:
> I'll rephrase my earlier post, as resident jobsworths and unnecessary
> nitpickers have deranged my OP.

You seem to still haven't noticed that it was your OP that was deranged.

> [...]
>
> [I hope but don't expect that the resident Arschloch in chief won't
> derange this thread again.]

....bad posting habits and offenses.

Janis

On 23.03.2022 14:17, Kenny McCormack wrote:
>
> First, I don't think you need to worry about aliases. Aliases are not
> expanded in shell scripts unless you explicitly ask for them to be;

This is not true.

> there
> is an obscure option in bash to turn this on (which you should, of course,
> never do).

Obviously also not true in bash.

If you have an alias defined it gets expanded.

Janis

On Wed, 23 Mar 2022 12:58:54 +0000, Ottavio Caruso wrote:

[snip]
> The problem I'm having with `which $PROGRAM` is that it reports exit 0
> (successful) even if it's not found.

Funny, that's not how which(1) is supposed to work.
From the which(1) manpage:
RETURN VALUE
Which returns the number of failed arguments,
or -1 when no `program-name´ was given.

[snip]

HTH
--
Lew Pitcher
"In Skills, We Trust"

On 23/03/2022 at 16.00, Janis Papanagnou wrote:
>> First, I don't think you need to worry about aliases. Aliases are not
>> expanded in shell scripts unless you explicitly ask for them to be;
>
> This is not true.
>
>> there
>> is an obscure option in bash to turn this on (which you should, of course,
>> never do).
>
> Obviously also not true in bash.
>
> If you have an alias defined it gets expanded.

From bash man page:

“Aliases are not expanded when the shell is not interactive,
unless the expand_aliases shell option is set using shopt[…]”

--
mrg

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

> I have a list of applications (say: perl, php, mysql, git) that MUST
> be present on the system if the script is expected to run. However,
> they must be interpreted and rewritten for their presence in $PATH.
>
> Example:
>
> perl
>
> 1) is it in $PATH? Yes, then $PERL becomes `which perl`? No, shout
> loud and exit.
>
> 2) Wash rinse and repeat for all programs in my list.
>
> The problem I'm having with `which $PROGRAM` is that it reports exit 0
> (successful) even if it's not found.
>
> I've checked the above in both /bin/sh (which on my system is a
> symlink to dash) and /bin/bash.

Hmm... In both bash and dash (a POSIX shell) I get:

$ which perl || echo Eek!
/usr/bin/perl
$ which perlx || echo Eek!
Eek!

> "command -v" is really not good for me, because it reports successful
> if the application is in an alias and I DO NO WANT THAT.
>
> Arrogance? Maybe, but I need to make sure has a "real" program, not a
> mickey mouse alias pointing to a fake perl, php, etc.

If you are really worried by "fake" perls (and you seem to be) I don't
think you will have much luck. The presence of an executable called
perl in $PATH does not mean it is not a "mickey mouse alias". Not only
might it exec("/use/bin/awk"), it might even be a dangerous perl-like
program (so you can't check just by running some simple perl). To be
sure (or at least a bit more sure) you could checksum the binary you
find, but that's going to be way more complicated.

As the risk of being called a jobsworthy, I'll ask if an executable
called /usr/bin/perl that executes /usr/local/bin/perl is something you
worry about? It's not clear how far the notion of a mickey mouse alias
extends.

--
Ben.

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

> I have a list of applications (say: perl, php, mysql, git) that MUST
> be present on the system if the script is expected to run. However,
> they must be interpreted and rewritten for their presence in $PATH.

What you describe is commonly done by an installation tool.
If you take a look at autoconf, you can see how that's commonly done.
It's not always done by looking for the executable.

I don't see much point by doing the checks every time the tool is run
unless you are in some unusual environment. How much more useful is
your error message going to be vs. the error the script will generate
when it tries to run the missing program?

--
Dan Espen

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:
> I'll rephrase my earlier post, as resident jobsworths and unnecessary
> nitpickers have deranged my OP.
>
> I have a list of applications (say: perl, php, mysql, git) that MUST
> be present on the system if the script is expected to run. However,
> they must be interpreted and rewritten for their presence in $PATH.
>
> Example:
>
> perl
>
> 1) is it in $PATH? Yes, then $PERL becomes `which perl`? No, shout
> loud and exit.
>
> 2) Wash rinse and repeat for all programs in my list.
>
> The problem I'm having with `which $PROGRAM` is that it reports exit 0
> (successful) even if it's not found.
>
> I've checked the above in both /bin/sh (which on my system is a
> symlink to dash) and /bin/bash.
>
> "command -v" is really not good for me, because it reports successful
> if the application is in an alias and I DO NO WANT THAT.
[...]

Why are you using the external "which" command rather than the builtin
"type"?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 23.03.2022 16:33, marrgol wrote:
> On 23/03/2022 at 16.00, Janis Papanagnou wrote:
>>> First, I don't think you need to worry about aliases. Aliases are not
>>> expanded in shell scripts unless you explicitly ask for them to be;
>>
>> This is not true.
>>
>>> there
>>> is an obscure option in bash to turn this on (which you should, of
>>> course,
>>> never do).
>>
>> Obviously also not true in bash.
>>
>> If you have an alias defined it gets expanded.
>
> From bash man page:
>
> “Aliases are not expanded when the shell is not interactive,
> unless the expand_aliases shell option is set using shopt[…]”

Right for case:
IF bash AND IF non-interactive => non-expanded

Wrong for cases:
IF bash AND IF interactive => expanded
IF ksh (generally) => expanded
IF zsh (generally) => expanded

Janis

On 3/23/22 9:39 AM, Ben Bacarisse wrote:
> If you are really worried by "fake" perls (and you seem to be) I
> don't think you will have much luck.r

Agreed.

I think about the best that can /easily/ and / or /quickly/ be done is
to see if the path is that of a known non-functional version.

The next best thing that I can think of is to check the version reported
by the program to see if it's at least the minimum requisite version.
-- Seeing as how this test is program specific, it's trivial to have
proper syntax for said program to check it's version.

> The presence of an executable called perl in $PATH does not mean it is
> not a "mickey mouse alias".

The traditional Sys V vs UCB commands installed on the same system but
in different directories comes to mind. Both are provided by the
vendor. Which one is used is dependent on the user's PATH.

This is why I've been asking for more information on how to identify the
proper version in the hopes to differentiate it from a so called Mickey
Mouse version.

--
Grant. . . .
unix || die

On 23/03/2022 13:17, Kenny McCormack wrote:
> I've had best luck with "type" instead of "command" or "which" or anything
> else. "type" will return a non-zero exit status if the command is not
> found, or a string describing where it was found. You should be able to
> parse that output and figure out if it (the location of the command) meets
> your requirements.
>
> As long as you don't use the "-a" option, it seems to work the same in dash
> and bash (the two shells of interest these days).

Thanks it makes sense, but I'd like to rephrase my question (and sorry
that I didn't do my homework. I genuinely don't have a stable Internet
connection and I have to rely to the *couch* public library or what
remains of it):

How can I check that a number of programs are installed _and_ point to a
true executable rather than a shell script or similar?

Now, I prevent one of the possible objections: Debian makes great use of
alternatives[1], therefore most programs do point to a shell script or a
link rather than an executable. I'll have to make an explicit exception
for Debian/Ubuntu and similar.

[1] https://wiki.debian.org/DebianAlternatives

--
Ottavio Caruso

On 24/03/2022 15:45, Ottavio Caruso wrote:
> I genuinely don't have a stable Internet connection and I have to rely
> to the *couch* public library or what remains of it):

And the typos are an evidence of this, plus lack of sleep.

s/a program in/a program is
s/ho/how
s/couch/cough

and possibly more.

--
Ottavio Caruso

On 3/24/22 9:45 AM, Ottavio Caruso wrote:
> Thanks it makes sense, but I'd like to rephrase my question (and
> sorry that I didn't do my homework. I genuinely don't have a stable
> Internet connection and I have to rely to the *couch* public library
> or what remains of it):

IMHO there's no need to apologize. I consider the nature of discussions
to involve learning and / or corrections and / or clarifications.

> How can I check that a number of programs are installed _and_ point
> to a true executable rather than a shell script or similar?

It sounds like you mean "binary" as opposed to "executable". I consider
scripts to be executables.

I'd suggest focusing on a (repeatable) process to check an individual
file to determine if it meets your standards or not.

Once you have that process you would loop across the list of files to
see if each file.

> Now, I prevent one of the possible objections: Debian makes great
> use of alternatives[1], therefore most programs do point to a shell
> script or a link rather than an executable. I'll have to make an
> explicit exception for Debian/Ubuntu and similar.

I know that some programs actually use sym-links to provide varies ways
to invoke the compiled binary. BusyBox is an example of such a
quintessential binary wherein many different command names link to one
binary and the binary behaves differently based on the invoking name.

Another example is contemporary Solaris systems making /bin itself a
sym-link to /usr/bin. So, what would you consider /bin/ls which is
(indirectly) a sym-link to /usr/bin/ls.

Aside: What if hard links are used in lieu of sym-links?

Without a clear definition of what a proper executable (binary?) is,
it's near impossible to derive a test that takes into account many
different things that Unix has done over the years. Especially if you
want to account for more esoteric things like over-mounting, hard links,
LD_PRELOAD interceptions, etc.

--
Grant. . . .
unix || die

Ottavio Caruso wrote:

> How can I check that a number of programs are installed _and_ point to a
> true executable rather than a shell script or similar?

Shell scripts *are* true executables. For example:

$ type google-chrome
google-chrome is /bin/google-chrome
$ file /bin/google-chrome
/bin/google-chrome: Bourne-Again shell script, ASCII text executable

This is the genuine google-chrome browser, as provided by Google in
a .deb package. Of course, the script ends up executing a binary,
but that binary is not intended to be executed directly by users.

If you want to distinguish original shell scripts from ones a user
has created, you could perhaps use command -p -v to do a PATH search
of only the "system" PATH instead of the user's PATH. However, there
can be legitimate reasons for users to create wrapper scripts. For
example, I have:

$ cat ~/bin/mutt
#! /bin/sh

# this prevents blinking
case $TERM in
xterm) TERM=xterm-256color ;;
esac

exec /bin/mutt "$@"

You do your users a disservice if you prevent them doing such things.

--
Geoff Clare <netnews@gclare.org.uk>

In article <ubt0hi-e6r.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:
>Ottavio Caruso wrote:
>
>> How can I check that a number of programs are installed _and_ point to a
>> true executable rather than a shell script or similar?
>
>Shell scripts *are* true executables. For example:

Indeed. It is really hard to figure out what OP's real problem is.

It would be useful if he would give us a good example (i.e., description
of) the problem/error case he is worried about. i.e., what is the failure?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Pedantic

On 3/25/22 11:37 AM, Kenny McCormack wrote:
> It would be useful if he would give us a good example (i.e.,
> description of) the problem/error case he is worried about.

+10

--
Grant. . . .
unix || die

In article <t1l2eh$kvr$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/25/22 11:37 AM, Kenny McCormack wrote:
>> It would be useful if he would give us a good example (i.e.,
>> description of) the problem/error case he is worried about.
>
>+10

Thank you.

--
Life's big questions are big in the sense that they are momentous. However, contrary to
appearances, they are not big in the sense of being unanswerable. It is only that the answers
are generally unpalatable. There is no great mystery, but there is plenty of horror.
(https://en.wikiquote.org/wiki/David_Benatar)

On 25/03/2022 17:37, Kenny McCormack wrote:
> It would be useful if he would give us a good example (i.e., description
> of) the problem/error case he is worried about. i.e., what is the
failure?

See below.

On 25/03/2022 13:40, Geoff Clare wrote:
> If you want to distinguish original shell scripts from ones a user
> has created, you could perhaps use command -p -v to do a PATH search
> of only the "system" PATH instead of the user's PATH.

Thanks. `command -p` is exactly what I was looking for

$ (command -v ffmpeg 2>/dev/null)&& echo success || echo failure
/home/oc/opt/bin/ffmpeg
success

$ (command -p ffmpeg 2>/dev/null)&& echo success || echo failure
failure

Pedantic question: Is `command -p` implemented consistently across all
/bin/sh clones? Can the user hack the " PATH that guarantees to find all
the standard utilities"?

--
Ottavio Caruso

On 3/29/22 4:38 AM, Ottavio Caruso wrote:
> See below.

I don't see an answer to what the problem / error case is.

The example is a couple of options related to ffmpeg. But nothing about
why /home/oc/opt/bin/ffmpeg vs /usr/local/bin/ffmpeg is a problem.

> Thanks. `command -p` is exactly what I was looking for

My read of Zsh's man page for `command -p` makes me believe that
(symbolic) links will be followed. And I thought that you had indicated
that you wanted to exclude (symbolic) links too.

> Pedantic question: Is `command -p` implemented consistently across all
> /bin/sh clones?

I don't know.

> Can the user hack the PATH that guarantees to find all the standard
> utilities?

I don't know if the /user/ can or not. I strongly suspect that an
administrator can change the system / default path to be anything they want.

Also, what is the "default path" and how does it differ from the
(user's) "non-default path"? -- What if a system administrator puts a
symbolic link in a directory that's earlier in the default path? E.g.

PATH=/bin:/usr/bin:/usr/local/bin

/bin/ffmpeg -> /home/oc/opt/bin/ffmpeg

I strongly suspect that even `command -p ffmpeg` would produce unwanted
results.

If you don't like the sym-link, try a hard link on a common file system.
Or how about a wrapper script. Or how about a compiled binary that
shells out to /home/oc/opt/bin/ffmpeg.

We still don't have any working understanding of what the problem /
error case is that you are worried about.

--
Grant. . . .
unix || die

Grant Taylor wrote:

> On 3/29/22 4:38 AM, Ottavio Caruso wrote:
>
>> Thanks. `command -p` is exactly what I was looking for
>
> My read of Zsh's man page for `command -p` makes me believe that
> (symbolic) links will be followed. And I thought that you had indicated
> that you wanted to exclude (symbolic) links too.

I suggested command -v -p because I suspected that what Ottavio really
wanted was to distinguish "original" (system-supplied) executables from
user-supplied ones, rather than taking any notice of what type of
executable they are. I gave an example of an original shell script
(google-chrome), but the same would apply to symbolic links as well.

>
>> Pedantic question: Is `command -p` implemented consistently across all
>> /bin/sh clones?

POSIX requires that it searches a default PATH "that is guaranteed to
find all of the standard utilities", instead of the PATH value from
the environment. The contents of the default PATH could be chosen by
the shell author, or they could leave it to the C library by using
confstr() with _CS_PATH to obtain a suitable PATH.

>> Can the user hack the PATH that guarantees to find all the standard
>> utilities?

No, it's built into the shell. (The "command" utility is necessarily
implemented as a shell built-in.)

--
Geoff Clare <netnews@gclare.org.uk>