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, 2021 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, 2021 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, 2021 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, 2021 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, 2021 at 15:37

1 Answer 1


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .