On Fri, Nov 4, 2011 at 9:00 AM, <pan-users-requ...@nongnu.org> wrote: > Send Pan-users mailing list submissions to > pan-users@nongnu.org > > 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 > pan-users-requ...@nongnu.org > > You can reach the person managing the list at > pan-users-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pan-users digest..." > > > Today's Topics: > > 1. Re: Command line use; download of nzb files does not stop (Duncan) > 2. Re: Command line use; download of nzb files does not stop > (Ron Johnson) > 3. Re: Command line use; download of nzb files does not stop (Duncan) > 4. Re: Command line use; download of nzb files does not stop > (Ron Johnson) > 5. Re: Command line use; download of nzb files does not stop (Duncan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Nov 2011 22:26:33 +0000 (UTC) > From: Duncan <1i5t5.dun...@cox.net> > To: pan-users@nongnu.org > Subject: Re: [Pan-users] Command line use; download of nzb files does > not stop > Message-ID: <pan.2011.11.03.22.26...@cox.net> > Content-Type: text/plain; charset=UTF-8 > > Graham Lawrence posted on Thu, 03 Nov 2011 08:17:44 -0700 as excerpted: > >> 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. > > [ Please don't top-post. There's a reason for pan's top-posting > warnings. ] > > OK, that clears up the intent of the script logic a /lot/! =:^) > > In terms of &&, note that bash's default behavior is to wait for a > command to terminate (and return a result) before continuing. However, > if a command forks and the fork actually does the work, with the original > process simply terminating (the behavior of many daemons unless run in > foreground mode, for instance), then when the originally invoked process > terminates, bash continues. That's one reason the sleep (N seconds) > command is often used, to wait after original termination some time, for > the forked process or the hardware state or whatever, to settle. > > If the converse is desired, do NOT wait for completion, there's the & > (single &) backgrounding directive. Much like redirection, this is > tacked on to the tail end of the shell command. However, the invoking > bash script instance still owns the backgrounded process, which will > still terminate if the invoking bash script terminates, thus the wait > builtin (which waits for all background processes to complete) as well as > the disown (disown child processes) builtin. > > So && doesn't add the wait for termination -- that's the default -- > instead, it's a conditional, only executing what follows if the previous > command succeeded (returned 0 exit status). > > Or more precisely, && is a logical "AND" (thus the use of the & symbol), > but since both sides of a logical AND must be true, if the left side is > false the outcome is already known and bash shortcuts things by not even > attempting execution of the right side, thus making it an effective exit- > conditional, only executing what's on the right if the left hand side > succeeds. =:^) > > As alluded to earlier, || serves the converse logical OR function, > actually XOR, which after shortcutting, effectively makes it an exit- > conditional testing for failure of the left-hand side, only executing > what's on the right if the left-hand side fails. > > So that part of your script can simply use... > > || { dem 1; exit 1 } > > ... to execute the compound command (the call to dem and the call to > exit) on failure. > > By the way, since you mentioned that dem is a function in your bashrc, > you can simplify the logic even further, if desired. > > 1) Add the call to exit to the dem function itself, presumably as the > last command executed in the function. > > 2) Instead of using a compound dem 1; exit 1 structure ever time you'd > invoke it, simply use: > > dem 1 > > Of course, if you're already passing "1" as a status code to dem, you're > probably already using it in the function, and can simply invoke exit > with the same variable ($1 positional or whatever other it's assigned to). > > With that modification to your dem function, the above compound on the > right-hand side of the || can be made a single command, as such > > || dem 1 > > Alternatively, if in your existing usage you sometimes call dem but do > NOT exit, then you can keep it as-is, and add a second function > "deme" (dem with exit), defined as such: > > deme () { dem $1; exit $1 } > > Then you can call dem as normal if you don't want to exit, or deme if you > do want to exit, passing the status codes as you are currently doing. > >> But there does seem to be an anomaly here. Whatever follows the && can >> not take effect until pan exits. > > True. As mentioned above, you could change that by using the & (single) > to invoke pan as a background process, but that wouldn't seem to be your > intent, either. > >> 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. > > What about without the & at all? It seems to me that it's redundant. > >> 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. > > If the script isn't looping, thus calling pan repeatedly, then you're > correct, the problem would seem to be in pan. But as I don't know what > the rest of the script looks like, I don't know if it's invoking pan > repeatedly, thus causing the dups, or if pan itself is causing the dups. > >> 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. > > Yes. That's still something of a mystery. I don't have an explanation > for that at all, at this point. The path thing was simply grasping at > straws, particularly as you'd used the absolute path in the redirect. > The only other thing I could think of would be some sort of permissions > related problem -- if for some reason the script was run as a different > user, perhaps SETUID or some such, without permissions to write to that > dir. But that seems quite unlikely indeed. > > Perhaps the partition on which you have /home/g is full? Equally > unlikely. Quota issue? If anything, even more unlikely. Depending on > your distro, maybe SELinux or similar security issue? Possible, > particularly as I don't run SELinux myself and thus am unfamiliar with > its restrictions, but that seems just as unlikely as the other > possibilities. > > So... I have no clue at all what's going on there. If it were happening > on my machine, I could probably figure it out, but the turn-around > latency for troubleshooting it via list thread is simply prohibitive; we > could easily still be working on it at this time next year! > > -- > 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 > > > > > ------------------------------ > > Message: 2 > Date: Thu, 03 Nov 2011 17:34:09 -0500 > From: Ron Johnson <ron.l.john...@cox.net> > To: pan-users@nongnu.org > Subject: Re: [Pan-users] Command line use; download of nzb files does > not stop > Message-ID: <4eb316e1.9070...@cox.net> > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > I've used "pan --no-gui --nzb ${FOO}.nzb -o ." on *many* occasions and > it always returns to the $ prompt when d/l is complete. Using v0.135. > > If you want something to run only if a process errors out, then use > "||". For example: > $ pan --no-gui --nzb ${FOO}.nzb -o . || dem > > Anyway... "Task Manager" (Real Men run top(1) in a separate window...) > just reports what the kernel tells it. > > On 11/03/2011 10:17 AM, Graham Lawrence wrote: >> 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. >> > > -- > Supporting World Peace Through Nuclear Pacification > > > > ------------------------------ > > Message: 3 > Date: Thu, 3 Nov 2011 22:47:49 +0000 (UTC) > From: Duncan <1i5t5.dun...@cox.net> > To: pan-users@nongnu.org > Subject: Re: [Pan-users] Command line use; download of nzb files does > not stop > Message-ID: <pan.2011.11.03.22.47...@cox.net> > Content-Type: text/plain; charset=UTF-8 > > Ron Johnson posted on Thu, 03 Nov 2011 17:34:09 -0500 as excerpted: > >> Anyway... "Task Manager" (Real Men run top(1) in a separate window...) >> just reports what the kernel tells it. > > I parsed his "task manager" reference as to pan's TM, not the one in his > DE, corresponding to top, etc. > > Meanwhile, if you're going to make the real-men/top assertion, why don't > you do it right, and say ps, with the appropriate options. If the task > manager isn't for real men, then surely, top isn't either, since it's > simply a semi-gui task manager. In context, ps/pgrep/etc are what "real > men" use. =:^) > > (Obviously, such "real men" would be sufficiently familiar with ps's/ > pgrep's options as to type them in off the top of their heads without > having to look them up in a manpage, too. No hand-wavy references to > "appropriate options"; they'd simply type in the options directly. So I > guess we all three fail the test in that regard. =:^( ) > > -- > 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 > > > > > ------------------------------ > > Message: 4 > Date: Thu, 03 Nov 2011 18:28:23 -0500 > From: Ron Johnson <ron.l.john...@cox.net> > To: pan-users@nongnu.org > Subject: Re: [Pan-users] Command line use; download of nzb files does > not stop > Message-ID: <4eb32397.9040...@cox.net> > Content-Type: text/plain; charset=us-ascii; format=flowed > > On 11/03/2011 05:47 PM, Duncan wrote: >> Ron Johnson posted on Thu, 03 Nov 2011 17:34:09 -0500 as excerpted: >> >>> Anyway... "Task Manager" (Real Men run top(1) in a separate window...) >>> just reports what the kernel tells it. >> >> I parsed his "task manager" reference as to pan's TM, not the one in his >> DE, corresponding to top, etc. >> > > Except that the pan TM doesn't appear when you run "pan --no-gui". > > -- > Supporting World Peace Through Nuclear Pacification > > > > ------------------------------ > > Message: 5 > Date: Fri, 4 Nov 2011 02:13:41 +0000 (UTC) > From: Duncan <1i5t5.dun...@cox.net> > To: pan-users@nongnu.org > Subject: Re: [Pan-users] Command line use; download of nzb files does > not stop > Message-ID: <pan.2011.11.04.02.13...@cox.net> > Content-Type: text/plain; charset=UTF-8 > > Ron Johnson posted on Thu, 03 Nov 2011 18:28:23 -0500 as excerpted: > >> On 11/03/2011 05:47 PM, Duncan wrote: >>> Ron Johnson posted on Thu, 03 Nov 2011 17:34:09 -0500 as excerpted: >>> >>>> Anyway... "Task Manager" (Real Men run top(1) in a separate window...) >>>> just reports what the kernel tells it. >>> >>> I parsed his "task manager" reference as to pan's TM, not the one in >>> his DE, corresponding to top, etc. >>> >>> >> Except that the pan TM doesn't appear when you run "pan --no-gui". > > Thus this bit (I /think/ it's the correct number of quote levels)? > >>>>> 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. > > =:^) > > Perhaps that's why I parsed it as referring to pan's task manager, tho I > obviously didn't take the time to analyze why, back then, the pieces > simply fit together better when I parsed TM as referring to pan's, than > otherwise. > > For more discussion of the alternate parsings effect, google "crash > blossoms". Here's an explanation of how the name came to be (and a very > amusing read it is), by Language Log's Ben Zimmer. (I came to know them > thru language log, which I believe I'm mentioned here before, after > originally stumbling upon LL while googling, IIRC, "toe the line" vs. > "tow the line", the former being "correct", tho I was sure it was the > latter, but that could well be its own subthread!) > > http://www.google.com/search?q=%22crash+blossoms%22 > > http://www.nytimes.com/2010/01/31/magazine/31FOB-onlanguage-t.html > > http://languagelog.com/ ( which redirects to > http://languagelog.ldc.upenn.edu/nll/ , take your pick) > > Then of course there's also eggcorns and Lady Mondegreens... Suffice it > to say that I have LL in my feed-reader now. Not only the articles > themselves, but the comments as well. > > -- > 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 > Pan-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/pan-users > > > End of Pan-users Digest, Vol 106, Issue 3 > ***************************************** >
> Anyway... "Task Manager" (Real Men run top(1) in a separate window...) > just reports what the kernel tells it. Ron, I seem to have misled you inadvertently. I was referring to deleting the task list in Pan's Task Manager. I had no trouble stopping Pan itself. The problem was that if I restarted it it went right back to downloading duplicates of files already downloaded. The only other Task Manager I was aware of is on windows, and in 12 years the only use I ever had for it was to kill unresponsive apps, and which I actually preferred to do with a little bat file using tasklist and taskkill. Similarly on linux; grepping my notes I find I have used kill $(pgrep thunar) and that would seem to be the extent of my need for a task manager. I started top (which I was also unaware of), but it seems to be just a real-time version of ps. What sort of things would one use it for, that you can't do through ps? And I think, above all a real man would be independent, and entirely unconcerned with "Real Men's" need for group solidarity and identification. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
