+++ This bug was initially created as a clone of Bug #805254 +++ --- Additional comment from mschmidt on 2012-03-21 09:53:19 EDT --- Good to know. To summarize the problem: 1) /etc/X11/prefdm executes /usr/sbin/gdm 2) /usr/sbin/gdm is a shell script running in POSIX mode (it has #!/bin/sh) 3) /usr/sbin/gdm sources /etc/profile 4) /etc/profile sources /etc/profile.d/rvm.sh 5) rvm.sh depends on non-POSIX bash functionality, so a syntax error is hit. The whole thing quits with error code 2. I see at least 2 issues that made this problem needlessly difficult to debug: - /etc/X11/prefdm executes the display manager with ">/dev/null 2>&1", thus hiding the error messages. - /etc/profile sources the files /etc/profile.d/*.sh with: . "$i" >/dev/null 2>&1 again hiding the error messages.
This is not really true, it hides errors only for the case of noninteractive login. For interactive logins the errors are shown. This is necessary for e.g. ssh logins (these could be quite wordy without these redirections). If you have some idea for improvement, feel free to propose an adjustment. Otherwise I will have to close this not a bug, as this redirection is required.
(In reply to comment #1) > This is necessary for e.g. ssh logins (these could be quite wordy without > these redirections). I fail to see the problem. Could you give me an example of what a wordy login is?
I'll try to find the original bugzilla number with the request for disabling info from profile.d scripts for noninteractive logins.
bug 457243 and bug 202468 look related.
Yep, these are both the similar cases for tcsh... reasoning with less will be the same even in bash, but I can't find the related bash (/etc/profile) bugzilla. I probably did that together with tcsh fix by http://git.fedorahosted.org/git/?p=setup.git;a=commitdiff;h=722b1261607fb28328c708d45a39e8786139aa70 as the #202468 caused a regression #464788 and it was necessary to fix it somehow. Reverting them doesn't seem to be a good idea, but probably it should be possible to see debug output even for noninteractive mode via some envvar or something.
(In reply to comment #5) > Yep, these are both the similar cases for tcsh... reasoning with less will be > the same even in bash, but I can't find the related bash (/etc/profile) > bugzilla. I have doubts whether bash was ever affected by the less problem (bug 202468). When bash is running as non-login and non-interactive, to run a shell script (such as when spawned from popen(3): "/bin/sh -c command"), it does not run /etc/profile. This is different from tcsh, because tcsh runs /etc/csh.cshrc even if run as "tcsh -c command". Furthermore, even if we suppose there is some good reason for suppressing stdout, it does not follow that stderr ought to be suppressed as well.
Fair enough... suppressing stdout only seems to be a compromise. I'll change it in next rawhide build. Given the fact that it was suppressed in Fedora more than 3 years without complains and the main benefit here is debugging of the failures I think that waiting for possible future setup bugfix with rawhide only update should be ok. Are you ok with closing RAWHIDE after rawhide fix (no F16/F17 update ?) ?
Fine with me. Thank you.
Built as setup-2.8.51-1.fc18, closing RAWHIDE.