Re: Problem with kpsewhich on a new instal

AFAIK the TL installer does not rely on PATH and explicitly uses the
full path specification of the binaries. Imagine that you already have
another version of TL installed and you are installing the new one, If
the installer depended on PATH, it would call the old binaries and the
whole process would most probably crash.

Zdeněk Wagner
https://www.zdenek-wagner.eu/

Facebook canceled my account without giving a specific reason.
Facebook kansellerte kontoen min uten å oppgi noen spesifikk grunn.
Facebook mi zrušil účet bez uvedení konkrétního důvodu.
फेसबुक ने बिना कोई खास कारण बताए मेरा अकाउंट बंद कर दिया है।

po 18. 5. 2026 v 7:26 odesílatel Paulo Ney de Souza <[email protected]> napsal:
>
> Hi Max,
>
> But why would the TL installer take it in and proceed with the entire installation?
>
> PN
>
> On Sun, May 17, 2026 at 9:58 PM Max Chernoff <[email protected]> wrote:
>>
>> Hi Paulo,
>>
>> On Sun, 2026-05-17 at 18:10 -0700, Paulo Ney de Souza wrote:
>> > I do need to use a PATH relative to my home directory because the admin's
>> > on the machine move users home directories frequently... and in fact, most
>> > things are broken:
>> >
>> > $ which lualatex
>> > ~/usr/local/texlive/2026/bin/x86_64-linux/lualatex
>>
>> Tilde expansion is a shell feature, so I'm rather surprised that this
>> ever worked at all. You never mentioned what your $PATH is exactly, but
>> I'm guessing that your ".<shell>rc" file has something like the
>> following in it:
>>
>>     export PATH=~/some/path:/usr/bin
>>
>> I'd suggest that you replace that with
>>
>>     export PATH=$HOME/some/path:/usr/bin
>>
>> then your $PATH will always only have absolute paths, while still
>> adapting to any changes in the location of your home directory.
>>
>> On Sun, May 17, 2026 at 5:51 PM Paulo Ney de Souza <[email protected]>
>> wrote:
>> > I thought I had seen this some 20 years ago ... is this something that
>> > will be fixed?
>>
>> Karl will be the one who decides what to do here, but I'd argue that the
>> current behaviour is correct, since this matches the GNU coreutils's
>> behaviour:
>>
>>     $ mkdir -p ~/testing
>>     $ cd ~/testing/
>>     $ printf '#!/bin/sh\necho "Hello, world!"\n' > test.sh
>>     $ chmod a+x test.sh
>>     $ PATH="/usr/bin/:~/testing" env test.sh
>>     env: ‘test.sh’: No such file or directory
>>     $ PATH="/usr/bin/:$HOME/testing" env test.sh
>>     Hello, world!
>>
>> Plus, "~" is a perfectly valid character to use in a filename (and is
>> notably used in Windows for short path names), so if we were to expand
>> it, we would need to make sure to only expand it if it's at the start of
>> a $PATH component. The path parsing code in kpathsea is
>> security-sensitive since it's what ultimately determines if a program is
>> allowed to run when restricted shell-escape is active, so the fewer
>> special cases we need there, the better.
>>
>> Thanks,
>> -- Max