Re^4: Testing for a background process waiting for input (use a thread)

a "unixish" implementation of BrowserUk's idea

Nice!++

the backspace cancellation trick would only work under rare circumstances (AFAICT) — simply reading from stdin would, for example, not treat the backspaces in any special way.

I added a little extra diagnostics. a) When the parent detects that the child entered an input state, it sends it a string "hello\n"; b) when the child enters an input state, it prints out what it receives:

The upshot shows that on Windows at least, even though the child (perl in this case) only uses a standard read from stdin scalar <STDIN>, the CRT provides line-editing that allows the backspace cancellation to work:

C:\test>detectChildInputState -I=0 -N=2
Kid done
Kid never entered input state
Parent done

C:\test>detectChildInputState -I=1 -N=2
Child waiting for input
Parent done
Kid got hello
Kid done

C:\test>detectChildInputState -I=0 -N=10
Command timed out
Kid never entered input state
Parent done

C:\test>detectChildInputState -I=1 -N=10
Child waiting for input
Parent done
Kid got hello
Kid done

C:\test>detectChildInputState -I=0 -N=12
Command timed out
Kid never entered input state
Parent done

C:\test>detectChildInputState -I=1 -N=12
Command timed out
Kid never entered input state
Parent done
[download]

But I guess what you are saying is that under *nix, the standard CRT input routines don't provided line editing facilities, unless the program in question uses a readline(3) library or similar.

Would nulls be an workable alternative? Or DC1/DC3 (XON/XOFF)?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^4: Testing for a background process waiting for input (use a thread) Select or Download Code

Replies are listed 'Best First'.
Re^5: Testing for a background process waiting for input (use a thread) by Eliya (Vicar) on Apr 15, 2012 at 04:22 UTC
But I guess what you are saying is that under nix, the standard CRT input routines don't provided line editing facilities, unless the program in question uses a readline(3) library or similar.* Essentially yes. stdin is just a file handle like any other, which by itself is unfiltered / binary-clean. Any other behavior you may observe (typically with interactive sessions) is the result of other layers that sit in between stdin and the user/keyboard, most prominently a tty and (optionally) some readline library. When stdin is connected to a regular pipe for non-interactive communication, those layers are not involved, unless things have explicitly been programmed that way (as with tools like Expect or similar) — this of course can be done, but usually isn't.	[reply]

Replies are listed 'Best First'.

Re^5: Testing for a background process waiting for input (use a thread)
by Eliya (Vicar) on Apr 15, 2012 at 04:22 UTC

But I guess what you are saying is that under *nix, the standard CRT input routines don't provided line editing facilities, unless the program in question uses a readline(3) library or similar.

Essentially yes. stdin is just a file handle like any other, which by itself is unfiltered / binary-clean. Any other behavior you may observe (typically with interactive sessions) is the result of other layers that sit in between stdin and the user/keyboard, most prominently a tty and (optionally) some readline library.

When stdin is connected to a regular pipe for non-interactive communication, those layers are not involved, unless things have explicitly been programmed that way (as with tools like Expect or similar) — this of course can be done, but usually isn't.

[reply]