[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 is NOT what your proposal says.  Your proposal says it goes to 
standard output.  For a daemon, standard output should be directed to 
/dev/null.  So, that would be an acceptable result?

If you want to say "it causes it to go somewhere that it can be made 
visible when requested" then say that.

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

Saying it prints to standard output is neither helpful in testing it, 
nor does it add to anything.  But, it does nicely restrict 
implementations in how they might implement these functions - without 
any obvious benefit in return.

For example, our implementation doesn't send it to standard output.  It 
sends it to a logging daemon.  Something else arranges for it to go 
where it needs to go (like to the screen).

Why should it send to standard output specifically?

What you're saying is "This function is precisely identical and in every 
way indistinguishable from echo".  That doesn't sound too useful to me.


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