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

[Alan Robertson]

Nick Stoughton wrote:
> I need to start making some progress on this ... I've waited a month!
> 
> On Thu, 2005-07-07 at 22:51, Alan Robertson wrote:
>>Nick Stoughton wrote:
>>>>Nick:  If you would consider withdrawing or modifying your bugzilla to 
>>>>the LSB until we finalize our own discussion, that would be much 
>>>>appreciated.
>>>It turns out that my bugzilla comment was a dup of an earlier one, and
>>>has been closed as a duplicate. However, the timeline has this as a
>>>defect to be fixed in release 3.1 (to be published late September 2005
>>>if all goes according to schedule).
>>>...
>>It worked for fprintf :-)
> Well, how exactly??? fprintf says "The fprintf() function shall place
> output on the named output stream." And defines how streams work. All
> I'm doing here is the same thing.
> 
>>But, more seriously...
>>
>>_Which_ are you trying to test?  The base LSB capabilities?  An LSB init 
>>script?  A vendor's overall init process?  Are you trying to test them 
>>in an boot environment?  Standalone?  Are you going allow adding things 
>>to the messages printed?  Or do they have to be printed exactly as they 
>>are (the message, the whole message, and nothing but the message)?
>>
> If there was a test (there isn't one today), it would be of the init
> functions. My proposal said that the format of the message was
> unspecified...so no, they don't have to be printed in any given form.
> Anything could be added to or taken away from the message (for example,
> it might be translated into a foreign language).
> 
>>The point of the API is that they are redirected to a place where they 
>>are visible (if requested) during the boot sequence.
>>
> Exactly. That is precisely what my proposal said. The message is sent to
> stdout in an unspecified format. This can be redirected, etc as required
> by the init script, or by the infrastructure that calls init scripts.
> 
>>That's the requirement - which is driven by the intended purpose.  If 
>>you left out "(if requested)" for example, then the implementation would 
>>have no option for a less-scary boot sequence like basically all Linux 
>>vendors do now.  Similar things happen if you add much beyond what the 
>>purpose requires.
>>
> I don't quite follow this ...
> 
> 
> Just for clarity, here is exactly what I'm proposing the LSB does:
> 
> Change "The log_xxx_msg function shall cause the system to print a xxx
> message." to "The log_xxx_msg function shall cause the system to print a
> xxx message to the standard output. The format of this message is
> unspecified."

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.


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