Re: "mesg n" exits with error, even if the command is successful

[Santiago Vila <sanvila@unex.es>]

[ Trimming Cc lines a little bit ].

On Tue, Aug 11, 2015 at 12:32:22PM +0200, Karel Zak wrote:
> I think Posix standard is pretty explicit:
> 
> EXIT STATUS
> The following exit values shall be returned:
>     0 Receiving messages is allowed.
>     1 Receiving messages is not allowed.
>     >1 An error occurred.
> 
> 
> but you're asking for 0 also when 'n' or 'y' operants are specified.
> For me it seems like complicated return code semantic...

It is not complicated, it is usual Unix behaviour: Most commands
return 0 on success and > 0 on error (often, they return a different
number > 0 according to the type of error).

If I say "mesg n", and the mesg command is actually able to disable
writes to the terminal, that should count as successful, because it
did what I asked it.

But it still exits with 1, which usually indicates error, and this
forces shell script writers to write extra code.

I would call *that* complicated, not the current behaviour.

> I think standard wants to keep the things simple and stupid without
> any extra exceptions (another exit codes when executed with operants).
> [...]

On the contrary, I think standard is simple but not because they tried
to make it simple, but just because they forgot to make it *sensible*,
apparently nobody thought that it is probably a lot more useful to
leave the 0 and 1 error codes only for the case where an argument is
not used.


I can understand that you guys want to follow the standard (after all,
if a program follows the standard, it is not a bug in the program by
definition), but to me this seems like a bug in the standard itself,
as explained.

Unfortunately, I'm just speaking as an end user here. If nothing I say
about this makes sense to you, ok, do nothing, but it would be
wonderdul if you, as the authors, would ask the standard to be
clarified or modified, as you are in a much better position to do so.

Thanks.