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

[Graham Lawrence]

Duncan, thank you for pointing out that && is a conditional test.  I
had understood && simply as "wait until previous instruction completes
before proceeding", because that is the question I sought to answer
when I first came across it via google; hence my seemingly
contradictory logic.  If pan fails I need to run dem (display error
messages), a function I've put in .bashrc.  Its essential feature is
that it throws up an xterm and blinks an appropriate error message at
me whenever a script running in background fails for some reason.

But there does seem to be an anomaly here.  Whatever follows the &&
can not take effect until pan exits.  That it happens to be a test
that must always fail is irrelevant.  That test cannot be tried until
the pan instruction has terminated.  And that does _not_ happen.  In
fact, after Ctrl-c-ing to terminate pan, when restarted (after reboot)
with just
pan &
it went right back to downloading those duplicates.

Apparently Task Manager is not removing completed items from the list
in command line mode,  So when it reaches the end of the list it just
returns to the beginning of it again.  The only way I was able to
completely shut it up was to select all the items in Task Manager and
delete them, when in gui mode.

As for pan.debug, when I could not find it in /home/g I ran
find /home -name pan.debug
which I believe searches every subdirectory under /home.  It returned
nothing.  Possibly I deleted it in some way.


On Wed, Nov 2, 2011 at 9:00 AM,  <address@hidden> wrote:
> Send Pan-users mailing list submissions to
>       address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.nongnu.org/mailman/listinfo/pan-users
> or, via email, send a message with subject or body 'help' to
>       address@hidden
>
> You can reach the person managing the list at
>       address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pan-users digest..."
>
>
> Today's Topics:
>
>   1. Command line use; download of nzb files does not stop
>      (Graham Lawrence)
>   2. Re: Command line use;     download of nzb files does not stop (Duncan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 1 Nov 2011 14:57:31 -0700
> From: Graham Lawrence <address@hidden>
> To: address@hidden
> Subject: [Pan-users] Command line use; download of nzb files does not
>        stop
> Message-ID:
>        <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
> 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.
>
> 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.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 1 Nov 2011 23:40:10 +0000 (UTC)
> From: Duncan <address@hidden>
> To: address@hidden
> Subject: Re: [Pan-users] Command line use;      download of nzb files does
>        not stop
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Pan-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/pan-users
>
>
> End of Pan-users Digest, Vol 106, Issue 1
> *****************************************
>