I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]
%

%sh -c 'which pdflatex'
/home/x/miktex2/miktex/bin/x64/pdflatex
%

That's correct. But the following result confuses the hell out of me.
I'm not specifying any SHELL to make, so it must be using my local POSIX
sh.

%cat Makefile
default: bcw.pdf

bcw.pdf: Makefile bcw.tex
pdflatex bcw && pdflatex bcw

clean:
rm -f *.aux *~ *.log bcw.pdf
%

%make
pdflatex bcw && pdflatex bcw
/usr/bin/sh: line 1: pdflatex: command not found
make: *** [Makefile:6: bcw.pdf] Error 127
%

Very puzzled. How I can see through the fog here? Thank you.

%/usr/bin/sh --version
/usr/bin/sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
%

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

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]
%

By the way, I'm just truncating the long list of paths that are
irrelevant here.

%sh -c 'which pdflatex'
/home/x/miktex2/miktex/bin/x64/pdflatex
%

[...]

Here's perhaps a smaller example.

%sh -c 'which pdflatex'
/home/x/miktex2/miktex/bin/x64/pdflatex

%sh -c 'pdflatex bcw'
sh: line 1: pdflatex: command not found

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]
%

%sh -c 'echo $PATH && which pdflatex && pdflatex' ~/spdf:~/miktex2/miktex/bin/x64:[...]
/home/x/miktex2/miktex/bin/x64/pdflatex
sh: line 1: pdflatex: command not found
%

I can't see what could be causing this.

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

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]
%

%sh -c 'which pdflatex'
/home/x/miktex2/miktex/bin/x64/pdflatex
%

That's correct. But the following result confuses the hell out of me.
I'm not specifying any SHELL to make, so it must be using my local POSIX
sh.

%cat Makefile
default: bcw.pdf

bcw.pdf: Makefile bcw.tex
pdflatex bcw && pdflatex bcw

clean:
rm -f *.aux *~ *.log bcw.pdf
%

%make
pdflatex bcw && pdflatex bcw
/usr/bin/sh: line 1: pdflatex: command not found
make: *** [Makefile:6: bcw.pdf] Error 127
%

Very puzzled. How I can see through the fog here? Thank you.

%/usr/bin/sh --version
/usr/bin/sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
%

I'm not entirely sure under what circumstances ~ is expanded in $PATH.
bash seems to do it, but $PATH is also used by the execlp(), execvp(),
and execvpe() library functions, and I'm fairly sure they don't treat
the '~' character as special.

If you have literal ~ characters in your $PATH, you'll have some things expanding it to your home directory and some things not.

~ is equivalent to $HOME for most purposes, but $HOME is expanded in double-quoted strings and ~ is not:

$ echo $HOME ~kst "$HOME" "~"
/home/kst /home/kst /home/kst ~
$

I suggest avoiding the issue by updating whatever you use to set $PATH
(some code in $HOME/.bash_profile, perhaps) so it refers to $HOME rather
than ~. It should then expand to the full path of your home directory.

(And note that ~user is different from ~. ~ expands to the current
value of the $HOME environment variable. ~user does a lookup in
/etc/password or equivalent to determine user's home directory.)

--
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 */

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

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

What’s that expectation based on? I don’t see any mention of it here:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

--
https://www.greenend.org.uk/rjk/

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]
%

%sh -c 'which pdflatex'
/home/x/miktex2/miktex/bin/x64/pdflatex
%

That's correct. But the following result confuses the hell out of me.
I'm not specifying any SHELL to make, so it must be using my local POSIX
sh.

%cat Makefile
default: bcw.pdf

bcw.pdf: Makefile bcw.tex
pdflatex bcw && pdflatex bcw

clean:
rm -f *.aux *~ *.log bcw.pdf
%

%make
pdflatex bcw && pdflatex bcw
/usr/bin/sh: line 1: pdflatex: command not found
make: *** [Makefile:6: bcw.pdf] Error 127
%

Very puzzled. How I can see through the fog here? Thank you.

%/usr/bin/sh --version
/usr/bin/sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
%

I'm not entirely sure under what circumstances ~ is expanded in $PATH.
bash seems to do it, but $PATH is also used by the execlp(), execvp(),
and execvpe() library functions, and I'm fairly sure they don't treat
the '~' character as special.

If you have literal ~ characters in your $PATH, you'll have some things expanding it to your home directory and some things not.

~ is equivalent to $HOME for most purposes, but $HOME is expanded in double-quoted strings and ~ is not:

$ echo $HOME ~kst "$HOME" "~"
/home/kst /home/kst /home/kst ~
$

I suggest avoiding the issue by updating whatever you use to set $PATH
(some code in $HOME/.bash_profile, perhaps) so it refers to $HOME rather
than ~. It should then expand to the full path of your home directory.

Great idea. I hadn't thought of that. Problem solved.

