Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error: channel "stdout" wasn't opened for writing when "exec >&@stdout printenv"

417 views
Skip to first unread message

Will...@gmail.com

unread,
Nov 29, 2006, 3:24:05 PM11/29/06
to
Hello,

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

Stéphane A.

unread,
Nov 30, 2006, 1:55:58 AM11/30/06
to

Will...@gmail.com a écrit :

> 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

Fredderic

unread,
Nov 30, 2006, 2:29:36 AM11/30/06
to
On 29 Nov 2006 22:55:58 -0800,
"Stéphane A." <stephan...@yahoo.fr> wrote:

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

Kevin Kenny

unread,
Nov 30, 2006, 7:08:00 AM11/30/06
to
"Stéphane A." <stephan...@yahoo.fr> wrote:
>>> exec >&@stdout printenv
>>
>>'stdout' is a special channel, it is _not_ a fileId as
>>required by this notation.

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

Fredderic

unread,
Nov 30, 2006, 10:06:42 AM11/30/06
to
On Thu, 30 Nov 2006 07:08:00 -0500,
Kevin Kenny <ken...@acm.org> wrote:

> 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

Jeff Hobbs

unread,
Nov 30, 2006, 11:09:46 AM11/30/06
to

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/

Donal K. Fellows

unread,
Nov 30, 2006, 1:04:51 PM11/30/06
to
Jeff Hobbs wrote:
> No, the lack of a std channels is particular to Windows gui subsystem
> apps and OS X apps run from the Finder.

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.

Fredderic

unread,
Nov 30, 2006, 2:05:36 PM11/30/06
to
On 30 Nov 2006 10:04:51 -0800,

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

0 new messages