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
$ alias vim
$ 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:        alias vi=__vi_internal_vim_alias
./profile.d/vim.sh:        alias vim=__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 
$ rpm -qf ./profile.d/vi.sh 
  • Zsh very rarely changes defaults. Are you sure that both are recent changes? I've sometimes observed that zsh seems to “forget” the command line of a job, but it hasn't happened to me often enough to track it down. Feb 6 at 13:43
  • @Gilles'SO-stopbeingevil' Yes, I am. Of course, it could also be caused by a change in the kernel or a library. Although I can't reproduce it with bash. Regarding reproducibility, the weird new behavior is stable - cf. my question update for a sample session. Feb 6 at 14:29
  • For information I can't reproduce this with zsh 5.8 on Ubuntu. Does it matter which programs are involved? (I wonder if it could be this version/configuration of vim doing something “weird” that confuses zsh.) Feb 6 at 14:35
  • @Gilles'SO-stopbeingevil' ok, it really only happens with vim! Where vim is really a weird system-wide alias! See my latest update for details. That means with \vim job-control works as before ... Feb 6 at 15:09
  • @Gilles'SO-stopbeingevil' the latest Fedora vim update now installs small wrapper shell scripts under /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 make vim work. I mean what's the big deal if vim fails when you don't have it installed? Do you have an idea what could be behind this? Feb 6 at 15:37

It's caused by Fedora started defining system-wide vim aliases that start vim in a sub-shell.

Since this seems to break stuff left and right those aliases are now being rolled back: https://bugzilla.redhat.com/show_bug.cgi?id=1918575

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.