I often find myself in the situation where I need to find a code base for a given symbol like so:

find src/galio -not -path './src/stapi-sdk/apilib/* -regextype posix-extended -iregex '.*(\.hpp|\.hxx|\.cpp|\.cxx|\.h|\.c|\.ma?k|\.sh|makefile)' | xargs egrep --colour=always -Hn 'NUM_EXTERITY_FLAGS' | less -R

The find/grep combination can take quite a while and I'd like to put the whole chain into the background (using Ctrl-Z and bg) and check back later to look at the result.

However, the whole job is immediately "Stopped" again after putting it into the background with bg. Is there a way around this?


  • 1
    You may want to take a look at a terminal multiplexer like tmux or screen.
    – FloHimself
    Mar 27, 2015 at 14:44

2 Answers 2


I'd recommend screen for this kind of situation. (Or run the command in a different window if that's feasible for you.)

To start a detached session, just enter screen. Then type your command but without the & to background it. Use Ctrla then d to detach the running session. Use screen -ls to list existing sessions and screen -r to reattach.

  • Hmm, isn't there another way? Why is less going straight to the stopped state? I'm too lazy to start a new screen session just for the one command. :D Mar 27, 2015 at 14:49
  • Write the output to /tmp/somefile (instead of piping it to less). Use less /tmp/somefile to check back every so often. Use job control notifications to discover that the job has finished. Mar 27, 2015 at 14:56
  • Yes, that'd be one option, thanks. But again, out of pure laziness / convenience, I'd rather end up not having lots of spurious files lying around. (I typically do dozens of searches like this in a day and I'm looking to run different search simultanenously). Mar 27, 2015 at 14:58
  • Create a (trivial) script to parameterise your searches. Use a known directory to store the searches, e.g. /tmp/mysearches. Add a find /tmp/mysearches -type f -mtime +2 -delete 2>/dev/null in the script to keep it reasonably tidy. Mar 27, 2015 at 14:59

The Two problems with less slowing your search are pipe wait and opening standard out/error for reading. In normal operation less will read enough to fill a screen and stop reading until you advance to the next page. This works fine unless you are reading from a pipe and the program writing to the pipe notices the pipe id full and sleeps until the pipe is read and is really slow about writing enough to fill the next page. The two easiest ways to change this behavior by less is to search for something that is not there or to calculate the size of standard input. Both will read the full file in. The next problem is that to control less it needs to receive commands from the keyboard, so it opens standard out or standard error for reading. This is odd but works just fine (with a few safeguards that less takes care of), but now less has a file handle open for reading pointing to the controlling tty (which you want when controlling less) that the shell's job control notices when you put things into the background and when less tries to read a key the shell puts it to sleep. You may be able to get around this by searching for the end of file in less before putting it in the background.

You must log in to answer this question.

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