Re: Why not exit on SIGPIPE
- From: "tom.rmadilo" <tom.rmadilo@xxxxxxxxx>
- Date: Sun, 14 Oct 2007 01:39:24 -0000
On Oct 13, 9:38 am, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:
On Oct 13, 5:35 pm, "tom.rmadilo" <tom.rmad...@xxxxxxxxx> wrote:
Is there any difference between Tcl as a shell (tclsh) and Tcl as a
language? I can't see why a program should exit just because of an
error. Communication errors in particular are not unexpected.
See the beginning of the thread for the rationale.
See the end for the conclusion: we're heading for a [fconfigure]
switch, which you're welcome not to use if you dislike it.
The main target of this switch is stdout, for _filters_, which are a
specific case of glue, with specific properties: when a filters gets
to know that nobody's interested in its output any longer, it makes
sense to exit. The situation is of course utterly different for a more
complex glue with higher connectivity.
I did see the beginning of the thread. Tcl is a programming language.
Bash, and tclsh, and less and more are programs. Putting a switch on a
channel is trying to turn a command into a program. Are there any
other examples of commands doing this? In any language? Even a shell
(the shell command, not the shell)? It seems like poor programming
style and pure laziness. Programming languages need to be simple.
Actually this is one of my biggest gripes with switches. Some
developers think that a switch is okay to add because it is backwards
compatible (the "don't use it if you don't need it" argument...All
switches are used by everyone, every call passes through the switch
handling, source code becomes more complex). In most cases, it is
better to wrap a regular API with a filter to get the behavior you
want.
Instead of coding behavior into a switch, you could instead add
something else to fconfigure. Maybe fconfigure could return the last
result code. Then this tiny amount of information could be used by
developers familiar with channel programming to decide what to do.
Programming channels/sockets/fds with Tcl is easy because much of the
real complexity is removed, trying to add a little bit of it back via
switches is very short sighted. One other problem is that the call to
fconfigure could be well removed from the actual use of the channel
and the decision to handle the error.
I'm not sure this response is coherent, but looking at fconfigure, I
see channel configuration (get and set options), and at most
filtering. Exit code is not a filter, it is a branch. My argument is
that branch code should not be in switches. I think this is distinct
from constructs like try..., etc. where you make very explicit, in one
place, what is going on.
.
- References:
- Why not exit on SIGPIPE
- From: Alexandre Ferrieux
- Re: Why not exit on SIGPIPE
- From: Donal K. Fellows
- Re: Why not exit on SIGPIPE
- From: Alexandre Ferrieux
- Re: Why not exit on SIGPIPE
- From: Ron Fox
- Re: Why not exit on SIGPIPE
- From: Donal K. Fellows
- Re: Why not exit on SIGPIPE
- From: Ron Fox
- Re: Why not exit on SIGPIPE
- From: Donal K. Fellows
- Re: Why not exit on SIGPIPE
- From: Alexandre Ferrieux
- Re: Why not exit on SIGPIPE
- From: tom.rmadilo
- Re: Why not exit on SIGPIPE
- From: Alexandre Ferrieux
- Why not exit on SIGPIPE
- Prev by Date: Re: Messy graphical language ?
- Next by Date: Re: Why not exit on SIGPIPE
- Previous by thread: Re: Why not exit on SIGPIPE
- Next by thread: Re: Why not exit on SIGPIPE
- Index(es):
Relevant Pages
|