[OCF] ocf-shellfuncs standardization - Comments? Objections?

[Alan Robertson]

Nick Stoughton wrote:
> On Mon, 2005-08-15 at 21:13, Alan Robertson wrote:
>>Our code doesn't print it to standard output.  You don't want daemons 
>>printing to standard output - that's an error.  It may cause them to 
>>crash later on - when the pipe reading from its standard output is closed.
>>
>>Daemons should NEVER write to standard output.
>>
> I didn't say that *daemons* should write to standard output ... these
> are tools to use in a shell script.

In fact, they are startup scripts for daemons.  Admittedly not the 
daemons themselves.  But, sometimes the line isn't so clear as it seems...

 > Almost all utilities write to
> standard output. I remain convinced that the log_xxx_message functions
> should write to standard output. This means that you, as a writer of the
> shell init script, know that you can do normal redirection things with
> this function. For example
> 	log_success_message "All started OK" > /dev/null
> or
> 	logger $(log_failure_message "Failed to start service")
> 
> The script *starts* the daemon ... it isn't the daemon itself. Even if
> it was, it still helps programmers who will now know that they have to
> do something with this output (even if it is to discard it). Simply
> saying it "prints" it is so ambiguous and vague as to be useless.

The latter example you gave using logger is prohibited by the 
specification you wrote.  Our implementation would fail your criteria, 
AND, we would be unable to work with scripts written using your criteria.

For our case, we specifically need to define these commands to do 
something OTHER than write to standard output.

Let me explain this problem again a different way...

    Let me give an example from our IPaddr resource - which is similar in
	 most respects like an init script...

Our IPaddr script runs and brings up an IP address and then returns 
after forking off a background gratuitous ARP program - which will run 
for a few seconds, and then go away.  It's not exactly a daemon, since 
it only runs for about 5 seconds.

If the log_*_message implementations write to standard output, then the 
output will be lost and the process will die with a SIGPIPE - because 
the original child process has exited.  When that happens, typically 
parents close pipes going to their children to make their life easier.

If you are allowed to implement it by a logger call (which does NOT 
write to standard output), then it works perfectly - and nothing is lost.

So, my vote is to allow it to say "the output is directed somewhere such 
that it can be redirected to the console when desired".  This allows the 
implementor of the log_success_message maximum freedom and makes the 
purpose of the command also perfectly clear.

But, creating the expectation that the programmer is free to do this is 
I think wrong:

    j=0
    while
      [ $j -lt 10 ]
    do
      log_success_message "Try $j"
      j=`expr "$j" + 1`
    done | grep 9

Is I think giving the wrong message about what this is for, and as I 
mentioned above, creates problems for users and implementors, and ties 
implementors hands in terms of how they do their work and implement 
their system.

One can always say "you screwed up" or "don't do that", but given that 
it's perfectly avoidable, AND provides greater implementation 
flexibility, I have trouble seeing why one would make the choice which 
leads both to more errors and fewer implementation choices.

-- 
     Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me 
claim from you at all times your undisguised opinions." - William 
Wilberforce