Bug 56291

Summary: up2date STDERR redirection w/ BASH broken. Sorta.
Product: [Retired] Red Hat Linux Reporter: Ali-Reza Anghaie <ali>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: medium    
Version: 7.2CC: shishz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-03-07 00:03:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ali-Reza Anghaie 2001-11-15 03:54:27 UTC
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?

Comment 1 Ali-Reza Anghaie 2001-11-15 03:56:49 UTC
BTW, that is not "jeremy" its supposed to be "katzj" ..
just in case you're wondering.

Comment 2 Bernhard Rosenkraenzer 2001-11-15 13:48:35 UTC
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


Comment 3 Ali-Reza Anghaie 2001-11-15 14:23:14 UTC
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.

Comment 4 Adrian Likins 2001-12-10 19:13:28 UTC
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.

Comment 5 Ali-Reza Anghaie 2001-12-10 23:01:12 UTC
/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!

Comment 6 Adrian Likins 2002-03-07 00:03:13 UTC
This behaviours is supposed to get fixed with the next release
of the userhelper utility.

Comment 7 Adrian Likins 2002-03-27 00:06:19 UTC
Versions of usermode 1.5 or higher should fix this issue, so
I'm closing this bug with resolution RAWHIDE.