Re: "broken pipe", but not when debugging...
A broken pipe usually means that one end of the connection has been closed for one reason or another. You don’t show the actualtoggle quoted messageShow quoted text
read and write code, but that is most likely where the problem occurs. Be sure and put the data write into a try-catch block in order
to catch the broken pipe (assuming it occurs on a write). This is actually documented, but I’ll have to go find it to say. My notes indicate the
docs to say: This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe
or socket endpoint, if no free space is left on the file system, or if any other writing error occurs. The catch block should set pretty much all the
handles to nil, especially the read handle.readabilityHandler. It is pretty easy and useful to set up the readabilityHandler block to get the
data coming from the executable.
This is a two-way street, and it is likely the other end is participating in the broken pipe, if not actually throwing it. If your pipes are not set
up properly and it tries to write to its stdout, you will see this issue.
Also, it might be helpful to debug the son an El Capitan system where we still have a good logging system.
One thing that does look slightly strange is the way the arguments are set up. NSTask really would like for each item to be in a separate
entry (i.e. @[@“ponder”, @“off”, @“noise”, @“1000000”…]. I don’t know if it makes any difference, but is worth trying.
This stuff works pretty well, but there is a lot of opportunity to get broken pipes when one side shuts down for any reason, or simply
closes their side of the connection. Try-catch is definitely your friend here, on both sides of the connection.
On Aug 10, 2017, at 4:12 PM, Graham Cox <graham@...> wrote: