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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <t1f5if$vme$[email protected]>,
Ottavio Caruso <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In our last episode, the evil Dr. Lacto had captured our hero,
Ottavio Caruso <[email protected]>, 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 [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> 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) [email protected]
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)