fix(detection/terminalshell): use absolute path to shell if available

[jnooree]

Sometimes shell executable name (exe; e.g., zsh) might resolve to a different path than path to the login shell (exePath; e.g., /bin/zsh). This PR tries to use absolute path to the login shell if possible, and fallback to previous behavior if absolute path is not available.

[CarterLi]

Do the same for terminals?

[CarterLi]

Do the same for terminals?

[jnooree]

Do the same for terminals?

Yes, if you could give me the code location, I can try fixing that too.

[CarterLi]

Well, you know the file you modified is called terminalshell.c

[jnooree]

Oh it's in the same file. Wait for me...

[jnooree]

e914504 fixes terminal.

[Copilot]

Pull request overview

This PR modifies the terminal and shell detection logic to prefer absolute paths (exePath) over executable names (exe) when available. The change ensures that the correct shell binary is used for version detection, avoiding cases where the executable name might resolve to a different location than the actual login shell.

Key Changes

• Refactored shell version detection functions to accept only the executable path parameter, removing the separate exePath parameter
• Added logic to select exePath over exe when exePath is available before calling version detection functions
• Applied consistent handling across both Windows and Linux platforms

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
terminalshell_windows.c	Selects exePath over exe when available before calling fftsGetTerminalVersion
terminalshell_linux.c	Selects exePath over exe when available before calling fftsGetTerminalVersion
terminalshell.c	Refactored getShellVersionBash and getShellVersionZsh to remove exePath parameter and added path selection logic in fftsGetShellVersion

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[filbo]

What was the bug that this issue & PR intended to fix? The stated rationale is:

Sometimes shell executable name (exe; e.g., zsh) might resolve to a different path than path to the login shell (exePath; e.g., /bin/zsh)

On Linux, at least, these are extracted from a running process's /proc/pid/exe, and will only resolve to different files if the original file has been removed or otherwise changed since the running shell-under-examination was started. The exe field will not be 'zsh' but rather '/bin/zsh'; and the exePath field will be identical or effectively identical, unless actual filesystem changes have happened since the process was started.

For example, on my desktop (Debian 'sid', different from the Termux I was reporting on in #2136):

$ fastfetch -l none -s shell --format json
[
  {
    "type": "Shell",
    "result": {
      "exe": "/bin/bash",
      "exeName": "bash",
      "exePath": "/usr/bin/bash",
      "pid": 2981054,
      "ppid": 2980847,
      "processName": "bash",
      "prettyName": "bash",
      "version": "5.3.3",
      "tty": 6
    }
  }
]

Here, indeed, exe and exePath are 'different'; but this is because /bin and /usr/bin are the same directory on this system. /bin/bash has come from my account's /etc/passwd entry; the kernel decodes the same exact file's full name as /usr/bin/bash in the process's /proc entry:

$ ls -l /proc/$$/exe
lrwxrwxrwx 1 filbo filbo 0 Jan  8 18:07 /proc/2981054/exe -> /usr/bin/bash

But these (/bin/bash and /usr/bin/bash) are precisely, identically, the same file. It does not matter which one is invoked to query bash --version.

I don't think this change (5d13389) can have fixed an actual behavior bug; and instead it introduced one, since it causes fastfetch to try to follow nonsense ' (deleted)' links in some real-world scenarios.

[filbo]

Actually, I think I may be misreading slightly what the change does. If it effectively changed it from running bash --version (with no path) to exePath --version -- that would fix some class of bugs where e.g. /bin/bash and $HOME/my/build/of/bash both exist and I was running the latter.

But the solution of decoding /proc/pid/exe's symlink target -- that does not work. Use what fastfetch has collected as '.exe' (not '.exePath').

[jnooree]

But the solution of decoding /proc/pid/exe's symlink target -- that does not work. Use what fastfetch has collected as '.exe' (not '.exePath').

Well no, for login sessions on most UNIX-like platforms .exe field is just the shell name.

Ubuntu:

$ ps
  PID TTY          TIME CMD
42947 pts/0    00:00:00 zsh
$ fastfetch -l none -s shell --format json
[
  {
    "type": "Shell",
    "result": {
      "exe": "zsh",
      "exeName": "zsh",
      "exePath": "/usr/bin/zsh",
      "pid": 42947,
      "ppid": 42946,
      "processName": "zsh",
      "prettyName": "zsh",
      "version": "5.8.1",
      "tty": 0
    }
  }
]

mac:

$ ps
  PID TTY           TIME CMD
 9802 ttys000    0:00.30 -zsh
$ fastfetch -l none -s shell --format json
[
  {
    "type": "Shell",
    "result": {
      "exe": "zsh",
      "exeName": "zsh",
      "exePath": "/opt/homebrew/bin/zsh",
      "pid": 9802,
      "ppid": 9801,
      "processName": "zsh",
      "prettyName": "zsh",
      "version": "5.9",
      "tty": 0
    }
  }
]

[jnooree]

I might instead argue that the user’s login shell should be detected from struct passwd (via getpwuid_r), not from /proc/pid/exe.