reassign 794727 util-linux
retitle 794727 "mesg n" exits with error, even if the command is successful
thanks
In this report I'm being asked to change
/usr/share/base-files/dot.profile which is the default for
/root/.profile to accomodate for the "new" mesg behaviour.
The "new" behaviour, however, does not make any sense to me.
The usual Unix definition of "error" is: If the command is able
to do what I'm asking it to do, there is not an error. If the command
is unable to do what I'm asking it to do, there is an error.
In this case, a line saying "mesg n" should make mesg to disallow
write access to the terminal. If the command is successful in
disallowing write access to the terminal, or even if write access was
already disallowed (following the principle of idempotency), then the
exit code should be 0, because the command is able to do what I'm
asking it to do.
Please change the behaviour of mesg and/or forward this upstream.
The current behaviour makes little sense and it's contrary to
traditional Unix standards.
Thanks.
----- Forwarded message from Daniel Reichelt <deb...@nachtgeist.net> -----
Date: Thu, 06 Aug 2015 03:36:26 +0200
From: Daniel Reichelt <deb...@nachtgeist.net>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: Bug#794727: base-files needs to account for changed behaviour of mesg
in dot.profile
X-Mailer: reportbug 6.6.3
Package: base-files
Version: 9.2
Severity: normal
Tags: patch
In testing /usr/bin/mesg is provided by util-linux instead of sysvinit-utils.
Its changed behaviour with respect to exit codes needs to be accounted for in
/usr/share/base-files/dot.profile.
When displaying of messages is set to no and also when being set to no,
util-linux' mesg exits 0 but 1. Since "mesg n" is the last command being run
for root's login-shells, the first exit code the user "sees" is 1 - which is
plain wrong.
Another example is ssh'ing into a stretch machine with e.g. "bash -lex
somecommand" where "somecommand" will never be executed due to the error-exit
triggered by the "failed" invocation of mesg.
A possible workaround is to change "mesg n" to s.th. along the lines of
-------8<------------
(
mesg n
err=$?
[ $err -gt 1 ] && exit $err
:
)
-------8<------------
This way, mesg's exit 1 gets masked by the empty statement ":" which returns
zero.
If the mesg call fails with, say 127 becaus the binary is missing, exit 127
gets triggered which exits the sub-shell - and only the sub-shell, not the
login shell - and the empty statement ":" which would return zero gets skipped
and code 127 gets propagated to the login shell.
Daniel
[...]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
