I'll volunteer to help...

[Robert Uhl]

Bill Wohler <wohler at newt.com> writes:
>
> > > I've lodged a bug report about suppressing any output with this
> > > command, as well as suppressing gratuitous stderr output--the
> > > redirection of stdout and stderr to /dev/null shouldn't be
> > > necessary here.  The funny thing is I just browsed my bugs at
> > > bugzilla and didn't see this, and I see it still isn't fixed in
> > > 1.8.4.
> >
> > Possibly because it's not really a bug?  Run interactively (as I
> > just ran it), it's useful to know which stocks are being looked up
> > where
> 
> If you're doing this interactively, chances are you're already in
> gnucash and can hit the Get Quotes button faster than you can type the
> command above.

Not when gnucash takes as long to start as it does...

To tell the truth, I'd prefer more output--maybe even a little report.

> > of course error output is never gratuitous.
> 
> Except when output that really should be sent to stdout is sent to
> stderr as is the case here.

Ah, then I agree.  That's one of the nastier things around.

> > Run from cron, it's simple enough to send stdout & stderr to
> > /dev/null
> 
> Of course, but this is only a workaround.  Most commands that you run
> from cron shouldn't have any output at all so that you don't have to
> add the redirection in your crontab.

I'm a Unix sysadmin--most of the commands I end up putting in my
crontabs do produce output, for various reasons.  I normally send stdout
to /dev/null and let stderr go so cron can trap it and email me if
there's a problem.

-- 
Robert Uhl <ruhl at 4dv.net>
Merely having an open mind is nothing; the object of opening the mind,
as of opening the mouth, is to shut it again on something solid.
                                              --G.K. Chesterton