bash-lsp / bash-language-server

A language server for Bash

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

man pages cannot be found for symlinked commands

saucyfox opened this issue · comments

Code editor

neovim and helix

Platform

Arch Linux

Version

5.0.0

What steps will reproduce the bug?

Some programs will present separate command line interfaces to users based on which name they're executed with, and a common way to do that is through symlinks. For example, sox provides:

$ ls -l $(which sox)
-rwxr-xr-x 1 root root 76016 Feb  6 15:20 /usr/bin/sox

...for audio manipulation, spectrogram generation, etc., and:

$ ls -l $(which soxi)
lrwxrwxrwx 1 root root 3 Feb  6 15:20 /usr/bin/soxi -> sox

...for metadata inquiry.

Separate manual pages exist for these commands, and they're functionally different programs from the user's perspective.

In this case, bash-language-server is able to return the manual for sox but not soxi. I've tested this in both neovim and helix.

Many LVM commands are also just symlinks (e.g. vgcreate), so you can also reproduce the issue with one of those if you already have LVM installed on your system.

How often does it reproduce? Is there a required condition?

If a command in the user's path is actually a symlink, the language server will return no result 100% of the time even if a manual exists for it.

What is the expected behavior?

In this case, a request from the editor for documentation on the term soxi should return the contents of soxi(1)

What do you see instead?

No results are returned.

Additional information

I've had issues trying to get meaningful debug output with an editor and this language server, but I think the calls to fs.lstat() in this file are to blame. Is there a reason to check file attributes on the link itself instead of the target inode, or could fs.stat() be used instead?