On Jun 12, 2014, at 4:53 PM, Jerry Krinock <je...@ieee.org> wrote:
> On 2014 Jun 12, at 15:35, Greg Parker <gpar...@apple.com> wrote:
>> If you get back an empty data object you are at end of file, and you should
>> not call -waitForDataInBackgroundAndNotify again.
>
> Thank you, Greg. I thought that same thing a couple hours ago. But it
> trades one problem for another…
>
> * * *
>
> To implement your suggestion, I moved the line
>
> [input waitForDataInBackgroundAndNotify] ;
>
> up a few lines, into the block that is conditioned by if([data length] > 0)
That looks correct to me.
> Indeed, doing that fixes the infinite loop, but then there is no response to
> subsequent stdin because, presumably, without
> -waitForDataInBackgroundAndNotify, it’s not waiting and not notifying.
>
> That’s why I focused on the weird zero-byte notification as being the
> problem. It seems like NSFileHandle, that it does not reset itself to "no
> data available" after I’ve read the piped-in initial stdin.
There's no such thing as "initial stdin" and "subsequent stdin". You can get
stdin from a pipe or from user input, but not both.
This sends "text" via stdin, then closes stdin. Nothing the user types will
appear on stdin.
echo "text" | ./YourTool
This lets the user send input via stdin until the user types whatever the shell
interprets as EOF (typically control-D at the start of a line).
./YourTool
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
