From: SourceForge.net <no...@so...> - 2009-09-07 14:53:04
|
Bugs item #2849797, was opened at 2009-09-03 11:00 Message generated for change (Comment added) made by nijtmans 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: Jan Nijtmans (nijtmans) Date: 2009-09-07 16: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 22: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 |