On Mon, Jul 14, 2008 at 2:12 AM, rehan khan <<a href="mailto:rehan.khan@dsl.pipex.com">rehan.khan@dsl.pipex.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>

<div><font size="2" color="#000000" face="Arial">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.</font></div>

<div><font size="2" face="Arial"></font> </div>

<div><font size="2" face="Arial">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.</font></div>

<div><font size="2" face="Arial"></font> </div>

<div><font size="2" face="Arial">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?</font></div>

<div><font size="2" face="Arial"></font> </div>

<div><font size="2" face="Arial">It is quite useful for there to be a demarcation between 'user' and 'developer' features. <font size="2" face="Arial"> This is especially useful when it comes to documentation (the user manual and the developer manual) and user expectations. </font>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?</font></div>

<div><font size="2" face="Arial"></font> </div>

<div><font size="2" face="Arial">These are open questions and feedback from the list would be really useful.</font></div>

<div><font size="2" face="Arial"></font> </div>

<div><font size="2" face="Arial">Thanks</font></div>

<div><font size="2" face="Arial">Rehan</font></div></div>

</blockquote></div><br><br>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.<br clear="all">

<br>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.<br>

<br>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. <br>

Grant --  Some people, when confronted with a problem, think "I know, I'll use Windows."  Now they have two problems.