System "wget"command

[Fairlight]

On Tue, May 15, 2007 at 06:34:13PM -0500, Mike Schwartz, the prominent pundit,
witicized:
> 
> 1> /dev/null 2>/dev/null
> 
>    The "&" did give me another thought, though.  I wonder if I add an "&" at
> the end of the command, if that would throw the process into "background"
> and eliminate the errors?  (I believe that "SYSTEM" already runs the
> commands in background, but I'll grasp at any straw that might fix this.)

No.  In that case, you're -guaranteed- untrappable output in the form of
job control:

> ls &
[1] 11364

You'll get the job number and its corresponding PID.  

>    The frustrating thing is that I have can run this dang thing 100 times
> and not see an error, then all of a sudden I get a splash.  It may be
> relative to the load on the processor at any given time, because the
> keypunchers said that they notice this happening more often "when the system
> is slow".  

Whatever it is (and I've given the matter some thought) would appear to
be either the command shell or filePro.  You're redirecting everything
possible with wget and within your command.  

There is no practical difference between "1> file 2> file" and "1>file 2>&1" 
whatsoever, btw.  It's a semantic difference in that instead of two
separate and distinct redirects, it dup()s the file descriptor from one to
the other and only one merged stream goes to the file over one fd; but the
net result for all practical intents and purposes is identical when you
don't need to know which stream something came from, and just need it to
all go somewhere.

By the way, your use of -O implies -t 1 according to my man page on wget.
Nothing harmful AFAIK, just redundant and thought I'd mention it.

>    If I can't come up with anything else, I think I'll try setting this up
> as a "USER" function, and test it that way.

It depends why it's doing it at all.  It's not wget doing it.  It'd have
no reason to reprint its command--and it shouldn't even -know- about the
redirection since that's soaked up by the shell before the fork and exec,
so if that's getting splashed as well, it's -definitely- not wget itself.
If it's the shell's doing, you stand just as much chance of it happening
with USER, as I believe they both use system(2), so no net change.  If it's
fP somehow, it -might- make a difference.

I wouldn't toss random solutions at it and pray they work.  I'd try to
isolate it with fP-Tech support, or here.

What's /bin/sh point to on the affected system?  I somehow think it's shell
related, not fP-related, or we'd see this a lot more.  I can't prove
it...but you can call it an educated guess.

I've thought about this on and off all day since you posted it, and it's
damned odd.  I don't have a solid answer--just things it can't be.  Don't
suppose it's related to the data in any way?  If it only happens 1:100 or
better, that usually indicates some data-derived bug massaging.

mark->
-- 
No matter what your problems, modern medicine can help!
http://members.iglou.com/fairlite/fixital/