From: <no...@so...> - 2001-03-31 18:48:00
|
Bugs item #218339, was updated on 2000-10-25 17:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=218339&group_id=10894 >Category: Channel Types Group: 8.0.5 Status: Closed Priority: 2 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Gripes about pipes Initial Comment: OriginalBugID: 3985 RFE Version: 8.0.5 SubmitDate: '2000-01-06' LastModified: '2000-01-10' Severity: MED Status: Closed Submitter: techsupp ChangedBy: hobbs OS: Solaris FixedDate: '2000-10-25' ClosedDate: '2000-01-10' Name: Krzysztof Kozminski DesiredBehavior: Did anyone ever complain that Tcl pipes don't work very well with processes that pass out some of their output via exit status, such as the unix 'diff' command? I find this example rather annoying: % open [list | diff $file1 $file2 | wc] file7 % read file7 639 3230 19434 % close file7 child process exited abnormally There is nothing abnormal here; diff exits with status 1 if it finds differences. Presently, I have to do some ridiculous convolutions like: % open [list | /bin/sh -c "diff '$file1' '$file2';exit 0" | wc] which work fine until I have a filename with funny characters in it. Tcl pipe is much nicer in enabling me to work with arbitrary filenames. It would be nice to have some control over what exit status is considered abnormal. Perhaps something like: pid fileId pIndex -exitok expression where pIndex would be the address of the process in the pipe, and expression would be a Tcl expression in which '#' would stand for the exit status. In my example, I would do: % open "| diff .cshrc .login | wc" % pid file7 0 {(# == 0) == (# == 1)} Or maybe 'close' should return a list of exit status values for the user to decide whether they were abnormal or not. Something like: % close file7 -getexits 1 0 This RFE wants to allow for !0 exit codes to be considered "normal" exits, which goes against the grain of Tcl and the de facto standard for exit status. We understand that there are a few commands in Unix which return !0 after "normal" execution, but these can still be handled, and as special cases should be. -- 01/10/2000 hobbs ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=218339&group_id=10894 |