exec-path "/:" prefix; file-name-handler-*; start-process

exec-path "/:" prefix; file-name-handler-*; start-process

[Karl Chen]

Why does initializing `exec-path' need to prepend a "/:" to paths that
"would otherwise be treated as magic" ?
[emacs.c : decode_env_path ():
      ...
      tem = Ffind_file_name_handler (element, Qt);
      if (! NILP (tem))
        element = concat2 (build_string ("/:"), element);
      ...
]

All single-directory (single slash) paths in PATH such as /bin turn into
/:/bin. This may be the fault of sloppy regexes in ange-ftp. Seems like a
dirty hack, having to say "this is a normal path."

At first I thought it was a bug - there are unresolved bug reports about
it in debian archives. I even wrote a lisp kludge around it to get rid of
all initial "/:"s in exec-path.

I use (simplified):
  (setq explicit-shell-file-name (which "bash"))

On many systems bash is first found in /bin. (which "bash") finds
"/:/bin/bash" since (file-executable-p "/:/bin/bash") returns t. However,
"/:/bin/bash" is not acceptable as an `explicit-shell-file-name' for
`shell' since it eventually calls `comint-exec' which calls
`start-process'.

I think either the /: prefixing can/should be removed from
decode_env_path(), or file-name-handler stuff should be expanded to
start-process and possibly other functions.

If it still is neccessary for exec-path to have "/:" for single-directory
paths (probably is; I don't know anything about emacs internals), then it
should at least be documented in `exec-path' that the default-generated
directory names in it could have a superfluous /:  prepended. Then it
would have been easy to figure out to add a "s,^/:,," in which.el.

-- 
Karl Chen / quarl@quarl.org

Re: exec-path "/:" prefix; file-name-handler-*; start-process

[Kai Großjohann]

Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:

> Why does initializing `exec-path' need to prepend a "/:" to paths that
> "would otherwise be treated as magic" ?
> [emacs.c : decode_env_path ():
>       ...
>       tem = Ffind_file_name_handler (element, Qt);
>       if (! NILP (tem))
>         element = concat2 (build_string ("/:"), element);
>       ...
> ]
>
> All single-directory (single slash) paths in PATH such as /bin turn
> into /:/bin. This may be the fault of sloppy regexes in
> ange-ftp. Seems like a dirty hack, having to say "this is a normal
> path."

Just a random thought on this: it's clearly useful that Ange-FTP
grabs filenames like these -- this enables user/host name
completion.

But now, Tramp takes over those files, and so in principle, one could
require the user to use "/ftp:foo" filenames when user/host name
completion is desired, so it might not be necessary anymore to have
Ange-FTP (or Tramp) grab filenames like "/foo".

I'm not sure what to do, though.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: exec-path "/:" prefix; file-name-handler-*; start-process

[Richard Stallman]

    Why does initializing `exec-path' need to prepend a "/:" to paths that
    "would otherwise be treated as magic" ?

Because without that they really would mean something else.
If you have a directory /foo:, Emacs would get confused by the
name /foo: without the /: in front.

    All single-directory (single slash) paths in PATH such as /bin turn into
    /:/bin.

The name /bin is not really magic, but it seems to be magic
because of the hostname completion facility.
These names don't need to have /: added, and should not have it.

In the current development version, /: is not added to them.
I am not sure what caused the change; perhaps it has to do
with installing Tramp.  It could be that this has introduced
some other bug or that the hostname completion facility
has been deactivated.  Kai, could you see whether the hostname completion
facility still works?

Anyway, I fixed this problem for 21.3.

    On many systems bash is first found in /bin. (which "bash") finds
    "/:/bin/bash" since (file-executable-p "/:/bin/bash") returns t. However,
    "/:/bin/bash" is not acceptable as an `explicit-shell-file-name' for
    `shell' since it eventually calls `comint-exec' which calls
    `start-process'.

"/:/bin/bash" is a valid name in Emacs for that file,
so it should work in start-process.  I fixed that, and
call-process too.

Re: exec-path "/:" prefix; file-name-handler-*; start-process

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> In the current development version, /: is not added to them.
> I am not sure what caused the change; perhaps it has to do
> with installing Tramp.  It could be that this has introduced
> some other bug or that the hostname completion facility
> has been deactivated.  Kai, could you see whether the hostname completion
> facility still works?

Tramp does not support hostname completion at the moment.  Luckily,
Michael Albinus has already written code to support it.  It still
needs to be tested, though.

But I have no idea (yet) what will happen to "/:" in exec-path after
Michael's feature is added to Tramp.  Hm.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: exec-path "/:" prefix; file-name-handler-*; start-process

[Richard Stallman]

    But I have no idea (yet) what will happen to "/:" in exec-path after
    Michael's feature is added to Tramp.  Hm.

I fixed the problem in general.  You just need to add a safe-magic
property to the handler that you use to complete single-component file
names as possible host names.