18

fg, bg and jobs are used for job management. And for some reason (maybe it's just me), I'm not able to find where their binaries are nor their manpages (whereis prints no information). which gives no output. The commands themselves work just fine, though.

I ran commands like find /bin bg, but with no hits. I also ran find / bg to cast a wide net.

3
  • manpage fg: unix.com/man-page/posix/1posix/fg and bg: unix.com/man-page/posix/1p/bg Where users below answers have "bash" it is probably more correct to call these mandatory POSIX shell commands. If those are not present you can not call the system used POSIX compliant.
    – Rinzwind
    Apr 24 '15 at 17:50
  • @Rinzwind Do you know/have a suspicion why I don't have their manpages in my shell, though? :) Apr 24 '15 at 17:54
  • 1
    You already know: these are shell builins. So their man page is bash. Do a man bash | grep fg ;) (see steeldrivers' answer)
    – Rinzwind
    Apr 24 '15 at 18:04
36

You are not getting any files against those commands because they are shell (bash) built-ins, not separate executable files (e.g. binary files, scripts). Actually, shell built-ins are compiled into the shell executable; if you want you can check the source code to be sure of it. As which or whereis only looks for external executable files, you are not getting any output for the built-ins.

To find if a command is a built-in or alias or function or external file, the best way is to use the type built-in:

$ type fg
fg is a shell builtin

$ type bg
bg is a shell builtin

$ type jobs
jobs is a shell builtin

Also note that your find command is not syntactically correct. The correct (simplest) syntax is find /where/to/search -name 'name_to_search'.

Also note that few commands are implemented as both a shell built-in and a separate standalone executable. For such commands, always remember that the built-in command will take precedence over the external one. So, when you run echo something, the built-in echo is run. If you want to run the binary executable echo you need to call it in a different way. One way is to use the full path to the executable: /bin/echo something.

To display all available versions of a command, run type with the -a option:

$ type -a echo
echo is a shell builtin
echo is /bin/echo

To get documentation for shell built-ins, you can check the manpage of bash or use the help command (which is a built-in command):

help jobs

Also as @terdon pointed out you should use type instead of which.

6
  • I had heard about this 'builtin' business before, but I guess I didn't consider it much since whereis echo and which echo gives normal output, and type echo says that echo is builtin. Do you know the reason for that? Apr 24 '15 at 17:52
  • 5
    @user136104 in the case of echo, it's available both as a shell built-in and a separate standalone executable (with different capabilities and options - see Why is printf better than echo? Apr 24 '15 at 18:09
  • @user136104: Check my edits..
    – heemayl
    Apr 24 '15 at 18:14
  • 4
    @user136104 The reason why something like echo or kill can exist as both commands and builtins and most of the other builtins aren't is because they cannot function without being part of the shell. What exactly would an external bg do? It doesn't know what process to continue, and it can't control its interaction with the terminal.
    – Random832
    Apr 24 '15 at 19:58
  • 1
    @user136104 for more (far, far, more) on the differences between type and which, see Why not use "which"? What to use then?. The short summary is: always use type.
    – terdon
    Apr 25 '15 at 13:08
6

They are shell built-ins - you can get basic usage information by typing help fg or help jobs at the bash shell prompt, or more detailed information from the bash manpage.

5

Adding to heemayl's answer, it's worth pointing out that fg, bg, and jobs have to be built into the shell, because they manipulate data structures in the shell's memory and/or the kernel state associated with the shell's process. It would not be possible to write an external command that does what fg does.

Other commands that have to be built in include cd, eval, exec, exit, export, history, read, set, source (aka .), shift, trap, ulimit, umask, and wait. Your shell may have a longer list, depending on how much extended functionality it implements. POSIX has a different, but overlapping, list of "special built-in utilities" -- I'm not sure why things like break and continue count as commands rather than control-structure keywords, or why POSIX doesn't consider things like umask must-build-in when they can't be implemented any other way. (You could write a program called /bin/umask that called umask(2), but it would only change the setting for itself, not for subsequent processes created by the shell, so it wouldn't fulfill its specification.)

2
  • I think you're mostly right, @zwol, especially if the command needs to manipulate the shell's state. If it is manipulating the systemwide kernel state, however, I think any executable with suitable permissions ought to be able to do that. This is probably why sysctl is not a built-in, for example. Apr 24 '15 at 21:21
  • @RandallCook I didn't say system-wide kernel state, I said the kernel state associated with the shell's process, such as the umask and the resource limits. (I believe current Unixes do let you alter the resource limits for another process, given sufficient privilege, but that didn't used to be possible.)
    – zwol
    Apr 25 '15 at 2:06
2

This are shell builtin commands. There is no binary for them as they are a part of Bash (or whatever shell you are using).

They are documented for example in the Bash manpage (see the section "SHELL BUILTIN COMMANDS")

2

fg, bg and jobs are not separate utilities, but they are part of bash(shell builtin commands).

you can find more about them in bash manual using the command

man bash
1
  • 1
    You may want to make it clear that by "bash manual" you mean running the command man bash.
    – IQAndreas
    Apr 25 '15 at 8:27

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