Re: [Pan-users] Command line use; download of nzb files does not stop

[Duncan]

Graham Lawrence posted on Tue, 01 Nov 2011 14:57:31 -0700 as excerpted:

> In a bash script I use
> 
>  pan --no-gui -o /home/g/Films --nzb \"${nzb[1]}\" 2>/home/g/pan.debug
>  && if [ $? -ne 0 ]; then dem 1; exit 1; fi

Given the semicolons, I'm assuming that's all one line.  But it doesn't 
make sense to me.  Let's rewrite it as a normal multilined script.  (I'm 
adding a cd so (shorter) relative paths can be used, and double-spacing,
to keep pan wrapping a bit easier to manage.  Also, note the \ line 
continuation, for posting/wrapping reasons.):

cd /home/g

pan --no-gui -o Films --nzb \"${nzb[1]}\" 2>pan.debug \

        && if [ $? -ne 0 ]; then

                dem 1

                exit 1

        fi


First, you're using the && conditional, which only executes what follows 
if the previous command returned success, but then testing the exit code 
AGAIN! (the && tests it once!) in your if conditional, executing the 
"then" clause ONLY if it's NOT success!

The "then" clause should therefore never be reached because it's behind 
two contradictory conditionals testing the same thing!

I don't know whether you're trying to execute the then clause on success 
or failure, but the if/then is actually superfluous.  If the intent is to 
do it if pan returns success (0), try this (untested of course):

cd /home/g

pan --no-gui -o Films --nzb \"${nzb[1]}\" 2>pan.debug \

        && {

                dem 1

                exit 1

        }

Or strung together:

cd /home/g; pan --no-gui -o Films --nzb \"${nzb[1]}\" 2>pan.debug && {
        dem 1; exit 1; }

Change the && to || if the intent is to execute those two subcommands on 
failure (non-zero, normally an error code) instead of success.

Another way, using an explicit $? test:

pan --no-gui -o Films --nzb \"${nzb[1]}\" 2>pan.debug

[[ $? = 0 ]] && {

        dem 1

        exit 1

}

A third way, using if/then:

pan --no-gui -o Films --nzb \"${nzb[1]}\" 2>pan.debug

if [[ $? = 0 ]]; then

        dem 1

        exit 1

fi


Second, what on earth is this "dem" command?  I've never read of it 
AFAIK, both a local manpage search and a google don't seem to turn up 
anything, and it doesn't appear to be a bash builtin either.  You /do/ 
say "in a bash script", which could indicate you're only posting a 
snippet of the script and it's a function defined earlier in the script, 
or perhaps you have a local "dem" command/script that's invoked, but 
given the contradictory result conditionals, actually knowing what that 
command is intended to do is critical to understanding whether you want 
to execute it on success or failure.

Third, why are you escaping the quotes around ${nzb[1]} ?  That tells 
bash to treat them as literals, not quotes, which makes no sense at all 
in this context.  I can see quoting the variable in case the nzb filepath 
contains spaces, but escaping those quotes? ??

Fourth, _if_ that's the end of the script and not a script fragment, with 
more following, do you really need the explicit exit at all?  Since 
that's the end of the script, it simply exits anyway.  But of course if 
you're using this script in another, testing for the result of this one 
in the other, then the explicit exit 1 could be justified, and of course 
if this is a script fragment, with more of the script following, that 
exit 1 does cause an early exit, so the rest of the script isn't executed.

> to download through an nzb file
> 
> The download process will not terminate, instead it downloads duplicates
> of files already obtained, e.g. from ls
> 
> Gangs of New York (2002) PAL.part065_copy_2.rar

> Gangs of New York (2002) PAL.part066.rar

> Gangs of New York (2002) PAL.part066_copy_2.rar

> Gangs of New York (2002) PAL.part067.rar

> Gangs of New York (2002) PAL.part067_copy_2.rar

> The download is complete, when I delete the copies the files par2 and
> unrar normally, and the result is good.

If you're calling the above script segment in a loop, yes, that's what 
I'd expect to happen.  Pan downloads and terminates, but the early exit 
is never triggered due to the screwed up logic as explained above, so the 
loop is invoked again, calling pan again, and seeing existing files there 
it creates new ones with the _copy_2 bit inserted.  Then it does it 
again, creating *_copy_3*. Repeat...

Fix the result testing logic and I expect that problem to disappear.

> There should have been a file, pan.debug, to attach to this email. The
> file was created at the start of the download process, but was not to be
> found after I terminated Pan with Ctrl-c.  I have no explanation for its
> absence.

I can't say, given the provided information either.  But I might guess.  
Where were you executing the script from (what was the PWD)?  Note that 
the script as you posted it uses an absolute path for the debug file.  If 
you weren't in that dir and simply did an ls in the current working dir 
to find it, you may well have missed it.  One might think this is an 
elementary error to make, true, but by the same logic, those 
contradictory tests on the same thing are an elementary error to make as 
well, so it's worth double-checking.

Meanwhile, take a look at bash's set builtin for bash script debugging.  
It would seem that might be more useful to you at this point than pan 
debugging.  In particular, take a look at set -v and set -x ( +v and +x 
to revert to normal).  I resort to these quite often when debugging my 
own scripts, but be aware that they can be rather more verbose than you 
might expect (especially when turned on when executing thru shell 
functions, sourced files, etc, which one might forget about when 
initially turning them on), so be sure to only turn them on for bits of 
the script at once, then turn them off after you're passed the critical 
area.  You can always move the set statements around if you find you 
weren't tracing where the problem was.  I find that much easier than 
trying to human-parse pages and pages of output.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman