[vox-tech] writing to a shell instance

[Ken Bloom]

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 <matloff at cs.ucdavis.edu>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
>
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lugod.org/pipermail/vox-tech/attachments/20111026/84e04304/attachment-0001.htm