It sounds like the functionality here would be a low-priority feature request, that perhaps might belong in a separate module from a technical perspective.
In either case, the official documentation ( https://docs.perl6.org/type/Proc::Async) needs to be updated to reflect this limitation. Providing methods to tap into STDIN and STDOUT of a launched application combined with the statement of "Proc::Async allows you to run external commands asynchronously, capturing standard output and error handles, and optionally write to its standard input." would reasonably imply to any developer/user that this library is meant to work for any command. The subtleties of pipes versus PTYs are not mentioned anywhere in the documentation, and is a topic that nobody not familiar with the low-level guts of the terminals is likely to know (myself included). While it adds a lot of overhead, the "ssh -t -t" approach seems to be the best workaround until somebody develops a true Expect module for Perl6, or extends Proc::Async to support PTYs. On Tue, Jan 17, 2017 at 3:41 PM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > On Wed, Jan 4, 2017 at 11:20 PM, David E. <perl6-bugs-follo...@perl.org> > wrote: > > > SSH is one example. When using key-based logins everything works > > perfectly. If not using key-based logins (as required for a certain > piece > > of hardware I need to work with), the password prompt is not captured by > > Proc::Async. STDIN is read directly from the user shell, and the prompt > > itself is never output from the 'tapped' stdout. Further, SSH will > refuse > > to get even that far if the "-T" parameter is not given to it. > > > > Screen is another example (I'm trying to use this because > > Device::SerialPort hasn't been ported to Perl6 yet). No matter what I > try, > > screen always aborts with the error "Must be connected to a terminal." > > > > Strictly speaking, this is not a bug: the interface for these kinds of > programs is usually some variant of expect (the original being in Tcl, with > versions for Perl 5, Python, and other languages). ptys are a more limited > and more complex (and *far* less portable, in particular not possible on > Windows) resource than pipes, and general subprocess interfaces usually > aren't suitable; and adding the necessary logic to allow ptys to work > properly complicates the common case considerably. > > The portability concern also means that pty support likely does not belong > in Perl 6's core, but should be provided by a POSIX support module. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >
