Tcl

Thanks!!!

OK got it. This is not a Tcl nor Linux problem, just one specific behavior
of csh.
Details from the strace:

12200 09:32:12.664493 execve("/bin/csh", ["csh"..., "-fc"..., "echo hello
>fff"...], [/* 69 vars */] <unfinished ...>
12200 09:32:12.675081 dup2(0, 16) = 16
12200 09:32:12.747895 open("fff", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1
EACCES (Permission denied)
12200 09:32:12.748463 write(18, "fff: Permission denied.\n", 24) = 24
12200 09:32:12.748541 lseek(16, 0, SEEK_END) = 8660

Explanation:

(1) The dup2 is part of the redirections for the "echo hello" command. It
just inherits desc 0 because there is no redirection on stdin.
(2) Csh tries to honour the > redirection, and gets an (expected) error.
It barfs to stderr (which is okay).
(3) *but* it also decides to skip ahead to the end of the local
subcommand's stdin (lseek(16,...))
(4) All this hooks back to Tcl's stdin since the [exec csh] has no stdin
redirection either.
(5) Hence on the next attempt to read, the Tcl IO subsystem gets an EOF.
QED.

I have no idea why Csh does (3). At the extreme it could vaguely make
sense for an interactive Csh to do that on a terminal, so that it skips to
new typed command when an error has occurred in a buffered block of
commands... But here the Csh is not interactive. From my seat it is a fully
qualified Bug.

A simple workaround is to [exec csh ... < /dev/null].

I'll thus close this artifact as Invalid, since Tcl cannot be held
responsible for Csh's misbehavior.
My personal take on Csh is: only use it interactively if ever. That's not
a programming language. That's an engineer's nightmare.
*Always* use /bin/sh when you need to resort to an OS shell.

File Added: tra

File Added: tra

Please attach an strace:

strace -f -tt -o tra tclsh < xxx.tcl