[vim/vim] Why does vim always resolve symbolic-link directory? (#4942)
agguser
Describe the bug
It seems that vim always resolve symbolic-link directory to physical directory!
To Reproduce
$ mkdir /tmp/d1
$ touch /tmp/d1/f1.txt
$ ln -s /tmp/d1 /tmp/d2
$ vim --clean -c 'set statusline=%F | set laststatus=2' /tmp/d2/f1.txt
Notice that the status line show "/tmp/d1/f1.txt".
Expected behavior
The status line should show "/tmp/d2/f1.txt".
Environment:
- Vim 8.1.1968
- OS: Arch Linux 5.2.14
- Terminal: xterm
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Christian Brabandt
Well, I for one appreciate it, that Vim does correctly resolve the file to be edited. In the end it is probably a matter of taste. I do not consider this a bug.
agguser
Well, I for one appreciate it, that Vim does correctly resolve the file to be edited. In the end it is probably a matter of taste. I do not consider this a bug.
If so, there should be a setting to disable this.
Christian Brabandt
I don't think this warrants another setting. I believe you can achieve this by a custom 'statusline' function.
agguser
This is not about formatting. If autochdir is set, current directory is /tmp/d1 instead of /tmp/d2.
Shane-XB-Qian
i noticed that too, feeling a little strange to me, i'd like to keep 'xx/d2/yy' if you opened 'd2' which not 'd1'.
sometime, that would be issue if vim auto resolve to 'd1' for a 'link' (#4832 maybe)
:)
097115
Well, I for one appreciate it, that Vim does correctly resolve the file to be edited. In the end it is probably a matter of taste. I do not consider this a bug.
The behaviour is not consistent, though -- if we continue with the original example:
md /tmp/d3
ln -s /tmp/d1/f1.txt /tmp/d3/
vim --clean +'set statusline=%F | set laststatus=2' /tmp/d3/f1.txt
And now notice that the status line shows "/tmp/d3/f1.txt".
Me, I'm actually with you here, Christian, I do like that the file is resolved :)
However, unfortunately, it seems that it's really not always the case. (Or, may be I'm missing something?)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
John Little
There are cases where the resolution of symbolic names causes problems.
I have to use a cloud file share service for work, and it insists on using a long path that has spaces and parentheses in it. If I use a symbolic name to make the path manageable vim resolves it, and that causes various problems interacting with scripts, as well as annoyingly long file names.
The service provider says, just map a drive letter, but that's a Windows feature. So, I use a bind mount to get a similar result, and vim doesn't know about it. The bind mount can confuse some utilities, like find, but using a "hidden" directory (a directory with a leading ".") in the real path minimizes this, and it works for me really well.
—
You are receiving this because you are subscribed to this thread.
Gary Johnson
> There are cases where the resolution of symbolic names causes problems.
I have a plugin that needs to search for parent directories and for
files in those parent directories. I used to use finddir() and
findfile() for this, but then discovered that they, too, resolve
symbolic links. This was no good when running the plugin in
a subdirectory of one of the /usr/src/linux-headers-* directories.
Many of those subdirectories are symbolic links to some other
/usr/src/linux-headers-* subdirectory, so my plugin would find the
wrong parent directory. I wound up writing my own FindDir() and
FindFile() that textually traverse $PWD/<relative path>.
Regards,
Gary
vim-dev ML
—
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> On 2021-09-19, John Little wrote:
> > There are cases where the resolution of symbolic names causes problems.
>
> Agreed.
>
> I have a plugin that needs to search for parent directories and for
> files in those parent directories. I used to use finddir() and
> findfile() for this, but then discovered that they, too, resolve
> symbolic links. This was no good when running the plugin in
> a subdirectory of one of the /usr/src/linux-headers-* directories.
> Many of those subdirectories are symbolic links to some other
> /usr/src/linux-headers-* subdirectory, so my plugin would find the
> wrong parent directory. I wound up writing my own FindDir() and
> FindFile() that textually traverse $PWD/<relative path>.
I would think that findfile() and finddir() could return the file or
directory as-is, but when editing a file, then the symbolic link resolve
would apply.
--
A fine is a tax for doing wrong. A tax is a fine for doing well.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Gary Johnson
>
> > On 2021-09-19, John Little wrote:
> > > There are cases where the resolution of symbolic names causes problems.
> >
> > Agreed.
> >
> > I have a plugin that needs to search for parent directories and for
> > files in those parent directories. I used to use finddir() and
> > findfile() for this, but then discovered that they, too, resolve
> > symbolic links. This was no good when running the plugin in
> > a subdirectory of one of the /usr/src/linux-headers-* directories.
> > Many of those subdirectories are symbolic links to some other
> > /usr/src/linux-headers-* subdirectory, so my plugin would find the
> > wrong parent directory. I wound up writing my own FindDir() and
> > FindFile() that textually traverse $PWD/<relative path>.
>
> Can you give a reproducible example of the problem you encountered?
enough to reproduce it. But now I can't. And I fixed the problem
before I put the plugin in version control, so I can't just revert
to that earlier version, although I can probably reconstruct it.
I'll take another stab at it tomorrow or Wednesday.
> I would think that findfile() and finddir() could return the file or
> directory as-is, but when editing a file, then the symbolic link resolve
> would apply.
the problem. I may have misinterpreted my findings at the time.
I'll let you know what I find.
Regards,
Gary
vim-dev ML
—
You are receiving this because you are subscribed to this thread.
Gary Johnson
> On 2021-09-20, Bram Moolenaar wrote:
> >
> > > On 2021-09-19, John Little wrote:
> > > > There are cases where the resolution of symbolic names causes problems.
> > >
> > > Agreed.
> > >
> > > I have a plugin that needs to search for parent directories and for
> > > files in those parent directories. I used to use finddir() and
> > > findfile() for this, but then discovered that they, too, resolve
> > > symbolic links. This was no good when running the plugin in
> > > a subdirectory of one of the /usr/src/linux-headers-* directories.
> > > Many of those subdirectories are symbolic links to some other
> > > /usr/src/linux-headers-* subdirectory, so my plugin would find the
> > > wrong parent directory. I wound up writing my own FindDir() and
> > > FindFile() that textually traverse $PWD/<relative path>.
> >
> > Can you give a reproducible example of the problem you encountered?
>
> When I found the problem, I made notes on it that I thought would be
> enough to reproduce it. But now I can't. And I fixed the problem
> before I put the plugin in version control, so I can't just revert
> to that earlier version, although I can probably reconstruct it.
>
> I'll take another stab at it tomorrow or Wednesday.
> > I would think that findfile() and finddir() could return the file or
> > directory as-is, but when editing a file, then the symbolic link resolve
> > would apply.
>
> That's what I'm seeing now, too, although it contradicts my notes on
> the problem. I may have misinterpreted my findings at the time.
>
> I'll let you know what I find.
commented-out pieces. I reproduced the problem, but the causes are
getcwd() and fnamemodify(file, ":p:h"), which happen before the
calls to findfile() and finddir(). Fixing those first calls fixes
the problem even when leaving the old calls to findfile() and
finddir().
So I was wrong in my initial analysis of the problem and in my
initial comments above. Thanks for setting me straight.
Regards,
Gary
pjlbyrne
I have just encountered this issue.
Every time I run a script it produces a new timstamped output directory. I make symbolic links from the latest built files back to the current directory. I want to be able to reopen these linked files in vim and for it to pick up the latest files through the symbolic link.
Instead the files are not opened via the link, and I get either the old files or nothing if the old files are gone.
I think we ought to be able to save the symlink paths to a vim session file to restore via the updated links.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
pjlbyrne
And whats more, the Netrw directory listing shows the link path in directory browse even though the path at the bottom shows the resolved name. I think they ought to be consistent!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Oleg Broytman
I want to add to the report.
vim ~/symlink-to-dir/file resolves the symlink and shows me ~/real-dir/file in the status line and in echo expand('%').
The conditions for the bug are (~/.vim/ and ~/.vimrc are absent or empty):
- the symlink must be a link to a directory; direct link to a file doesn't trigger the bug;
vim ~/symlink-to-fileshows~/symlink-to-file; - the bug is triggered only in shell command line;
vimwith:ed ~/symlink-to-dir/fileshows the symlink, not the resolved target; - the path must be absolute:
vim ~/symlink-to-dir/filetriggers the bug,vim ../symlink-to-dir/filedoesn't.
I reproduced the bug with different versions of vim on different Linux systems. I reproduced the bug with vim 7.4 on CentOS with absent ~/.vim/ and ~/.vimrc. I triggered the bug with vim 9.0 at Debian 12.4 with additional condition: :set laststatus=2 in ~/.vimrc; absent laststatus or other values (0 or 1) don't trigger the bug.
A script to reproduce the bug:
#! /bin/sh set -e cd "$HOME" trap 'set +e; rm -rf .vim .vimrc test-dir test-syml; mv .vim-backup .vim; mv .vimrc-backup .vimrc' EXIT HUP INT QUIT TERM mv .vim .vim-backup mv .vimrc .vimrc-backup rm -rf test-dir test-syml echo set laststatus=2 > .vimrc mkdir test-dir echo Test >test-dir/test-file ln -s test-dir test-syml vim -c "echo expand('%')" "$HOME"/test-syml/test-file
Expected output (both in the status line and from expand('%')) in vim: ~/test-syml/test-file; the actual output is ~/test-dir/test-file.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Michael Scheper
Just to add weight to the argument that vim ought to have an option not resolve symlinks:
I often set up directory structures more or less like this:
~
└─ projects
└─ foo-project
├─ repo -> ~/git/foo-project
├─ cloud -> ~/securely-backed-up/projects/foo-project
│ ├─ cfg # my dev configuration
│ └─ secrets # keys and stuff banished from the repo
└─ # logs and unimportant temporary files
But paths that get logged are often relative to the directory that I run the project in, which is typically ~/projects/foo-project/repo. I'd like it, when vim has been launched from that same directory, to be able to quickly view those paths, but when they're something like ../cloud/cfg/blah.conf, that doesn't work, because when vim launches it sets getcwd() to ~/git/foo-project instead. 😒
For a decade or two, I've just gritted my teeth and corrected the path manually, but today is one of those days when I've also done a websearch, to see whether there's finally an option to get vim to do what I want.
I hope there will be some day. I disagree with @chrisbra: I think such a setting is quite warranted. Part of the beauty of vim is how configurable it is, and this setting would make many users' lives easier.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Bruno Beltran
I want to also chip in that this makes it incredibly hard to write plugins that correctly determine what the "workspace root" should be for your LSP.
Similarly to @mscheper, I often find myself in directories that contain folders which are actually symbolic links. If I open a file in one of these folders, I want my LSP to know that I am still working on the same project! However, most tools for specifying what project is being worked on rely on looking for some kind of "workspace root" by traversing up the file tree from the file being analyzed...which breaks if vim resolves the symlink.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.