Re: Problem with kpsewhich on a new instal

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