GNU bug report logs - #24471
25.1.50; Error on empty PATH component

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Achim Gratz <Stromeko <at> nexgo.de>
Cc: 24471 <at> debbugs.gnu.org
Subject: bug#24471: 25.1.50; Error on empty PATH component
Date: Mon, 17 Oct 2016 21:53:48 +0300

> From: Achim Gratz <Stromeko <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.