Jobs module reports jobs that don't seem to exist

[inklesspen]

Current Behavior

When my shell is in my home directory, the jobs module doesn't show (because it's below the threshold, I assume). When I am in any other directory, the jobs module shows ✦2. However, running the jobs command prints nothing; there are not actually any background jobs.

Expected Behavior

The jobs module should only list jobs when they exist.

Additional context/Screenshots

ecc on  master 
✦2 ❯ cd ~

~ 
❯ cd /tmp

/tmp 
✦2 ❯ cd /

/ 
✦2 ❯ cd ~

~ 
❯ cd code/

~/code 
✦2 ❯ jobs

~/code 
✦2 ❯ 

Environment

• Starship version: 0.37.0
• bash version: GNU bash, version 5.0.16(1)-release (x86_64-apple-darwin19.3.0)
  Copyright (C) 2019 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

• Operating system: Mac OS 10.15.3
• Terminal emulator: Apple_Terminal 433

Relevant Shell Configuration

export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting

Starship Configuration

[cmd_duration]
disabled = true

[chipbuster]

Well that's funny.

What are the outputs of jobs -p and jobs -p | wc -l? These are the commands that starship uses to determine the jobs count--if they look correct, then we have some sort of argparse error, and if they look wrong, we either have a bug in bash or we've misunderstood how those functions work.

[inklesspen]

~ 
❯ jobs -p

~ 
❯ jobs -p | wc -l
       0

~ 
❯ cd code/

~/code 
✦2 ❯ jobs -p

~/code 
✦2 ❯ jobs -p | wc -l
       0

~/code 
✦2 ❯ 

[inklesspen]

Turns out there is in fact two jobs running during the shell prompt generation, but which are not running afterward. I am trying to figure out where they came from; very probably it's something in my bashrc.

[inklesspen]

Yep, turns out it's user error. At some point in the distant past, I installed https://github.com/rupa/z and forgot about it. It's responsible for the jobs.

(BTW I figured this out by hacking the starship_precmd to output the jobs to a file, and then compared that to the functions defined in set.)

[chipbuster]

I didn't know that z did that. (I guess because I mostly use it on zsh).

Is there a way for you to fix this (e.g. changing order of function evaluation for PROMPT_COMMAND)? If so, we'd love to know in case someone else has this issue.

[inklesspen]

I have fixed this for myself by removing z from my bash_profile, since I never actually used that. I do not know if there's an alternative.

I would recommend a note in the docs for the jobs module about how this works with the shell precommand, and if you have weird behavior with the jobs module you can start debugging by investigating your shell configuration.

(It would have been helpful if there were a debugging option to actually print the jobs it detects, not just count them, but since you convert to the count inside the shell integration, that's probably not viable.)

[aDotInTheVoid]

I was also getting this with .iterm2_shell_integration.bash

[davidmathers]

I found this issue because I have the same problem. Having learned that z.sh is the culprit I experimented by editing my bashrc and moving the line that loads z.sh to below the line that loads starship. This fixed the issue for me.

[muendelezaji]

As with @aDotInTheVoid, I got the same issue with .iterm2_shell_integration.bash. There are two lines in the file that call sh -c "exit $s" which seem to be the cause, though not sure why starship thinks the shells are still running afterwards. I'm not familiar with either the bash integration nor starship internals to debug further, but hope that info helps.

A quick fix is simply to move the iTerm2 line to load after starship init bash, but it turns out that may break the cmd_duration module as per this warning in the starship config guide, so you might no longer get the last command execution time.

[matchai]

To provide some context as to how the jobs module works, it simply prints what is passed in as the --jobs flag to starship prompt.
The init script passes in the output of $(jobs -p | wc -l), as can be seen here: https://github.com/starship/starship/blob/master/src/init/starship.bash#L43

It would seem that if there are lingering effects to running .iterm2_shell_integration.bash, they would be seen outside of starship as well, when running jobs.

[muendelezaji]

In my case the output of jobs was not showing anything, and fg also returns fg: no current job. Perhaps it is checked at some point during the startup (when there might be a background job) but then the status is somehow not refreshed?

[ev-agelos]

Same problem using fasd (alternative to z) too

[andytom]

I think this will be fixed in the next release thanks to #1897.