Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Stefan Monnier]

>     * src/fileio.c (Fexpand_file_name): Don't directly use the current
>     buffer's default-directory if it is relative.  Instead replace it
>     by its expansion relative to invocation-directory.  (Bug#36502)

I don't think invocation-directory is a better choice than any
other directory.  A relative `default-directory` value is an error.
We should signal that error rather than try and paper over it.


        Stefan

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 08 Jul 2019 19:13:52 -0400
> Cc: emacs-devel@gnu.org
> 
> >     * src/fileio.c (Fexpand_file_name): Don't directly use the current
> >     buffer's default-directory if it is relative.  Instead replace it
> >     by its expansion relative to invocation-directory.  (Bug#36502)
> 
> I don't think invocation-directory is a better choice than any
> other directory.  A relative `default-directory` value is an error.
> We should signal that error rather than try and paper over it.

In the bug discussion I explained why I thought this alternative was
better.

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Daniel Sutton]

[-- Attachment #1: Type: text/plain, Size: 82 bytes --]

#36502 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36502) if you are
inclined.

[-- Attachment #2: Type: text/html, Size: 169 bytes --]

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Stefan Monnier]

> In the bug discussion I explained why I thought this alternative was
> better.

I didn't see it there.  You mentioned that you preferred to avoid the
inf-loop, but that doesn't mean you prefer for expand-file-name to use
an arbitrary (hopefully) absolute file name as default
default directory over signaling an error.

In the OP's description of the problem, clearly the relative
default-directory is in error, so trying to fix this case by changing
one of Emacs core functions instead of just fixing that minor error
seems odd: most likely the minor error will have to be fixed anyway
because it will bump into other errors elsewhere or because it needs to
work with Emacs<27.

Signaling a clear error here would have helped the programmer find the
real problem and fix it quickly, whereas the patch we installed caters
to broken code, encouraging bad practices.

Don't get me wrong: this is a minor issue, and I don't think it matters
very much, but I'm rather surprised by the patch.


        Stefan

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Ken Brown]

On 7/8/2019 11:46 PM, Stefan Monnier wrote:
> Signaling a clear error here would have helped the programmer find the
> real problem and fix it quickly, whereas the patch we installed caters
> to broken code, encouraging bad practices.

FWIW, expand-file-name (before the patch) already allowed the user to specify a 
default directory that is not even a string.  This has been the case since 1997:

commit 82330e7fc0025b7eab669c19e6f4977aebe8cb13
Author: Richard M. Stallman <rms@gnu.org>
Date:   Fri Sep 5 01:21:43 1997 +0000

     (Fexpand_file_name): If default dir isn't string, use `/'.


Ken

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kbrown@cornell.edu,  emacs-devel@gnu.org
> Date: Mon, 08 Jul 2019 23:46:06 -0400
> 
> > In the bug discussion I explained why I thought this alternative was
> > better.
> 
> I didn't see it there.

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36502#46

> You mentioned that you preferred to avoid the inf-loop, but that
> doesn't mean you prefer for expand-file-name to use an arbitrary
> (hopefully) absolute file name as default default directory over
> signaling an error.

It isn't entirely arbitrary.  A relative file name can be interpreted
by taking some directory as cwd.  Is there a better candidate for that
than invocation-directory?  We cannot use "." and we cannot use nil in
this case, for obvious reasons.

> Signaling a clear error here would have helped the programmer find the
> real problem and fix it quickly, whereas the patch we installed caters
> to broken code, encouraging bad practices.

I think expand-file-name should try to avoid signaling an error as
much as possible, because it is called by many primitives and core
functions.  If we signal an error, we risk getting the users into a
situation where they cannot even shut down Emacs, let alone do
something less trivial.

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Stefan Monnier]

> It isn't entirely arbitrary.

I'd have gone with "/", but I also consider that as arbitrary: I don't
think there can be a non-arbitrary choice here, other than signaling
an error because we don't have any information that can give us a hint
about what was the intended absolute directory.

> I think expand-file-name should try to avoid signaling an error as
> much as possible, because it is called by many primitives and core
> functions.  If we signal an error, we risk getting the users into a
> situation where they cannot even shut down Emacs, let alone do
> something less trivial.

A relative default-directory is something extremely rare, so if some
operations like C-x C-c fail in that case I wouldn't mind.


        Stefan

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kbrown@cornell.edu,  emacs-devel@gnu.org
> Date: Tue, 09 Jul 2019 11:25:50 -0400
> 
> > It isn't entirely arbitrary.
> 
> I'd have gone with "/", but I also consider that as arbitrary: I don't
> think there can be a non-arbitrary choice here, other than signaling
> an error because we don't have any information that can give us a hint
> about what was the intended absolute directory.

I see nothing wrong with a somewhat arbitrary interpretation of such a
default-directory value.

> > I think expand-file-name should try to avoid signaling an error as
> > much as possible, because it is called by many primitives and core
> > functions.  If we signal an error, we risk getting the users into a
> > situation where they cannot even shut down Emacs, let alone do
> > something less trivial.
> 
> A relative default-directory is something extremely rare, so if some
> operations like C-x C-c fail in that case I wouldn't mind.

I agree that it is rare, but trapping the user even rarely is
something I'd like to avoid as much as reasonably possible.

Re: [Emacs-diffs] master 0528a7c: Ensure that expand-file-name returns an absolute file name

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   A relative `default-directory` value is an error.
  > We should signal that error rather than try and paper over it.

That would be logical, but maybe it could also cause a situation where
you can't access any file.  If you're a wizard, you could get out by
setting that variable -- but nonwizards wouldn't know how to get out
of this.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)