bash script problem

[Henry Yen]

The reason for Ari's suggestion is that it isn't entirely clear
if there are two ampersands after each command or just one.

My guess also is that there are two, which means that each command is
executed as long as the previous command completed successfully.
(If there were but one ampersand, that would cause the command to
run in the background, and control returned immediately to the
script as soon as the command starts.)

In either case, however, your script is not what you intend,
since you are using the "-b" option of wget. This option tells
wget to run in the background, and so, of course, each of the
wget commands in your script will appear to complete instantly.

I saw no option in wget to specify a command (e.g. md5sum) to
run after the wget completes. Therefore, to run a command after
wget completes, either you'd need to separately monitor the output
of wget's log, and watch for completion there (not so easy),
or don't run wget in the background in the first place.

To accomplish what we think you want to do (run the wget's in parallel
without your having to wait for any of them), try doing the
backgrounding setup yourself. For example, you could have a script
which has:

   nohup bash -c 'wget http://example.com/Downloads/v.iso ; md5sum v.iso' &

This says to run a subshell that will execute a "wget" command (running in
the foreground) followed by a "md5sum" command, but to turn off hangup signals
for that subshell (similar to the "-b" switch in wget), and then to
run that whole kit and kaboodle in the background. All output will
be appended to a file called "nohup.out", although you can redirect
it elsewhere.

Modern bash shells have some ability to directly control background jobs
with some flexibility, but when you have more than one, it begins to
get tricky. The above example is a low-common-demoninator method.

On Sat, Jun 22, 2013 at 13:04:07PM -0400, Jude DaShiele wrote:
> Adding the backslash characters provided no change in operation of the 
> script.
> 
> On Sat, 22 Jun 2013, Ari Moisio wrote:
> > Jus a wild guess but  should  there be a  backslash  at the end of each line
> > after the && or leave the && off.