Re: [vox-tech] writing to a shell instance
Thanks for all the suggestions, everyone! I should mention the application: A debugging tool for R (written in Python). R's internal debugging facilities are primitive, limited and clunky, a lack that my program is intended to remedy. For example, R's own debugger doesn't have conditional breakpoints, but my program adds them. My program writes commands to the R session, as if the user had typed the commands him/herself. As I said, I add a lot more commands, by handling them within my program. The current version is at http://heather.cs.ucdavis.edu/debugR.html It's basically for Unix-family machines only, because it relies on screen. I've gotten requests to port it to Windows, hence my query to vox-tech. I think the simplest solution may be to use Python to open a pipe to R, and then have Python accept input from either the keyboard or the debugger, say using select(). Norm ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
On 10/26/2011 03:34 PM, Norm Matloff wrote:
Here's what I'd like to do. I'm running code, in this case Python, in
xterm A (replace by your favorite terminal emulator), and want that code
to write to xterm B, just as if I had typed directly into xterm B.
Say for example I want to run the ls command in xterm B, but do so via
some action in A. Say the latter is /dev/pts/8. I could run the Python
code
import os
os.system('echo ls /dev/pts/8')
I have 2 questions:
1. How do I get the end-of-line character in there, so that the ls
command actually runs? I've tried ls\n, ls \r\n and lots of
variants, e.g.
echocmd = 'echo ls'+chr(14)+chr(10)+' /dev/pts/13'
os.system(echocmd)
But no matter what I try, it doesn't work. The ls does appear in
xterm B, and the newlines, but it's still expecting more input from me.
If I manually hit Enter in xterm B, then it works.
I know this must be simple ridiculously simple, but I don't see it.
Yes, I know I could use a pipe here, but I want to retain the ability to
manually type in xterm B, i.e. I want to be able to input there either
by physically typing there or by having the program in xterm B do it.
Maybe I can launch xterm A via a pipe in the first place? I've tried
that a bit, but don't have enough experience with pipes to see how to
make that work either.
One solution is to use screen, which is what I'm doing currently,
but some people would like to use my program from Windows.
2. Which brings me to my next question: How can I do this in Windows?
(Not Cygwin.)
Any ideas would be much appreciated.
Norm
As for question 1, backticks are what you want:
echo `ls` /dev/pts/8
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
You could do this at an X11 level, e.g.
http://www.doctort.org/adam/nerd-notes/x11-fake-keypress-event.html
This tool looks promising also, but I haven't tried it:
http://www.semicomplete.com/projects/xdotool/
I think you'd need to use some Windows API to do this there.
Harold
On Wed, Oct 26, 2011 at 4:20 PM, Bruce Wolk baw...@ucdavis.edu wrote:
On 10/26/2011 03:34 PM, Norm Matloff wrote:
Here's what I'd like to do. I'm running code, in this case Python, in
xterm A (replace by your favorite terminal emulator), and want that code
to write to xterm B, just as if I had typed directly into xterm B.
Say for example I want to run the ls command in xterm B, but do so via
some action in A. Say the latter is /dev/pts/8. I could run the Python
code
import os
os.system('echo ls /dev/pts/8')
I have 2 questions:
1. How do I get the end-of-line character in there, so that the ls
command actually runs? I've tried ls\n, ls \r\n and lots of
variants, e.g.
echocmd = 'echo ls'+chr(14)+chr(10)+' /dev/pts/13'
os.system(echocmd)
But no matter what I try, it doesn't work. The ls does appear in
xterm B, and the newlines, but it's still expecting more input from me.
If I manually hit Enter in xterm B, then it works.
I know this must be simple ridiculously simple, but I don't see it.
Yes, I know I could use a pipe here, but I want to retain the ability to
manually type in xterm B, i.e. I want to be able to input there either
by physically typing there or by having the program in xterm B do it.
Maybe I can launch xterm A via a pipe in the first place? I've tried
that a bit, but don't have enough experience with pipes to see how to
make that work either.
One solution is to use screen, which is what I'm doing currently,
but some people would like to use my program from Windows.
2. Which brings me to my next question: How can I do this in Windows?
(Not Cygwin.)
Any ideas would be much appreciated.
Norm
As for question 1, backticks are what you want:
echo `ls` /dev/pts/8
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
On 10/26/2011 04:20 PM, Bruce Wolk wrote: As for question 1, backticks are what you want: echo `ls` /dev/pts/8 Er, that's running a command in the original window and sending the output to the second window, which isn't what was asked for. Not to mention being rather confusing. The output of ls might well be for a different directory than the second terminal is in. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
On 10/26/2011 03:34 PM, Norm Matloff wrote:
Here's what I'd like to do. I'm running code, in this case Python, in
xterm A (replace by your favorite terminal emulator), and want that code
to write to xterm B, just as if I had typed directly into xterm B.
Say for example I want to run the ls command in xterm B, but do so via
some action in A. Say the latter is /dev/pts/8. I could run the Python
code
import os
os.system('echo ls /dev/pts/8')
I have 2 questions:
1. How do I get the end-of-line character in there, so that the ls
command actually runs? I've tried ls\n, ls \r\n and lots of
variants, e.g.
Er, getting in there should be easy. But your writing to the same
device that the shells OUTPUT is writing to. Not to the shells input
which is passed through X when the window manage decides that the focus
is in that window.
Sounds like you want something like:
nc -l | bash
That way anything you write to port gets executed in the target
window because bash's stdin is listening to the port.
echocmd = 'echo ls'+chr(14)+chr(10)+' /dev/pts/13'
os.system(echocmd)
But no matter what I try, it doesn't work. The ls does appear in
xterm B, and the newlines, but it's still expecting more input from me.
If I manually hit Enter in xterm B, then it works.
Woah, really? You sure? I just tried it, I send a ls to /dev/pts/7 and
I see it in the target window, if I hit return in the target window I
just get a new prompt. That fits with my idea of how this works since
you aren't writing to bash's input.
I know this must be simple ridiculously simple, but I don't see it.
Yes, I know I could use a pipe here, but I want to retain the ability to
manually type in xterm B, i.e. I want to be able to input there either
by physically typing there or by having the program in xterm B do it.
Ah, that makes it more complicated, seems like you want the equivalent
of tee, but for input instead of output. A tiny bit of perl/python/c
code should be able to listen to say a socket and interactive input and
exec both. I often do similar with screen -x to let two people share a
shell. Not surprised that doesn't work under windows.
Maybe I can launch xterm A via a pipe in the first place? I've tried
that a bit, but don't have enough experience with pipes to see how to
make that work either.
I'd be a little surprised if you could get an xterm to accept input from
a pipe AND what you type. Especially since it's bash listening/running
commands and not the terminal.
One solution is to use screen, which is what I'm doing currently,
but some people would like to use my program from Windows.
2. Which brings me to my next question: How can I do this in Windows?
(Not Cygwin.)
I don't run windows, but seems like there's likely a python or perl port
to windows (not cygwin) and portability for something so simple seems
very likely.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
I was wondering if I could get this down to just a few lines of code then realized that the shell should be able to handle this. Turns out it works okay. In terminal a: $ while /bin/true; do echo date; sleep 1; done | nc localhost In terminal b I run: ( nc -d -l cat) | bash And I see Wed Oct 26 19:21:54 PDT 2011 Wed Oct 26 19:21:55 PDT 2011 Wed Oct 26 19:21:56 PDT 2011 Wed Oct 26 19:21:57 PDT 2011 In terminal b if I say ls -al: Wed Oct 26 19:23:09 PDT 2011 ls -al total 16 drwxrwsr-x 2 bill bill 4096 2011-10-26 19:18 . drwxrwsr-x 143 bill bill 12288 2011-10-26 19:18 .. -rw-rw-r-- 1 bill bill 0 2011-10-26 19:18 filea -rw-rw-r-- 1 bill bill 0 2011-10-26 19:18 fileb Wed Oct 26 19:23:10 PDT 2011 A nice side effect is if I type slowly in terminal B: Wed Oct 26 19:24:26 PDT 2011 tWed Oct 26 19:24:27 PDT 2011 oWed Oct 26 19:24:28 PDT 2011 uWed Oct 26 19:24:29 PDT 2011 cWed Oct 26 19:24:30 PDT 2011 hWed Oct 26 19:24:31 PDT 2011 fWed Oct 26 19:24:32 PDT 2011 ilecWed Oct 26 19:24:33 PDT 2011 Wed Oct 26 19:24:34 PDT 2011 ls filea fileb filec Wed Oct 26 19:24:35 PDT 2011 So basically the buffering means that the streams don't stomp on each other unnecessarily. Assuming there's a nc/bash port to windows or a functional equivalent it should work there as well. Not pretty, but it seems workable. You could of course have perl/python send or receive in either terminal A or B. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
You would think that you could write to /dev/$PID/fd/0 and have that be the
input into bash, but you can't. ttys are wierd.
Xterm uses the Unix 98 pseudo terminal interface to talk to its child
process using a /dev/pts/something device file. It calls open(/dev/ptmx)
which is the single Unix 98 pesudo-terminal device in the system, and which
behaves somewhat wierd. Every time you open /dev/ptmx, it creates a new
/dev/pts slave device. After making several system calls on the /dev/ptmx
device, it calls ptsname on the file descriptor it has for /dev/ptmx, and
gets (as a string) the name of the /dev/pts slave device. The process can
give this name to whomever it pleases, either by sending the client the
string somehow, or by opening the /dev/pts device and letting the child
process inherit the file descriptor of the slave device (just like you do
when setting up input redirection using pipes).
Basically, if you want to write something to the tty, so that the child
process (bash, in your case) can read it, you have to write to the master
device /dev/ptmx. But you can't just open /dev/ptmx and be routed to the
right slave, because if you call open(/dev/ptmx), you get a *brand new slave
*. So if you want to send data to the same /dev/pts slave that the Xterm is
sending data to, you need to get the file descriptor from the Xterm, which
AFAIK has to be done by inheriting it as a child process. (Even using
/proc/PID/fd won't help because the file descriptor shows up there as a
symlink to the slave device.)
When you tried to hijack /dev/pts/13 to write the ls command to bash, you
were writing to the slave device. This data is read back from the master fd
in the Xterm. The ls command was sent directly to the Xterm, and bash
never saw it at all. So what happened was that you acted like you *were* the
bash shell, not like you were the Xterm, and no technique for writing a
newline would help you get your ls command interpreted by bash.
Since you wanted send a command to bash, you could either use a pipe, or
you could use gdb to hijack bash's stdin, as described at
http://ingvar.blog.redpill-linpro.com/2010/07/10/changing-a-process-file-descriptor-on-the-fly/
.
On Wed, Oct 26, 2011 at 6:34 PM, Norm Matloff matl...@cs.ucdavis.eduwrote:
Here's what I'd like to do. I'm running code, in this case Python, in
xterm A (replace by your favorite terminal emulator), and want that code
to write to xterm B, just as if I had typed directly into xterm B.
Say for example I want to run the ls command in xterm B, but do so via
some action in A. Say the latter is /dev/pts/8. I could run the Python
code
import os
os.system('echo ls /dev/pts/8')
I have 2 questions:
1. How do I get the end-of-line character in there, so that the ls
command actually runs? I've tried ls\n, ls \r\n and lots of
variants, e.g.
echocmd = 'echo ls'+chr(14)+chr(10)+' /dev/pts/13'
os.system(echocmd)
But no matter what I try, it doesn't work. The ls does appear in
xterm B, and the newlines, but it's still expecting more input from me.
If I manually hit Enter in xterm B, then it works.
I know this must be simple ridiculously simple, but I don't see it.
Yes, I know I could use a pipe here, but I want to retain the ability to
manually type in xterm B, i.e. I want to be able to input there either
by physically typing there or by having the program in xterm B do it.
Maybe I can launch xterm A via a pipe in the first place? I've tried
that a bit, but don't have enough experience with pipes to see how to
make that work either.
One solution is to use screen, which is what I'm doing currently,
but some people would like to use my program from Windows.
2. Which brings me to my next question: How can I do this in Windows?
(Not Cygwin.)
Any ideas would be much appreciated.
Norm
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] writing to a shell instance
On Wed, Oct 26, 2011 at 10:39 PM, Ken Bloom kbl...@gmail.com wrote: You would think that you could write to /dev/$PID/fd/0 and have that be the input into bash, but you can't. ttys are wierd. Xterm uses the Unix 98 pseudo terminal interface to talk to its child process using a /dev/pts/something device file. It calls open(/dev/ptmx) which is the single Unix 98 pesudo-terminal device in the system, and which behaves somewhat wierd. Every time you open /dev/ptmx, it creates a new /dev/pts slave device. After making several system calls on the /dev/ptmx device, it calls ptsname on the file descriptor it has for /dev/ptmx, and gets (as a string) the name of the /dev/pts slave device. The process can give this name to whomever it pleases, either by sending the client the string somehow, or by opening the /dev/pts device and letting the child process inherit the file descriptor of the slave device (just like you do when setting up input redirection using pipes). Basically, if you want to write something to the tty, so that the child process (bash, in your case) can read it, you have to write to the master device /dev/ptmx. But you can't just open /dev/ptmx and be routed to the right slave, because if you call open(/dev/ptmx), you get a *brand new slave*. So if you want to send data to the same /dev/pts slave that the Xterm is sending data to, you need to get the file descriptor from the Xterm, which AFAIK has to be done by inheriting it as a child process. (Even using /proc/PID/fd won't help because the file descriptor shows up there as a symlink to the slave device.) When you tried to hijack /dev/pts/13 to write the ls command to bash, you were writing to the slave device. This data is read back from the master fd in the Xterm. The ls command was sent directly to the Xterm, and bash never saw it at all. So what happened was that you acted like you *were* the bash shell, not like you were the Xterm, and no technique for writing a newline would help you get your ls command interpreted by bash. Since you wanted send a command to bash, you could either use a pipe, or you could use gdb to hijack bash's stdin, as described at http://ingvar.blog.redpill-linpro.com/2010/07/10/changing-a-process-file-descriptor-on-the-fly/ . It's possible to transfer a file descriptor between processes using a unix domain socket (see http://stackoverflow.com/questions/2358684/can-i-share-a-file-descriptor-to-another-process-on-linux-or-are-they-local-to-t/2358843#2358843) so it's possible for the Xterm to share its file descriptor for the /dev/ptmx master with another process. Whether you can use this method to hijack the file descriptor with GDB is anybody's guess. If you come up with a devious way to do that, please share. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
