[Tcl-bugs] [ tcl-Bugs-2849797 ] channel name inconsistencies

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

Bugs item #2849797, was opened at 2009-09-03 10:00
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2849797&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: 25. Channel System
Group: development: 8.6b1.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Donal K. Fellows (dkf)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: channel name inconsistencies

Initial Comment:
Consider this trace...

% close stderr; open /dev/tty w
file2
% file channels
stdin stdout stderr
% fconfigure stderr -buffering none
% puts stderr BOO
BOO
% puts file2 BOO2
BOO2

Now the issues... [open] is returning a name that isn't listed by [file channels], and [puts] (and any other channel command) is working with both the 'standard' name (file2) and the 'magic' name (stderr). Let channels only ever have a single name, and let lookups always only work with that name. And when working with FDs 0, 1 or 2, let the name be the 'magic' one because that's what scripts expect (irrespective of what the [open] command - or any other channel creator - expects).

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

>Comment By: Donal K. Fellows (dkf)
Date: 2009-09-08 10:03

Message:
And I've no evidence of anyone relying on preservation of the 'file2'
pattern for the stdchan case.

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

Comment By: Donal K. Fellows (dkf)
Date: 2009-09-08 10:01

Message:
3 breaks existing code.

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2009-09-07 21:23

Message:
Yes, but it is the way people have been doing (unix-specific) std*
redirections in Tcl since the beginning... So, reforming it the way you
suggest is guaranteed to break scripts (eg Larry's on tclcore).

Clearly I have sympathy with any consistent move at this point, and both
extremes are consistent. The sad part is that both have potential losses of
compatibility... Now let's weigh them:

 (1) Business As Usual: do nothing, close this item as Won't Fix
 (2) force-to-std* (Donal): possible breakage of contorted scripts eg
depending on channel name prefix to recognize type
 (3) never-go-back-to-std* (Jan): clean, and isomorphic with Windows, but
guaranteed to break scripts that do hackish unix redirections.

IMHO (2) is a quick win which is 99.9% safe, while (3) is 90% safe, but
the 10% can be fixed by a new [chan dup2/rename] or similar explicit,
Tcl-channel-level redirection primitive.

Opinions ?

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

Comment By: Jan Nijtmans (nijtmans)
Date: 2009-09-07 15:51

Message:
Thinking more about it, letting FDs 0, 1 and 2 be magic, is the wrong
solution. In the given example, I expect the "puts stderr BOO" give
an error, because stderr is closed! When someone closes stderr, any
writing to it should give an error, just as any other channel.

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

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2009-09-06 21:23

Message:
It appears that channel creation occurs at several places, while they all
end up calling Tcl_RegisterChannel, whose channel argument is *not*
declared const.
Do you have an objection against extending T_RC's mission to "std
normalization" (ie rewriting "file1" as "stdin" etc) ? Or is its lack of
side effects too deep in its DNA ?

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

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