From: SourceForge.net <no...@so...> - 2009-03-01 20:44:01
|
Bugs item #2647951, was opened at 2009-02-27 22:56 Message generated for change (Comment added) made by eugene_cdn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2647951&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: 50. Embedding Support Group: current: 8.4.19 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Yevgen Ryazanov (eugene_cdn) Assigned to: Alexandre Ferrieux (ferrieux) Summary: Error in exec ends stdin Initial Comment: Tcl version: 8.4+ OS: Linux Red Hat 4, 5 Maybe, it is a Linux bug, but it appeared in Tcl's stdin handling. I got the problem in C, but I created a Tcl script that fails the same way. If you execute a certain command though system()/exec which fails, stdin stream does not provide any more input except already buffered in C code. My Tcl script is more that 8K long because I initially got the problem on the very next byte after 8K, but attached test fails a bit earlier. Important: file must be redirected to stdin: > tclsh <xxx.tcl Read(0) just returns 0 as if it is the end of pipe/socket. If you specify file name as an argument, the script works. I cannot classify the problem. Just weird. Stdin stays open, /proc/pid/fd shows it, but 0 handle is damaged. Fork/clone is doing something bad to to the parent's stdin. Any help is appreciated. I cannot depend on any developer who can call system() and break stdin. Yes, I know that such redirection seem to make no sense, but it does; it is just a simplified version. ---------------------------------------------------------------------- >Comment By: Yevgen Ryazanov (eugene_cdn) Date: 2009-03-01 12:43 Message: Thanks!!! ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-03-01 02:57 Message: 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. ---------------------------------------------------------------------- Comment By: Yevgen Ryazanov (eugene_cdn) Date: 2009-02-28 10:53 Message: File Added: tra ---------------------------------------------------------------------- Comment By: Yevgen Ryazanov (eugene_cdn) Date: 2009-02-28 09:33 Message: File Added: tra ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-02-28 04:23 Message: Please attach an strace: strace -f -tt -o tra tclsh < xxx.tcl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2647951&group_id=10894 |