Bash auto_resume

Recent versions of Bash have added functionality to the "auto_resume" variable. In older Bash versions, you could resume a stopped "vi" job (for instance) by typing "%vi". If you've never done this, try it now: vi some file, and hit CTRL-Z to suspend it. Type "%vi" and you'll be back editing your file.

The "auto_resume" variable lets you dispense with the "%". If you type "auto_resume=1", you can just type "vi" to resume the last job. That's not a great savings, but there is more. If you set "auto_resume=substring", you can them type any part of your job name to resume it.

For example, let's say you are running "vi /tmp/foo" and "vi /tmp/bar". If "auto_resume" is set to "substring", you can simply type "bar" to resume the second session or "foo" to resume the first. If you type "tmp", you'll resume whichever of those was started last.

When there are multiple jobs to choose from (if you just typed "vi"), the "substring" setting simply picks up the last job, With other settings, you'll get "ambiguous job spec".

Supposedly "auto_resume" can also take the value "exact". It's documented in the Bash man pages, and shows up in a "strings" of Bash right near "auto_resume":

saved redirects

According to the manual, this means you must type the precise job:

   If  set to the value exact, the string supplied must match the
   name of a stopped job exactly;

I'm unable to make that work on any version of Bash I have available. Strangely, I can't find anything on the Internet indicating anyone else has noticed the problem. Perhaps I'm missing something obvious or perhaps no one has ever tried using this. The latter wouldn't surprise me: "substring" is a reasonably attractive feature, but "exact" seems almost pointless. Its only value might be to help you prevent yourself from trying to re-run something you already have in background.. as I said, almost pointless.

There's also the matter that few people read new man pages at all. Unless a feature adds considerable value, a large number of Bash users may be completely unaware of it. I only noticed this accidentally while looking up something completely unrelated.

If you can make "exact" work, please post a comment here. Include your Bash version (bash --version) and anything else you think is relevant.

Got something to add? Send me email.

1 comment

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Thu Apr 20 10:29:38 2006: 1945   TonyLawrence

Another factor is probably the diminished need to have job control at all. In the bad old days when we were stuck with non-windowing serial terminal connections, switching between background tasks was a fairly common need. Then we got tools like FacetTerm and shortly after that everything was networked so we could open as many windows as we wanted. It's rare to need to background a job at all today, never mind need to switch between several.

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Much to the surprise of the builders of the first digital computers, programs written for them usually did not work. (Rodney Brooks)

This post tagged:

© Copyright 2019