Specifically, do function calls in a bash script run in the background if called with &?

I was trying to come up with a solution to Change a bunch of owners on files and thought something like the following might work. But will the user_searcher() function call actually run in the background?

  1 #!/bin/bash
  3 User1=1000
  4 User2=1001
  5 User3=1002
  7 user_searcher()
  8 {
  9         for fil in `find $HOME -uid $ooser -type f`
 10         do
 11                 chown "NEWUSER$1" $fil
 12         done
 13 }
 16 let i=1
 17 for ooser in $User1 $User2 $User3 ;
 18 do
 19         let i++
 20         user_searcher ooser i &
 21         PIDARRAY+=("$!")
 22 done    
 24 wait ${PIDARRAY[@]}
  • 3
    It will, although find … -exec chown "NEWUSER$1" {} + seems preferable here (or \; if your find doesn't support + for whatever reason) – Fox Jul 15 '17 at 3:06
  • 1
    Seems like it would be very easy to test this yourself. Just sayin'... – B Layer Jul 15 '17 at 3:23
  • That's true, and I did. I was just hoping for a bit of explanation. – flerb Jul 15 '17 at 3:25
  • 4
    The bash man page says "a function is an object that is called like a simple command" and, later, " If a command is terminated by ... operator &, the shell executes the command in the background in a subshell" – B Layer Jul 15 '17 at 4:17

man bash (See JOB CONTROL)

& is a control operator, meaning it performs a control function.

If a command is terminated by the control operator &, the shell executes the command in the background in a sub‐shell.

(A subshell is assigned a PID-Process ID Number)

In short, anything that is a command can be told to run in the background by terminating the command with &, which spawns a subshell process to run the command in.

Loosely, if it can be run stand-alone in a shell then it can be run in the background in a subshell (what & does). If it's a complete instruction for the subshell that its run in or sequence of complete instructions (function) then it can be run in the background...maybe I'll be corrected here but it's tempting to say that if it can be run in the foreground in a shell then it can be run in the background in a subshell, with varying and customizable scope for its variables (contrast coproc vs &, and see lastpipe, but scope of variables is a result of commands running in subshells, not because the commands are running in the background).

What constitutes a command?

From Wooledge Bash Guide:

BASH reads commands from its input (which is usually either a terminal or a file). Each line of input that it reads is treated as a command — an instruction to be carried out. (There are a few advanced cases, such as commands that span multiple lines, that will be gotten to later.) Bash divides each line into words that are demarcated by a whitespace character (spaces and tabs). The first word of the line is the name of the command to be executed. All the remaining words become arguments to that command (options, filenames, etc.).

From aosa-bash-full.pdf in bash-doc-3.2 from Bash Source:

A “simple” shell command...consists of a command name, such as echo or cd, and a list of zero or more arguments and redirections. (pg 47)

Shell functions and shell scripts are both ways to name a group of commands and execute the group, just like executing any other command. Shell functions are declared using a special syntax and stored and executed in the same shell’s context; shell scripts are created by putting commands into a file and executing a new instance of the shell to interpret them. Shell functions share most of the execution context with the shell that calls them, but shell scripts, since they are interpreted by a new shell invocation, share only what is passed between processes in the environment. (pg 48)


Bash introduces the concept of a job which is essentially a command being executed by one or more processes. A pipeline, for instance, uses one process for each element of the pipeline. The process group is a way to join separate processes together into a single job. The terminal has a process group ID associated with it, so the foreground process group is the one whose process group ID is the same as the terminal’s. (pg 69)

  • Any process can be run in the background
  • a shell itself is a process
  • any instruction/command (still loosely defined) within a shell can be run in the background by running it in the subshell that & spawns.

The biggest consideration is how the background subshell process interacts with its parent process, again, see Job Control in man bash

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.