I am redefining stdout and stderr using channels.
It seems to work fine for all cases except the following:
exec >&@stdout printenv
Which gets an error:
Error: channel "stdout" wasn't opened for writing
Any ideas how to get the above exec command to work (created from
init.tcl) with a redefined stdout channel?
Thanks.
-William
> Hello,
>
> I am redefining stdout and stderr using channels.
>
> It seems to work fine for all cases except the following:
>
> exec >&@stdout printenv
Hi William,
'stdout' is a special channel, it is _not_ a fileId as
required by this notation. exec manual page will tell
you that >&@fileId needs a file descriptor,
for a file that have been opened in write mode.
The solution is (IMHO) straightforward:
<CODE>
exec 2>&1 printenv
</CODE>
2>&1 tells the shell to redirect channel 2 (stderr)
to channel 1 (stdout).
Regards,
Stéphane
> > exec >&@stdout printenv
> 'stdout' is a special channel, it is _not_ a fileId as
> required by this notation.
Could someone, perhaps, explain "why not"? I'm just curious what is it
about TCL's concept of stdout that makes this notation not work?
Fredderic
Fredderic wrote:
> Could someone, perhaps, explain "why not"? I'm just curious what is it
> about TCL's concept of stdout that makes this notation not work?
Absolutely nothing about *Tcl's* concept of stdout. I just tried it
in tclsh from the the command line on Linux and Windows, and it
worked.
But 'tkcon' and the Wish console on windows are different in that
'stdout' there has no file descriptor in the underlying implementation.
It's a channel to a virtual file that's implemented with callbacks into
more Tcl code. As such, there are some twists like the fact that it
can't be inherited by subprocesses, and hence can't appear on
redirection.
We recognize that these issues are flaws, and with VFS becoming more
and more common, we'll need to deal with things like
exec myprog >/some/path/inside/a/vfs
which also isn't quite right, exactly.
TIPs 218, 219, 228 and 230 all touch related functionality.
--
73 de ke9tv/2, Kevin
> But 'tkcon' and the Wish console on windows are different in that
> 'stdout' there has no file descriptor in the underlying
> implementation. It's a channel to a virtual file that's implemented
> with callbacks into more Tcl code. As such, there are some twists
> like the fact that it can't be inherited by subprocesses, and hence
> can't appear on redirection.
Ahhh..... I've never used tkcon or Wish (or TCL and friends on
Windows). Which is why I was so surprised... I was sure it worked in
tclsh on Linux, but I'm not familiar enough with that syntax to be
certain I knew how to test it correctly.
Out of curiosity, in case I ever have the inclination to use either of
those, does this issue only effect tkcon/Wish on Windows, or is it a
general problem that runs through Unix's too?
Fredderic
No, the lack of a std channels is particular to Windows gui subsystem
apps and OS X apps run from the Finder.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
I've seen the equivalent on some Unix desktops (don't remember the
details of which) where the applications were being started with the
std channels being *closed* (and not redirected to/from /dev/null).
IIRC, Tcl doesn't deal well with this situation...
Donal.
I'd guess in that case, TCL should just open /dev/null in place of the
missing standard channels, shouldn't it? At least that way, they go
SOMEWHERE.
But that's still distinct, as I understand it, from Jeff Hobbs saying
that Windows is lacking the facility to capture an [exec]'s standard
channels and slurp them onto the tkcon/Wish console? Or should I just
give up and go hide under a rock on this one? ;)
Fredderic