[Tcl-bugs] [ tcl-Bugs-219161 ] Merging stdout and stderr

[SourceForge.net <no...@so...>]

Bugs item #219161, was opened at 10/25/00 22:02
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219161&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 27. Channel Types
Group: obsolete: 8.0.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: Merging stdout and stderr

Initial Comment:
OriginalBugID: 1470 RFE
Version: 8.0.4
SubmitDate: '1999-03-08'
LastModified: '2000-04-26'
Severity: SER
Status: Assigned
Submitter: pat
ChangedBy: hobbs
RelatedBugIDs: 682 582
OS: All
FixedDate: '2000-10-25'
FixedInVersion: NA
ClosedDate: '2000-10-25'


Name:  Alexandre FERRIEUX

DesiredBehavior:
It is well known that it's not trivial to merge the stdout and stderr of
a child on Windows. The Debated patch by Ian Taylor dragged the existing
>@ redirection semantics the wring way (i.e. patching WIndows to mimic
UNIX, while for once the UNIX behavior is wrong !!!). Suggestions have
been made to use "2>&1" instead, which at least doesn't violate the rest
of the >@ semantics. The problem with this is that it's a Bourne
shell-based notation, while the rest of [exec/open] uses a csh-notation.
In particular , ">&" already exists, which would make "2>&1" at least
ambiguous.
    
Hence, I suggest a syntax extension that is more in the spirit of the
existing notation, while protecting the semantics: ">&@outpipe".
Explanation: ">&@x" already exists, meaning "redirect both stdout and
err to the previously opened descriptor found at the low level of the
Tcl channel 'x'.
Notice that Ian Taylor's patch for Windows and the current (buggy)
semantics for Unix both propose to use "stdout" here as "x". Instead, I
propose to use a new string "outpipe", which would be recognized
internally as 'the output pipe being created'.


See 682 for longer explanation of odd behavior.  582 is the "incorrect"
patch that Ian Taylor proposed. 
-- 04/26/2000 hobbs

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 03/24/06 19:22

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 03/10/06 08:07

Message:
Logged In: YES 
user_id=80530


Didn't TIP 202 resolve this?

----------------------------------------------------------------------

Comment By: Craig A. Handler (craighandler)
Date: 10/15/02 10:11

Message:
Logged In: YES 
user_id=629134

Of course, the difference in behavior Unix v. Windows also 
occurs with [open "| foo 2>@stdout"].  For this case, at least, 
the problem could be resolved by supporting "|&" at the head 
of a new pipeline.  This is an already supported syntax in the 
middle of pipelines, just not at the head of one.  So, this 
should not be objectionable the way 2>&1 seems to be.

Of course, it does nothing to resolve the problem for [exec].


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 07/05/02 13:58

Message:
Logged In: YES 
user_id=80530

This appears to be more FR than Bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219161&group_id=10894