Tcl Source Code

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).

Those appear to be tests that I'd expect to be broken by this type of fix of this issue. My principal concern was always the confusion about what the name of the channel (file2 in this bug report's example) really was; whether stderr (and also stdout and stdin) are aliases or real names.

(chan-io-14.4 is just a [chan]-ification of io-14.4)

Failing tests:

---- Result was:
{ chan close stdin
stdout
} {stderr
}
---- Result should have been (exact matching):
{ chan close stdin
file1
} {file2
}
==== chan-io-14.4 FAILED

---- Result was:
{ close stdin
stdout
} {stderr
}
---- Result should have been (exact matching):
{ close stdin
file1
} {file2
}
==== io-14.4 FAILED

allow_comments - 1

Fixed as suggested by Donal

Added a patch, following exactly dkf's suggestion. Andreas (or anyone other), please evaluate! It shows that no current test case fails, but it would be good to add a test case for the new behavior.

Noting that the magic behavior is in fact documented and not
UNIX-specific (which I originally thought), it should be preserved
in Tcl8.x! After doing this test, I changed my opinion and I now
agree with DKF. The change looks harmless, and makes the
script behavior less confusing. So, +1 for me.

The *potential incompatibility* only consists of the function
Tcl_CreateChannel() and its deratives, which now sometimes
ignores the chanName argument. The proposed doc
change is in the patch as well.

Regards,
           Jan Nijtmans

File Added - 344019: channel.patch

Adding to the confusion:

% info pa
8.6b1
% open README r
file5
% puts file5 foo
channel "file5" wasn't opened for writing
% close file5
% close stderr
% open README r
file2
% file channels
stdin stdout stderr
% read file2 30
README:  Tcl
    This is the T
% read stderr 30
cl 8.6b1 source distribution.

% open README r
file5
% read file5 30
README:  Tcl
    This is the T
% puts file5 foo
% 

stderr can be open for reading, but it's no error to write to it. And this "not an error" state appears contagious, as the final [puts file5] doesn't throw an error anymore.

All I seek with this bug report is for channels to have one name, which should be that which people expect it to be. The command creating the channel should be returning the One True Name of that channel. (The standard channel names are exceptionally well known.)

> the 10% can be fixed by a new [chan dup2/rename] or
> similar explicit, Tcl-channel-level redirection primitive.

Or just implement a "chan rename" for Tcl 8.6,
which at least is risk-less and provides redirection for
the standard channels on Windows, in combination
with (1) or (2). Then (3) can be considered for
Tcl 9, because judging the remarks it
wouldn't be wise to do it in Tcl 8.x.

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

3 breaks existing code.

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 ?

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.

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 ?