Re: [PATCH] editor: use canonicalized absolute path
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 29, 2013, 10:03 UTC
- Message-ID
- <CACsJy8CQiESBsZvRB-Gs17Jg4Lvu-gJLUckV0njeTj+EwnTrig@mail.gmail.com>
- In-Reply-To
- <1375030782-13339-1-git-send-email-artagnon@gmail.com>
On Sun, Jul 28, 2013 at 11:59 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
Show 16 quoted lines
> By improving the relative_path() algorithm, e02ca72 (path.c: refactor > relative_path(), not only strip prefix, 2013-06-25) uncovered a latent > bug. While most editor applications like cat and vim handle > non-canonicalized relative paths fine, emacs does not. This is due to a > long-standing bug in emacs, where it refuses to resolve symlinks in the > supplied path: > > #!/bin/sh > mkdir z z/a z/b > echo moodle >z/a/file > ln -s z/b > cd b > emacs ../a/file # fail: opens /tmp/a/file > > Even if emacs were to be patched to fix this bug now, we still need to > support users running older versions.
We used to have workaround for external programs, e.g. 35ce862 (pager: Work around window resizing bug in 'less' - 2007-01-24), so I don't think this is a problem.
Show 6 quoted lines
> Co-authored-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> > Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> > --- > Urgent candidate for maint. I wrote to emacs-devel, but nobody seems > to be interested; the sources are horrendously unmaintainable, and > the project should die soon.
Hey, I don't want to throw away years of training my fingers to use emacs. It can't die until there is a viable fork :)
Show 12 quoted lines
> diff --git a/editor.c b/editor.c
> index 27bdecd..0abbd8d 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -37,7 +37,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
> return error("Terminal is dumb, but EDITOR unset");
>
> if (strcmp(editor, ":")) {
> - const char *args[] = { editor, path, NULL };
> + const char *args[] = { editor, real_path(path), NULL };
> struct child_process p;
> int ret, sig;real_path() returns a static buffer, which could be overwritten by the next real_path() call. I checked and I think that won't happen. So the patch looks good.
-- Duy