Re^3: Capture::Tiny alternative

Replies are listed 'Best First'.
Re^4: Capture::Tiny alternative by glasswalk3r (Friar) on Mar 27, 2017 at 23:44 UTC
The overall challenge is _my_ code takes sshutle as input parameter, so I can't have any guesses on what the external program could be ( any ), I don't try to get any workarounds ( like catch/ignore signals ) either. That's just not good. You might not have the source code of the program, but you do need to know how it behaves regarding IPC. A good example (if memory serves me well) in the `bc` program from UNIX. I think Perl documentation mentions that this kind of program is not reliable at all for IPC. Worst, some part of the program might be changed in the next release, and due buffering/signals handling it may broke down your IPC handling. But wait, you do have access to sshutle code... are you sure CPAN doesn't have something that implements the same you're looking for? If not, maybe you would be willing to implement a version in Perl as well. Or even fork the project and make the program behave well through IPC... or even use sockets instead! Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply] [d/l]
Re^4: Capture::Tiny alternative by afoken (Chancellor) on Mar 28, 2017 at 04:57 UTC
In my case sshutle This sshuttle? gets run as daemon (-D flag) Why? If you want to interact with the program, you don't want it to "break all bridges", fork(2) itself away from your control, disconnect from STDIN, STDOUT, and STDERR. (See `daemonize()` in client.py.) Simply don't use that flag, sshuttle will work without it. If you want sshuttle to run after your script exits, consider using daemontools or one of its clones instead of reinventing the wheel. See also the djb way. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l]
Re^4: Capture::Tiny alternative by Anonymous Monk on Mar 25, 2017 at 20:30 UTC
Well, we don't really know what your requirements are here, but if the task must run "as if on a command line" then you may have to spawn the jobs on their separate ptys. See IO::Pty. The program in question could be acting differently depending on isatty test.	[reply]
Re^5: Capture::Tiny alternative by melezhik (Monk) on Mar 25, 2017 at 20:53 UTC
Could you please provide an example code how can I run external program using pty and read its stdout in real time ? Also I need to know if programm exit successfully , is it possible with pty ? Sorry, I have read IO::Pty docs and it is not very clear what should I do.	[reply]
Re^6: Capture::Tiny alternative by Anonymous Monk on Mar 25, 2017 at 21:21 UTC
Okay, here's an example of IO::Pty usage. I do not know if there are any modules out there to support such functionality. `sub pty_spawn { my $pty = new IO::Pty; $pty->set_raw(); # stty -opost -echo! my $pid = fork // die; unless ($pid) { $pty->make_slave_controlling_terminal(); # $pty->slave->clone_winsize_from(\*STDIN); close STDIN; close STDOUT; open STDIN, "+>&", $pty->slave; open STDOUT, "+>&", $pty->slave; exit !exec @_; } close $pty->slave; return $pty; }` [download] Calling `pty_spawn(@cmd)` leaves you with the $pty handle (the master side), that you can read and write. You'll need an event loop if you plan to do both. But if you only read, it should be easy. And you've got the $pid to wait on as usual (for exit status).	[reply] [d/l] [select]