Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why not simply use & #5

igregson opened this issue Jan 21, 2015 · 3 comments

why not simply use & #5

igregson opened this issue Jan 21, 2015 · 3 comments


Copy link

@igregson igregson commented Jan 21, 2015


First off, thanks for the helpful article on using npm's package.json as a build tool. I'm trying to get off large-footprint tools for some projects and this is a sweet little approach.

When considering the use of parallelshell, however, I'm not sure what the benefit of it is over simply using &, between command which also executes them in parallel.

Having tested both approaches, each seem to work. Simply using & seems a bit faster, too.

Copy link

@jedrichards jedrichards commented Jan 21, 2015

Also would like to say ty for your work talking about using npm as a build too, its helped me a lot.

I agree, using & in place of parallelshell seems to work in the few cases where I've tried it, but maybe I'm missing something.

Note that I think you may also sometimes need the wait command to stop any long-running parallel processes properly with ctrl-c or whatever, otherwise they'll still be running in a detached state in the current shell when the parent command exits.

So say you wanted to run your dev server and watch local files for changes in order to rebuild, you might have something like,

npm run devserver & npm run watch & wait

From wait docs:

wait [jobspec or pid ...]

Wait until the child process specified by each process ID pid or job specification jobspec exits and return the exit status of the last command waited for. If a job spec is given, all processes in the job are waited for. If no arguments are given, all currently active child processes are waited for, and the return status is zero. If neither jobspec nor pid specifies an active child process of the shell, the return status is 127.

Copy link

@keithamus keithamus commented Jan 21, 2015

& is pretty sweet, and I'd absolutely recommend you use it for a certain number of cases. However, & offers specific semantics over what parallelshell does.

For starters, & creates a job from a process, and puts it in the background. This means that the process is no longer attached to your shell env, and when you leave the shell env the task will continue to run. Take for example the following npm script:

"scripts": {
    "foo": "sleep 100 & echo foo"

Now if I run this:

$ npm run foo

> foo@1.0.0 foo /<snip>
> sleep 100 & echo foo


The sleep process outlives the npm script!

$ ps -ef | grep sleep
  501 29701     1   0  3:55pm ttys002    0:00.00 sleep 100

Also the problem with this, is that background jobs' exit codes are ignored, meaning if it fails you wont know about it. As @jedrichards suggested I could use wait which will hang until sleep 100 finishes, and propagate the exit code. However this has a couple of problems:

  • As far as I know, wait isn't available on windows.
  • Pressing ctrl-c will terminate wait, but does not terminate any jobs (meaning they're still running in the background)

So for a task where you just want to build things in parallel and just wait for the exit codes, and don't care about windows support - use & and wait.

If you have a project where you need Windows, or a task where you need to run processes which wont quit until you quit them, then parallelshell is the right tool for this job.

Copy link

@igregson igregson commented Jan 22, 2015


Thanks for the clarity @keithamus. And thanks for pointing out the wait command @jedrichards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants