[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24471: 25.1.50; Error on empty PATH component
From: |
Eli Zaretskii |
Subject: |
bug#24471: 25.1.50; Error on empty PATH component |
Date: |
Mon, 17 Oct 2016 21:53:48 +0300 |
> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 17 Oct 2016 20:16:17 +0200
>
> POSIX specifically prescribes that an empty PATH element equals "." and
> declares that a legacy feature that strictly conforming applications
> shall not use, but in other environment variables an empty path element
> is also allowed and replaced by different defaults. For NLSPATH that
> default is %N and for MANPATH it usually means some system-defined
> (POSIX doesn't mention that possibility).
>
> Whether default-directory equates "." seems to depend on when it gets
> evaluated, since it's normally set to some absolute path. So a textual
> replacement with "." seems more correct than some hand-waving about nil
> representing current-directory in the case of PATH.
I think you are wrong, because you don't realize what is Emacs's
interpretation of "." in exec-path. The interpretation is exactly
default-directory, AFAIR. And that is TRT, because Emacs interprets
"." and default-directory as being local to each buffer. IOW,
conceptually, when you switch to another buffer, you effectively chdir
into its default-directory.
Bottom line, "legacy feature" aside, I think converting an empty PATH
element to "." in exec-path conforms to POSIX, and therefore there's
no issue here left after Glenn pushed his changes.