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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux