From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 Description of problem: Ok. In BASH, I was trying to redirect up2date output. I tried various things including the old stand-by: up2date -l 2>&1 | mail -s "Test" root Or piping it to tee, etc. I tried variations like: up2date -l 2> >(mail -s "Test" root) and other such novelties. Now, I was getting frustrated because it wasn't working. I tried different terminals (don't ask me why). The I dropped to CSH, "up2date -l |& mail -s "Test" root" and all was well. It worked fine. So I tell mharris & jeremy, among others in #redhat about this. And some try it and it works, some it fails for. Versions were the same, terminals, etc. Nothing really different... Then I vaguely remembered something about SSH changing terminal behavior. Sure enough, if I SSH into the system, within BASH, it works as expected. The other people had the same behavior. Overall, for anyone who did it local, it behaved exactly as described. And when SSH was used, it worked, again for everyone. So it was reproduced by a handful of people in #redhat on OPN. I'll paste real snippets below. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.In BASH, just try it with 2>&1 or variations piped. It'll do the redirect but the other end of the pipe or redirect will be NULL. 2.In CSH it'll be ok. 3.Command is "up2date -l" .. Actual Results: [root@xxx root]# up2date -l 2>&1 | mail -s "Test" root Null message body; hope that's ok [root@xxx root]# up2date -l 2> >(mail -s "Test" root) [root@xxx root]# Null message body; hope that's ok [root@xxx root]# csh [root@xxx ~]# up2date -l |& mail -s "Test" root [root@xxx ~]# NOTE: And yes, after the CSH one, I get the mail. Like noted about, TEE and anything else I could think of, shoving it back into a cat or something didn't work in BASH until I SSHed into the same box or any other box: [root@xxx root]# up2date -l 2>&1 |mail -s "test" ali [root@xxx root]# NOTE: And post SSH, still BASH of course, it works. To me, this is bizarre. You might know right off the bat whats going on. I haven't disassembled the components yet but I will tommorow after work hopefully. This is rather bizarre and I'm pretty sure I've seen this before. Expected Results: STDERR should gone w/ STDOUT like any other time. Additional info: So, in summary, since I'm tired and I really hope this submittion isn't too incoherent: - Locally, regardless of terminal, and regardless of program being piped too. Under BASH, the STDERR redirect doesn't work properly. - If I SSH in and do it, it's fine. - Under CSH it is a-ok either way. Make sense? I'll set it "Low" since I have a workaround. Oh yeah, BTW, I did wrapper this in Perl to grab the STDERR and such, print lines individually, etc. Same behavior. Odd, huh?
BTW, that is not "jeremy" its supposed to be "katzj" .. just in case you're wondering.
I guess up2date (or python) uses fdup() or the likes on stderr, and writes the error messages there, so redirecting just fd 2 isn't sufficient. Bash does redirect fd 2 correctly in all test cases I've tried
Hmm. Ok, well I guess I have some learning to do. I'm completely lost as to what you're talking about. If you meant up2date or python created "3" I had already tried: [root@xxx root]# up2date -l 3>&1 1>&2 2>&3 | mail -s "Test" root Null message body; hope that's ok As well. And why would SSH handle it ok though? Like you, any other redirect I tried (and I tried tons) worked fine. Thanks, and I already found a reference on fdup() so I'll be learning shortly.
can you check to see if your running it out of /usr/sbin or /usr/bin? /usr/bin/up2date is a symlink to a console helper, which is an app that execs up2date again, and might be causing the problem.
/usr/bin ... and you're right, using /usr/sbin the behavior doesn't happen. BUT, the PATH is the same whether I come in w/ SSH or not so I'm still a little bewildered as to that additional functionality or what-not. { sigh... } ~I~ would say it's still a bug of sorts. Or at least should be a side-not in the MAN page. Thanks much!
This behaviours is supposed to get fixed with the next release of the userhelper utility.
Versions of usermode 1.5 or higher should fix this issue, so I'm closing this bug with resolution RAWHIDE.