Until recently I was pretty satisfied with how the fg
and jobs
command worked in my zsh, i.e.:
- just
fg
-> foreground the most recently backgrounded job again jobs
-> display command name (incl. args) and perhaps even PID (don't recall)
After the latest Fedora 33 updates these zsh behaviors changed in a (for me) pretty annoying way:
fg
now foregrounds the job with the lowest job id (i.e. not the most recently backgrounded job)- 'jobs' output is much less verbose, e.g.:
[3] + suspended (signal) mutt
[4] - suspended
where job 4
is a vim session ...
So I presume that some zsh defaults changed. Thus my question: How do I configure the more useful behaviors for fg
and jobs
back?
(That means how do I get jobs
to always display command names with arguments and pid and fg
to foreground the most recently backgrounded job?)
(I'm currently at zsh-5.8-3.fc33.x86_64.)
Edit 1: A sample session:
$ zsh
~ $ man man
zsh: suspended man man
~ $ vim blah
zsh: suspended
~ $ jobs
[1] - suspended man man
[2] + suspended
~ $ fg
[2] - continued
zsh: suspended
zsh: suspended
~ $ jobs
[1] + suspended man man
[2] - suspended
Note that I suspended the foreground jobs via CtrlZ each time. Look for the +
marker in the jobs
output. What also surprises me is that I get 2 zsh: suspended
lines after suspending vim for the second time. Looks like the suspend signal is delivered to the already suspended man process, again?
Edit 2: The job-control issue only appears if one job is vim
. Thus, some details on how vim is invoked:
$ which vim
vim=__vi_internal_vim_alias
$ alias vim
vim=__vi_internal_vim_alias
$ typeset -f __vi_internal_vim_alias
__vi_internal_vim_alias () {
(
test -f /usr/bin/vim && exec /usr/bin/vim "$@"
test -f /usr/bin/vi && exec /usr/bin/vi "$@"
)
}
Ok, these definitions don't come from my profile. It appears they come from a system change. If I invoke vim
as \vim
the job control issues don't appear anymore. Looks like the sub-shell messes with zsh's command line string creation and other things. See also other related reports.
So where does this come from:
$ cd /etc
$ grep -r __vi_internal_vim_alias . -r 2>/dev/null
./profile.d/vim.sh:__vi_internal_vim_alias()
./profile.d/vim.sh: alias vi=__vi_internal_vim_alias
./profile.d/vim.sh: alias vim=__vi_internal_vim_alias
./profile.d/vi.sh:__vi_internal_vim_alias()
./profile.d/vi.sh: alias vi=__vi_internal_vim_alias
./profile.d/vi.sh: alias vim=__vi_internal_vim_alias
$ rpm -qf ./profile.d/vim.sh
vim-enhanced-8.2.2146-2.fc33.x86_64
$ rpm -qf ./profile.d/vi.sh
vim-minimal-8.2.2146-2.fc33.x86_64
vim
is really a weird system-wide alias! See my latest update for details. That means with\vim
job-control works as before .../usr/bin/vim
and/usr/bin/vi
which test for/usr/libexec/vim
and fallback to/usr/libexec/vi
. I really don't understand the motivation behind all this effort trying to alias and wrap to always makevim
work. I mean what's the big deal ifvim
fails when you don't have it installed? Do you have an idea what could be behind this?