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

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

[Santiago Vila]

Hello.

[ Apologies if this is a FAQ ].

Debian has recently switched the "mesg" implementation from
the one in sysvinit to the one in util-linux.

We have found a subtle issue: The old mesg didn't have any error codes
at all. The new mesg (from util-linux) has the following error codes:

            0     Messages are allowed.

            1     Messages are not allowed.

           >1     An error has occurred.

The problem is that those error codes are in effect not only when
the mesg command is invoked alone:

mesg

but also when it's used with an argument:

mesg y
mesg n

This breaks the default /root/.profile which has a simple "mesg n" at
the end, so we will probably have to hide the error like this:

mesg n || true

but this is a little bit weird and I wonder how much people will have
to do this as well.

In Unix, usually, whenever I tell a command to do something, there is
only an error when the command is not able to do what I ask it to do.

In this case, however, the "mesg n" is succesful, as it is actually
able to disable write to the terminal, and yet it exits with an error.

I think this does not make much sense and would humbly propose that
the behaviour is changed so that error codes are only used when
the mesg is used alone, without any arguments.

Surely that a change like this might in theory break some scripts,
but let's see what kind of breakage we could expect:

* People who write this:

mesg y

will not need to change anything.

* People who write this:

mesg n || true

will finally be able to remove the "|| true" part. If they don't
remove the "|| true" part, nothing really bad will happen.

In fact, this could even improve things a little bit, as "mesg" alone
will fail if the mesg does not exist.

* People writing things like this:

if mesg 2> /dev/null; then
  echo mesg is y
else
  echo mesg is n
fi

which is where exit codes are actually useful, will not be affected at
all.

Of course one can always create a complex use case where a change in
exit codes would break the script, but I think those would be a very
small minority.

So: Would you please consider a change in mesg behaviour regarding
exit codes, so that "mesg n" does not gratuitously fail?

Thanks.

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

[Reuti]

Hi,

Am 09.08.2015 um 17:04 schrieb Santiago Vila:

> Hello.
> 
> [ Apologies if this is a FAQ ].
> 
> Debian has recently switched the "mesg" implementation from
> the one in sysvinit to the one in util-linux.
> 
> We have found a subtle issue: The old mesg didn't have any error codes
> at all. The new mesg (from util-linux) has the following error codes:
> 
>            0     Messages are allowed.
> 
>            1     Messages are not allowed.
> 
>> 1     An error has occurred.
> The problem is that those error codes are in effect not only when
> the mesg command is invoked alone:
> 
> mesg
> 
> but also when it's used with an argument:
> 
> mesg y
> mesg n
> 
> This breaks the default /root/.profile which has a simple "mesg n" at

The profile is usually sourced. How does the error show up at the login prompt on Debian?

-- Reuti


> the end, so we will probably have to hide the error like this:
> 
> mesg n || true
> 
> but this is a little bit weird and I wonder how much people will have
> to do this as well.
> 
> In Unix, usually, whenever I tell a command to do something, there is
> only an error when the command is not able to do what I ask it to do.
> 
> In this case, however, the "mesg n" is succesful, as it is actually
> able to disable write to the terminal, and yet it exits with an error.
> 
> I think this does not make much sense and would humbly propose that
> the behaviour is changed so that error codes are only used when
> the mesg is used alone, without any arguments.
> 
> Surely that a change like this might in theory break some scripts,
> but let's see what kind of breakage we could expect:
> 
> * People who write this:
> 
> mesg y
> 
> will not need to change anything.
> 
> * People who write this:
> 
> mesg n || true
> 
> will finally be able to remove the "|| true" part. If they don't
> remove the "|| true" part, nothing really bad will happen.
> 
> In fact, this could even improve things a little bit, as "mesg" alone
> will fail if the mesg does not exist.
> 
> * People writing things like this:
> 
> if mesg 2> /dev/null; then
>  echo mesg is y
> else
>  echo mesg is n
> fi
> 
> which is where exit codes are actually useful, will not be affected at
> all.
> 
> Of course one can always create a complex use case where a change in
> exit codes would break the script, but I think those would be a very
> small minority.
> 
> So: Would you please consider a change in mesg behaviour regarding
> exit codes, so that "mesg n" does not gratuitously fail?
> 
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Santiago Vila]

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

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

[Sami Kerola]

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.
IMHO the reasonable thing to do is to leave the return codes as they
are to avoid breakage in existing usage. If someone needs messaging
setting not to report exit codes then this functionality is safest to
introduce with new option, such as --no-exit-code-status

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

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

[Santiago Vila]

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?

Moreover: Would not be possible to ask for the standard to be clarified?

> IMHO the reasonable thing to do is to leave the return codes as they
> are to avoid breakage in existing usage. If someone needs messaging
> setting not to report exit codes [...]

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.

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

[Reuti]

Am 09.08.2015 um 21:11 schrieb Santiago Vila:

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

Two things I noted:

- on my Mac with 10.6/10.10 it's implemented in the same way it is in linux-util right now - how is it implemented in AIX or FreeBSD?

- the initial issue on the Debian list not being able to do `ssh <hostname> bash -lex test.sh` does not show up for me or I got it in the wrong way (from Mac to Linux openSUSE), the script is executed despite there being a ~/.profile with the `mesg n` command. But it shows an other error which I output in a called script:

===== test.sh =====
echo $?
echo Hello
===== end =====

...
+ mesg n
mesg: ttyname failed: Invalid argument
+ echo 2
+ echo Hello



So, I have to use:

if tty >/dev/null; then mesg n; fi

in ~/.profile to avoid this error.

-- Reuti

PS:  The same behavior one can find in `biff`with a similar function - there is a difference: as `biff` is asynchron, there may be a delay. Hence checking $? may still show the former state and the state has to be checked again in this case.



> Moreover: Would not be possible to ask for the standard to be clarified?
> 
>> IMHO the reasonable thing to do is to leave the return codes as they
>> are to avoid breakage in existing usage. If someone needs messaging
>> setting not to report exit codes [...]
> 
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Karel Zak]

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

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

[Santiago Vila]

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