stderr behaviour

[Grant McWilliams]

On Mon, Jul 14, 2008 at 2:12 AM, rehan khan <rehan.khan at dsl.pipex.com>
wrote:

>  Recently I came across what I thought was odd behaviour in Smart relating
> to the use of stderr. As I understand it stderr is used to output program
> error messages like exceptions and bugs usually to provide feedback for
> debugging. So the question is 'what is a program error in the context of
> Smart?'. For example 'smart check' outputs to stderr. Now although the
> output of this command is reporting errors it is not reporting an error with
> Smart itself but an error with the metadata (which is external and actually
> unrelated to smart). Should this not just be output to stdout? This would
> make scripting smart less of a hassle.
>
> The same issue occurs with the various --dump commands. From a users
> perspective the --dump commands tells them what might happen if they
> executed a certain command. Again this is to check the behaviour of the
> metadata not smart itself. although in this case the --dump commands can
> also be used to check the behaviour of the depsolver. So from a developer
> perspective outputting to stderr is right and from a users
> perspective outputting to stdout would be right (more expected than
> 'right'). I would guess that the --dump command originated from a debugging
> need but it is also quite useful for users so perhaps the output behaviour
> should change.
>
> Personally I would expect tracebacks and the output of --log-level=DEBUG to
> go to stderr and any 'user' commands to go to stdout. What does the list
> think about this normalisation of expected behaviour?
>
> It is quite useful for there to be a demarcation between 'user' and
> 'developer' features.  This is especially useful when it comes to
> documentation (the user manual and the developer manual) and user
> expectations. For an application of Smart's type I don't think every user
> should be expected to have development skills. Are there any other commands
> that fall into this grey area?
>
> These are open questions and feedback from the list would be really useful.
>
> Thanks
> Rehan
>


You are quite right. I have a couple thousand lines of scripts surrounding
smart and gave up on it giving me any reliable return codes or data from
the  appropriate stream. If you're scripting smart you either have to use
Python or just grep everything that comes out of smart. Definitely not very
clean. At some point I was going to start looking into just making sure
return codes were reliable but I and another developer on our project got
everything to work by hacking around it (deadlines... it's faster to do it
the wrong way) and never got back to it.

I believe that any program error or diagnostics should go to stderr and
return various return codes to let the script know the level of failure.
Trying to upgrade a package and not being able to retrieve it should give a
different rc than the package being corrupt or maybe even if it's already
installed. Maybe that last one isn't really an error but it would be nice to
tell from a script.

Imagine having a list of rpms that need to be installed and have rpm gather
a list of what's installed an passing the diffs to Smart. If any one package
can't pass the dependency check or fails to install all remaining packages
will also fail because smart exits. This wouldn't be as big a problem if
smart was better at telling the script what failed so then the script writer
could recreate the list without that package and send it back into smart.

Grant

-- 
Some people, when confronted with a problem, think "I know, I'll use
Windows."
Now they have two problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080714/cd273051/attachment-0003.htm>