(And note that ~user is different from ~. ~ expands to the current
value of the $HOME environment variable. ~user does a lookup in /etc/password or equivalent to determine user's home directory.)

Lol. I took a while to understand this. I kept trying to see what
``~.'' would expand to 'til I realized the dot was just sentence
punctuation. Well, thank you for pointing that out: I did not know
there was a difference.

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

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

What’s that expectation based on? I don’t see any mention of it here:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

You're right. My expectation was unfounded. It worked with bash and I implicitly assumed it would have been a premise of POSIX. Thank you for pointing it out.

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

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]

How did you get the "~" character into the PATH environment variable?

Unless you quote it, it will be processed immediately by the shell
and will not be part of the environment variable:

$ PATH=/usr/bin:~/bin
$ echo $PATH
/usr/bin:/home/scott/bin
$ type antiword
antiword is a tracked alias for /home/scott/bin/antiword
$ PATH=/usr/bin:"~/bin"
$ echo $PATH
/usr/bin:~/bin
$ type antiword
-ksh: whence: antiword: not found

The library code for execlp will not perform the ~ substitution,
so placing it in the PATH variable will not work.

BASH is only a "POSIX" shell when the POSIXLY_CORRECT variable is set
because the GNU folks are under the mistaken impression that POSIX requirements are "ridiculous".

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

Meredith Montgomery <mmontgomery@levado.to> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

(And note that ~user is different from ~. ~ expands to the current
value of the $HOME environment variable. ~user does a lookup in
/etc/password or equivalent to determine user's home directory.)

Lol. I took a while to understand this. I kept trying to see what
``~.'' would expand to 'til I realized the dot was just sentence
punctuation. Well, thank you for pointing that out: I did not know
there was a difference.

I probably should have used backticks. (Markdown uses backticks to
enclose text that's meant to be read as code.) I also sometimes add a
space before the '.' at the end of a sentence to avoid confusion; I
could have done so here.

`~.`, at least in bash, "expands" to `~.`.

The rules about when ~ is expanded are moderately complicated (and I
don't know all of them). ~ and ~user are useful shortcuts when typing
at the command line, but I suggest using $HOME instead. The rules for
variable expansion (or "parameter expansion" as the documentation calls
it) are perhaps equally obscure, but better known.

--
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 */

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

scott@slp53.sl.home (Scott Lurndal) writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]

How did you get the "~" character into the PATH environment variable?

Unless you quote it, it will be processed immediately by the shell
and will not be part of the environment variable:

$ PATH=/usr/bin:~/bin
$ echo $PATH
/usr/bin:/home/scott/bin
$ type antiword
antiword is a tracked alias for /home/scott/bin/antiword
$ PATH=/usr/bin:"~/bin"
$ echo $PATH
/usr/bin:~/bin
$ type antiword
-ksh: whence: antiword: not found

The library code for execlp will not perform the ~ substitution,
so placing it in the PATH variable will not work.

BASH is only a "POSIX" shell when the POSIXLY_CORRECT variable is set
because the GNU folks are under the mistaken impression that POSIX requirements
are "ridiculous".

It's better than the old name: POSIX_ME_HARDER .

--
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 */

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

Meredith Montgomery wrote:

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH.

What’s that expectation based on? I don’t see any mention of it here:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

You're right. My expectation was unfounded. It worked with bash and I implicitly assumed it would have been a premise of POSIX.

Some things in bash behave differently depending on whether it is
invoked as "bash" or as "sh". This is one of them. When invoked as
"sh" you get behaviour that is closer to POSIX requirements. (For
full conformance you need to set POSIXLY_CORRECT in the environment,
as mentioned elsewhere in the thread.)

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

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

scott@slp53.sl.home (Scott Lurndal) writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I expected a POSIX sh to expand tilde in path names in $PATH. It seems
to do it.

%echo $PATH
~/spdf:~/miktex2/miktex/bin/x64:[...]

How did you get the "~" character into the PATH environment variable?

Unless you quote it, it will be processed immediately by the shell
and will not be part of the environment variable:

I quoted it.

%export HELLO='~/world'
%echo $HELLO
~/world
%

$ PATH=/usr/bin:~/bin
$ echo $PATH
/usr/bin:/home/scott/bin
$ type antiword
antiword is a tracked alias for /home/scott/bin/antiword
$ PATH=/usr/bin:"~/bin"
$ echo $PATH
/usr/bin:~/bin
$ type antiword
-ksh: whence: antiword: not found

The library code for execlp will not perform the ~ substitution,
so placing it in the PATH variable will not work.

BASH is only a "POSIX" shell when the POSIXLY_CORRECT variable is set
because the GNU folks are under the mistaken impression that POSIX requirements
are "ridiculous".

:-) I believe you, but I also wouldn't be surprised if they have a point.

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