Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I'm running a task on a computer network? I've just started to realize that if I qsub any task, then the task won't hog up my terminal, and I can do other things on the same terminal (which is quite useful even if the task only takes a single minute to finish).

And then I run qstat to see which taks have finished and which ones haven't.

http://pubs.opengroup.org/onlinepubs/009604599/utilities/qsub.html is a good explanation of qsub.

share|improve this question
Which batch system is supplying your qsub? (Several call their submission command by that name.) – dmckee Jan 28 '12 at 0:28
up vote 5 down vote accepted

In these cases I'd rather open another terminal. What is the reason that you don't want to do that?

Downside of running qsub, is that you have to write a tiny script file for a trivial operation, which takes you some time. I don't know how many other users are working on the same network, but the purpose is meant as a scheduler for jobs of several users on the cluster. Especially if there are no free cores available, your simple job will end up in the queue, taking you more time.

Did you consider screen as an alternative? With screen you can start and pause a different session in the same terminal. The workflow would be like this

  • working in the terminal
  • $ screen
  • your tiny jobs
  • Detach screen (Ctrl-a Ctrl-d)
  • working in the terminal
  • $ screen -r (to resume)
  • Check status of this tiny job
  • $ exit
  • And you're back
share|improve this answer

I don't see any advantage of using qsub over the standard at. The at command will take a "script" and execute it at a specific time (like "now"), using your current environment. Then you can check the status with atq or remove the job with atrm.

$ nohup ./myscript myargs & # put script in the background
# almost the same as
$ echo ./myscript myargs | at now # computer runs script independent of terminals

You do need to make sure that your myscript will not be looking for input.

Myself, I use screen in a single terminal session everywhere I go, as Bernhard suggests. Open a new window (within screen), start the script, switch back to original screen window.

share|improve this answer

I don't see any disadvantage to using qsub to background jobs that I typically would run interactively inside of screen. If you have a cluster available, then this is an optimal solution.

Although we have a job scheduler available, for a long time I tended to use screen to background long-running jobs or achieve parallelism without a lot of qsub script-writing overhead. Eventually, the limitations of this approach became apparent, and I wrote this qsub wrapper qgo to allow me to replace & and screen with qsub:


mkdir -p qsubscripts

qsub -w $(pwd)/qsubscripts -d $(pwd) -M user@addr.com $@ -S /bin/zsh -

Note that I'm using my preferred shell (zsh) but of course you can remove this argument, or add others. The use of $@ allows for the inclusion of resource specifications like -l ncpus=4 as needed. Here's how you'd use the script:

echo 'command -a 23 -b zz' | qgo | tee jobids

The STDERR.* and STDOUT.* files will be written to qsubscripts in the current working directory. The job ids are provided on The working directory for the job is set as thecwd` as well, which makes it easier to write these short scripts.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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