Re: Problem with kpsewhich on a new instal

    Paulo's report suggests that "~" doesn't currently work in $PATH.

It's the shell that is supposed to expand ~ on command lines,
particularly, in PATH assignments.  And if it doesn't (e.g., an old
/bin/sh), programs won't be found. This has nothing to do with
Kpathsea. I'm sure you know this.  Kpathsea doesn't treat PATH specially
in terms of expansion.

It's true that the particular code in progname.c (line 354ff.)  that
tries to do the self-locating does not do ~ expansion (or $ expansion or
{} expansion or anything else). As far as I know, it is not expected for
every single program that looks at PATH to have to do every kind of
expansion on the path elements. You're just supposed to take the PATH
elements as they are given. I believe.

Normally, the shell will expand ~ at the time PATH is setup:
$ PATH=~
$ echo $PATH
/u/karl

If PATH contains a literal ~, that is normally interpreted as a directory
named, literally, "~".  I see that bash apparently double-interprets the
~, but that's a (strange IMHO) behavior of bash. If I try dash, I get
the expected "program not found" when trying to use a literal ~ as a
PATH element:

/bin/dash      # start shell
$ PATH=\~/bin  # get literal ~ in PATH
$ echo "$PATH" # show that it's literal
~/bin
$ testprog     # try to execute a program from ~/bin -> not found
/bin/dash: 3: testprog: not found
$ ~/bin/testprog  # but of course I can execute it as an absolute filename
i am testprog

(~/bin/testprog contains the one line "echo i am testprog".)

I don't know what causes Paulo's original error,
  lstat(./kpsewhich) failed: ./kpsewhich: No such file or directory kpathsea:
  Can't get directory of program name: ./kpsewhich
since I can't reproduce it. But if there is a literal ~ in PATH, I can't
say I'm surprised that strange things happen. -k