* bug#33564: Incorrect path canonicalisation @ 2018-12-01 20:04 Mattias Andrée 2018-12-01 20:27 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Mattias Andrée @ 2018-12-01 20:04 UTC (permalink / raw) To: 33564 Emacs 26.1 removes ..'s incorrectly from file names. Emacs removes the directory in front the .. rather than getting its parent directory. Example: cd mkdir -p 1/2 cd 1/2 echo 3 > ../../3 ln -s ~ 4 echo 5 > 5 emacs 4/../5 # works, but shouldn't emacs 4/../$USER/3 # does not works, should On Linux, the proper way to get the canonical path for a file with the file descriptor $fd: stat(3) /dev/fd/$fd p := readlink(3) /dev/fd/$fd if (st_nlinks != 0) { stat(3) /dev/fd/$fd if (st_nlinks == 0) { p := readlink(3) /dev/fd/$fd remove " (deleted)" from the end of p } } else { remove " (deleted)" from the end of p } canonical path is p ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:04 bug#33564: Incorrect path canonicalisation Mattias Andrée @ 2018-12-01 20:27 ` Andreas Schwab 2018-12-01 20:35 ` Mattias Andrée 2018-12-01 20:30 ` Eli Zaretskii 2019-08-21 2:26 ` Stefan Kangas 2 siblings, 1 reply; 8+ messages in thread From: Andreas Schwab @ 2018-12-01 20:27 UTC (permalink / raw) To: Mattias Andrée; +Cc: 33564 On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: > Emacs 26.1 removes ..'s incorrectly from file names. > Emacs removes the directory in front the .. rather than > getting its parent directory. This is deliberate. Emacs never consults the filesystem when canonicalizing filenames, as documented in expand-file-name. This is consistent with the logical view of the filesystem, and how the shell builtin cd handles it. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:27 ` Andreas Schwab @ 2018-12-01 20:35 ` Mattias Andrée 2018-12-01 20:55 ` Andreas Schwab 0 siblings, 1 reply; 8+ messages in thread From: Mattias Andrée @ 2018-12-01 20:35 UTC (permalink / raw) To: Andreas Schwab; +Cc: 33564 On Sat, 1 Dec 2018 21:27:27 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: > On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: > > > Emacs 26.1 removes ..'s incorrectly from file names. > > Emacs removes the directory in front the .. rather than > > getting its parent directory. > > This is deliberate. Emacs never consults the filesystem when > canonicalizing filenames, as documented in expand-file-name. This is > consistent with the logical view of the filesystem, and how the shell > builtin cd handles it. What is the rationale for this? No other program Bash and Emacs behave this way, including the coreutils. It seems odd that the Bash suggest file from the wrong directory so that even the coreutils cannot find them, only Emacs. > > Andreas. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:35 ` Mattias Andrée @ 2018-12-01 20:55 ` Andreas Schwab 2018-12-01 21:14 ` Mattias Andrée 0 siblings, 1 reply; 8+ messages in thread From: Andreas Schwab @ 2018-12-01 20:55 UTC (permalink / raw) To: Mattias Andrée; +Cc: 33564 On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: > On Sat, 1 Dec 2018 21:27:27 +0100 > Andreas Schwab <schwab@linux-m68k.org> wrote: > >> On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: >> >> > Emacs 26.1 removes ..'s incorrectly from file names. >> > Emacs removes the directory in front the .. rather than >> > getting its parent directory. >> >> This is deliberate. Emacs never consults the filesystem when >> canonicalizing filenames, as documented in expand-file-name. This is >> consistent with the logical view of the filesystem, and how the shell >> builtin cd handles it. > > What is the rationale for this? Canonicalizing is a pure textual operation. > No other program Bash and Emacs behave this way, including the > coreutils. This is not true, as I explained above. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:55 ` Andreas Schwab @ 2018-12-01 21:14 ` Mattias Andrée 2018-12-02 6:27 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Mattias Andrée @ 2018-12-01 21:14 UTC (permalink / raw) To: Andreas Schwab; +Cc: 33564 On Sat, 1 Dec 2018 21:55:29 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: > On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: > > > On Sat, 1 Dec 2018 21:27:27 +0100 > > Andreas Schwab <schwab@linux-m68k.org> wrote: > > > >> On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote: > >> > >> > Emacs 26.1 removes ..'s incorrectly from file names. > >> > Emacs removes the directory in front the .. rather than > >> > getting its parent directory. > >> > >> This is deliberate. Emacs never consults the filesystem when > >> canonicalizing filenames, as documented in expand-file-name. This is > >> consistent with the logical view of the filesystem, and how the shell > >> builtin cd handles it. > > > > What is the rationale for this? > > Canonicalizing is a pure textual operation. Yes, you said, but why should Emacs canonicalise the file names given in the command line in the first place? One would expect that if you examine a file with for example stat or cat, you with be working with that file with you give Emacs the same file name. > > > No other program Bash and Emacs behave this way, including the > > coreutils. > > This is not true, as I explained above. Okay, dash also behaves this way, but ls, cat, and nano, for example don't (and no, you didn't explain, nor should you have, you should have given counter examples, preferably GNU program). I don't know any other program that behaves this way. The same think goes for resolving ~, normal programs use the file names given in the command line as is. > > Andreas. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 21:14 ` Mattias Andrée @ 2018-12-02 6:27 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2018-12-02 6:27 UTC (permalink / raw) To: Mattias Andrée; +Cc: schwab, 33564 > Date: Sat, 1 Dec 2018 22:14:30 +0100 > From: Mattias Andrée <maandree@kth.se> > Cc: 33564@debbugs.gnu.org > > why should Emacs canonicalise the file names given in the command > line in the first place? One reason is so that it could meaningfully compare file names as strings. Another reason is that relative file names change their meaning when you switch buffers, because Emacs behaves in a way that switching buffers conceptually changes your working directory to the directory of that buffer. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:04 bug#33564: Incorrect path canonicalisation Mattias Andrée 2018-12-01 20:27 ` Andreas Schwab @ 2018-12-01 20:30 ` Eli Zaretskii 2019-08-21 2:26 ` Stefan Kangas 2 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2018-12-01 20:30 UTC (permalink / raw) To: Mattias Andrée; +Cc: 33564 tags 33564 notabug thanks > Date: Sat, 1 Dec 2018 21:04:50 +0100 > From: Mattias Andrée <maandree@kth.se> > > cd > mkdir -p 1/2 > cd 1/2 > echo 3 > ../../3 > ln -s ~ 4 > echo 5 > 5 > emacs 4/../5 # works, but shouldn't > emacs 4/../$USER/3 # does not works, should This is by design: expand-file-name doesn't follow symlinks. It's documented not to do that: see the doc string and the ELisp manual. > On Linux, the proper way to get the canonical path > for a file with the file descriptor $fd: expand-file-name doesn't aim at yielding the canonical file name in that sense. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33564: Incorrect path canonicalisation 2018-12-01 20:04 bug#33564: Incorrect path canonicalisation Mattias Andrée 2018-12-01 20:27 ` Andreas Schwab 2018-12-01 20:30 ` Eli Zaretskii @ 2019-08-21 2:26 ` Stefan Kangas 2 siblings, 0 replies; 8+ messages in thread From: Stefan Kangas @ 2019-08-21 2:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Mattias Andrée, 33564-done Eli Zaretskii <eliz@gnu.org> writes: > tags 33564 notabug > thanks > >> Date: Sat, 1 Dec 2018 21:04:50 +0100 >> From: Mattias Andrée <maandree@kth.se> >> >> cd >> mkdir -p 1/2 >> cd 1/2 >> echo 3 > ../../3 >> ln -s ~ 4 >> echo 5 > 5 >> emacs 4/../5 # works, but shouldn't >> emacs 4/../$USER/3 # does not works, should > > This is by design: expand-file-name doesn't follow symlinks. It's > documented not to do that: see the doc string and the ELisp manual. > >> On Linux, the proper way to get the canonical path >> for a file with the file descriptor $fd: > > expand-file-name doesn't aim at yielding the canonical file name in > that sense. This was tagged notabug in December 2018; I'm now also closing this bug report. Thanks, Stefan Kangas ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-21 2:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-12-01 20:04 bug#33564: Incorrect path canonicalisation Mattias Andrée 2018-12-01 20:27 ` Andreas Schwab 2018-12-01 20:35 ` Mattias Andrée 2018-12-01 20:55 ` Andreas Schwab 2018-12-01 21:14 ` Mattias Andrée 2018-12-02 6:27 ` Eli Zaretskii 2018-12-01 20:30 ` Eli Zaretskii 2019-08-21 2:26 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).