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@xxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
