Read the FAQ first

• I have checked the FAQ but the issue is not covered

Description

Termux on Android. I happened to capture fastfetch output before and after apt-get dist-upgrade in which both bash and fastfetch were updated. Before, output displayed 'Shell: bash 5.3.8'; after, only 'Shell: bash'.

I force-reinstalled the previous versions (5.3.8 and 2.56.0, regressing from 5.3.9 and 2.56.1) -- and it was not fixed!

Then ran the following, which seems to show the problem:

$ fastfetch -s shell --format json
[
  {
    "type": "Shell",
    "result": {
      "exe": "/data/data/com.termux/files/usr/bin/bash",
      "exeName": "bash",
      "exePath": "/data/data/com.termux/files/usr/bin/bash.dpkg-tmp (deleted)",
      "pid": 19552,
      "ppid": 29706,
      "processName": "bash",
      "prettyName": "bash",
      "version": "",
      "tty": 1
    }
  }
]

The shell I'm invoking from is still running an old bash binary, now in fact replaced twice (and will be a 3rd time when I re-update to current).

I haven't checked the fastfetch source, but from this JSON output I suspect it is trying to run "/data/data/com.termux/files/usr/bin/bash.dpkg-tmp (deleted)" --version, with the predictable result 'ENOENT'. Even if it successfully edits the pseudo-symlink down to /data/data/com.termux/files/usr/bin/bash.dpkg-tmp and tries to run that, it will still fail, as no file exists at that path. It is merely a temporary artifact of the dpkg installation procedure; apparently dpkg renames a to-be-overwritten file out of the way before writing the new and deleting the old. The kernel, as exposed in /proc, remembers the last name the old file had before being removed. (and, of course, a fully intact version of that old file continues to exist, as witnessed by being able to run the /proc/%d/exe -- it necessarily must continue to exist until all open references to it, including processes which have it open as their running image, are closed.)

If I instead run /proc/19552/exe --version, I get output indicating bash '5.3.8(1)-release'.

So: either run the old binary using the direct /proc/%d/exe path; or use what the JSON is showing here as result.exe rather than result.exePath. (This will have a different effect in the corner case where the user has actually deleted the shell they're currently running, but I'm not sure that's a use case which requires perfect handling; anyway, current behavior suggests that would just cause it to output the old-now-deleted shell name with no version number -- a perfectly safe and sane degradation...)

=====

NOTE: I have not in fact checked the FAQ, primarily because even though this form uses the word 'FAQ' 3x in asking me to do so, none of those is a link in either live-clickable or just simply copy-pastable form! Secondarily because this report contains actionable information on the cause, whereas if the FAQ does mention this issue it will necessarily be presented as some sort of unsolvable mystery or 'that's the way it is', which wouldn't be helpful.

Version used

2.56.1

Bug prevalence

Other

Regression

Not sure

Installation

Package manager

Package manager

Termux apt-get -> apt -> pkg

Screenshots

No response

Configuration

System information

Not relevant

Features built-in

Not relevant