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@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? 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@xxxxxxxxxx> http://karelzak.blogspot.com -- 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
