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

[Karel Zak <kzak@redhat.com>]

On Sun, Aug 09, 2015 at 09:11:19PM +0200, Santiago Vila wrote:
> On Sun, Aug 09, 2015 at 06:58:15PM +0100, Sami Kerola wrote:
> > On 9 August 2015 at 18:19, Santiago Vila <sanvila@unex.es> wrote:
> > > On Sun, Aug 09, 2015 at 07:14:30PM +0200, Reuti wrote:
> > >> The profile is usually sourced. How does the error show up at the login prompt on Debian?
> > >
> > > The problem only happens in Debian testing and unstable, which I am not using yet.
> > > This is the original report which I received against base-files:
> > >
> > > https://bugs.debian.org/794727
> > 
> > Please notice the mesg(1) exit behavior is defined in POSIX
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mesg.html
> > 
> > Unfortunately the standard does not appear to be explicit whether the
> > exit value should be set only when requesting write permissions
> > (running without arguments), or if also when setting the permissions.
> 
> So if the standard is not explicit about this, there is some room for
> interpretation. Would not be possible to interpret the standard in a
> sensible way?

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

> Hmm, but who does really need message *setting* to report exit codes?
> They make more harm than help.
> 
> As explained before, if I do "mesg y" I can reasonably think that
> messages will be enabled after that, and if I do "mesg n" I can
> reasonably think that messages will be disabled after that.
> 
> I don't need an exit code for that, unless I don't trust the program
> to do its job, and this is why I think there is no need to interpret
> the standard so strictly.

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

BTW, you can use "mesg $SOMETHING_FROM_USER" and then return code
maybe an elegant way how to interpret user's input without parsing
$SOMETHING_FROM_USER.  (The current mesg implementation supporst
rpmatch().)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com