From: SourceForge.net <no...@so...> - 2009-09-08 09:01:41
|
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: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 |