Hi, The command echo "service httpd status " > /dev/pts/1 is executed on one terminal, let us assume it as t1. The echo command is executed on t1 but the output(service httpd status" is directed to /dev/pts/1 terminal.
What I am saying is that the output is redirected directly to the terminal /dev/pts1/1. The output here is "service httpd status", which is generally a command. And so it gets executed.
What I want is to get the return value of this "service httpd status" to the terminal t1.
Anyways this is my requirement, related to my work.
Can we achieve this?
Regards, Devi.
On Wed, Sep 16, 2009 at 03:06:09PM -0400, devi wrote:
Hi, The command echo "service httpd status " > /dev/pts/1 is executed on one terminal, let us assume it as t1. The echo command is executed on t1 but the output(service httpd status" is directed to /dev/pts/1 terminal.
What I am saying is that the output is redirected directly to the terminal /dev/pts1/1. The output here is "service httpd status", which is generally a command. And so it gets executed.
No, the text just appears in the terminal associated with /dev/pts1/1; it does not not cause the command to be executed. That is to say, you can't use this as a mechanism to insert characters into a another terminal's input buffer.
But the command got executed, and it gave the status of apache on /dev/pts/1 terminal.
On Wed, 2009-09-16 at 11:18 +0100, Dave Mitchell wrote:
On Wed, Sep 16, 2009 at 03:06:09PM -0400, devi wrote:
Hi, The command echo "service httpd status " > /dev/pts/1 is executed on one terminal, let us assume it as t1. The echo command is executed on t1 but the output(service httpd status" is directed to /dev/pts/1 terminal.
What I am saying is that the output is redirected directly to the terminal /dev/pts1/1. The output here is "service httpd status", which is generally a command. And so it gets executed.
No, the text just appears in the terminal associated with /dev/pts1/1; it does not not cause the command to be executed. That is to say, you can't use this as a mechanism to insert characters into a another terminal's input buffer.
-- Red sky at night - gerroff my land! Red sky at morning - gerroff my land! -- old farmers' sayings #14
On 16Sep2009 19:43, devi devi@atc.tcs.com wrote: | On Wed, 2009-09-16 at 11:18 +0100, Dave Mitchell wrote: | > On Wed, Sep 16, 2009 at 03:06:09PM -0400, devi wrote: | > > The command | > > echo "service httpd status " > /dev/pts/1 is executed on one terminal, | > > let us assume it as t1. | > > The echo command is executed on t1 but the output(service httpd status" | > > is directed to /dev/pts/1 terminal. | > > | > > What I am saying is that the output is redirected directly to the | > > terminal /dev/pts1/1. | > > The output here is "service httpd status", which is generally a command. | > > And so it gets executed. | > | > No, the text just appears in the terminal associated with /dev/pts1/1; | > it does not not cause the command to be executed. That is to say, | > you can't use this as a mechanism to insert characters into a another | > terminal's input buffer. | > | But the command got executed, and it gave the status of apache | on /dev/pts/1 terminal.
That's quite interesting. It should _not_ cause the command to be executed, and I really believe something more is going on.
/dev/pts/1 is the "slave" side of the pseudoterminal; all pseudoterminals have a "master" side and a "slave" side.
The slave side is the "normal" terminal side that programs are connected to. Writing to it causes text to the displayed, and reading from it consumes text that is typed.
The master side is what terminal emulators like xterm use. Xterm is a GUI program that displays a terminal on your screen. When you type at the displayed GUI, xterm catches that and writes data to the _master_ side of the pseudo terminal it obtained. That stuff appears as though typed to ordinary programs on the slave side. Conversely, data _read_ by xterm from the master side is the data _written_ to the slave side; xterm gathers that and updates the GUI, thus displaying the program output.
See "man ptmx" for how a pseudo terminal is obtained under Linux.
Anyway, because of this scheme nothing you write to /dev/pts/1, a slave device, should cause it to be _typed_ at that terminal.
Can you confirm your setup in more detail?
I would imagine that you have two terminals open, with plain shells in them. Typing the command "tty" in each will tell you their names, and presumably one says "/dev/pts/1". The other is "t1".
And you are really typing: echo "service httpd status" >/dev/pts/1 in the "t1" terminal, and on the /dev/pts/1 terminal you are not seeing the string "service httpd status" displayed as plain output; instead you are seeing the output of the command: service httpd status
Is that all correct?
Can I suggest the following experiments?
First, run the command "set -x" in the shell on /dev/pts/1. That will turn of execution tracing, and it should then be more obvious is that shell is really executing the command. Type some commands in that shell, like "date" or "uptime" to see the effect. Then do your echo statement from "t1" again.
Secondly, on the "t1" terminal, run the command: echo -n "service httpd status" >/dev/pts/1 You should see it displayed on /dev/pts/1 but it won't run a command because we have not sent the end-of-line. If you're right, it will be as though typed, and you can go to the other terminal and edit the line and change it before pressing enter.
Cheers,
Hi,
On Thu, 2009-09-17 at 08:09 +1000, Cameron Simpson wrote:
On 16Sep2009 19:43, devi devi@atc.tcs.com wrote: | On Wed, 2009-09-16 at 11:18 +0100, Dave Mitchell wrote: | > On Wed, Sep 16, 2009 at 03:06:09PM -0400, devi wrote: | > > The command | > > echo "service httpd status " > /dev/pts/1 is executed on one terminal, | > > let us assume it as t1. | > > The echo command is executed on t1 but the output(service httpd status" | > > is directed to /dev/pts/1 terminal. | > > | > > What I am saying is that the output is redirected directly to the | > > terminal /dev/pts1/1. | > > The output here is "service httpd status", which is generally a command. | > > And so it gets executed. | > | > No, the text just appears in the terminal associated with /dev/pts1/1; | > it does not not cause the command to be executed. That is to say, | > you can't use this as a mechanism to insert characters into a another | > terminal's input buffer. | > | But the command got executed, and it gave the status of apache | on /dev/pts/1 terminal.
That's quite interesting. It should _not_ cause the command to be executed, and I really believe something more is going on.
/dev/pts/1 is the "slave" side of the pseudoterminal; all pseudoterminals have a "master" side and a "slave" side.
Here, the /dev/pts/1 is the tty of a virtual machine. This virtual machine is created by xen. Yes, I have come across master and slave pseudo terminals, but I have not set any anything like that.
The slave side is the "normal" terminal side that programs are connected to. Writing to it causes text to the displayed, and reading from it consumes text that is typed.
The master side is what terminal emulators like xterm use. Xterm is a GUI program that displays a terminal on your screen. When you type at the displayed GUI, xterm catches that and writes data to the _master_ side of the pseudo terminal it obtained. That stuff appears as though typed to ordinary programs on the slave side. Conversely, data _read_ by xterm from the master side is the data _written_ to the slave side; xterm gathers that and updates the GUI, thus displaying the program output.
See "man ptmx" for how a pseudo terminal is obtained under Linux.
Anyway, because of this scheme nothing you write to /dev/pts/1, a slave device, should cause it to be _typed_ at that terminal.
Can you confirm your setup in more detail?
There is no setup, I created the virtual machine, and then found its tty. and executed the command from other terminal "t1" as specified earlier.
I would imagine that you have two terminals open, with plain shells in them. Typing the command "tty" in each will tell you their names, and presumably one says "/dev/pts/1". The other is "t1".
And you are really typing: echo "service httpd status" >/dev/pts/1 in the "t1" terminal, and on the /dev/pts/1 terminal you are not seeing the string "service httpd status" displayed as plain output; instead you are seeing the output of the command: service httpd status
Is that all correct?
Can I suggest the following experiments?
First, run the command "set -x" in the shell on /dev/pts/1. That will turn of execution tracing, and it should then be more obvious is that shell is really executing the command. Type some commands in that shell, like "date" or "uptime" to see the effect. Then do your echo statement from "t1" again.
Secondly, on the "t1" terminal, run the command: echo -n "service httpd status" >/dev/pts/1 You should see it displayed on /dev/pts/1 but it won't run a command because we have not sent the end-of-line. If you're right, it will be as though typed, and you can go to the other terminal and edit the line and change it before pressing enter.
I have done, what you suggested, it's the same. Anyways my requirement is that, after the command is executed on /dev/pts/1, I should be able to get the return value on the terminal "t1"
eg: rc=`echo "service httpd status" > /dev/pts/1" I thought rc will hold the return value, but it displays nothing.
Cheers,
Cameron Simpson cs@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/
It's a vague science. - Rory Tate, circle researcher.
On 17Sep2009 18:19, devi devi@atc.tcs.com wrote: | On Thu, 2009-09-17 at 08:09 +1000, Cameron Simpson wrote: | > On 16Sep2009 19:43, devi devi@atc.tcs.com wrote: | > | On Wed, 2009-09-16 at 11:18 +0100, Dave Mitchell wrote: | > | > On Wed, Sep 16, 2009 at 03:06:09PM -0400, devi wrote: | > | > > The command | > | > > echo "service httpd status " > /dev/pts/1 is executed on one terminal, | > | > > let us assume it as t1. | > | > > The echo command is executed on t1 but the output(service httpd status" | > | > > is directed to /dev/pts/1 terminal. | > | > > | > | > > What I am saying is that the output is redirected directly to the | > | > > terminal /dev/pts1/1. | > | > > The output here is "service httpd status", which is generally a command. | > | > > And so it gets executed. | > | > | > | > No, the text just appears in the terminal associated with /dev/pts1/1; | > | > it does not not cause the command to be executed. That is to say, | > | > you can't use this as a mechanism to insert characters into a another | > | > terminal's input buffer. | > | > | > | But the command got executed, and it gave the status of apache | > | on /dev/pts/1 terminal. | > | > That's quite interesting. It should _not_ cause the command to be | > executed, and I really believe something more is going on. | > | > /dev/pts/1 is the "slave" side of the pseudoterminal; all pseudoterminals | > have a "master" side and a "slave" side. | | Here, the /dev/pts/1 is the tty of a virtual machine. This virtual | machine is created by xen. | Yes, I have come across master and slave pseudo terminals, but I have | not set any anything like that.
Ah, ok. I have not used such a setup. However, it looks like Xen arranges the master slave setup. What it presents is like a crossover terminal connection. /dev/pts/1 is cross wired to the temrinal inside the Xen VM; functionally it will behave like the "master" side of a pseudo tty. Internally it will really be a pseudoterminal, with Xen as the master, and Xen passes stuff through to the VM for you.
As, indeed, you have shown it does.
| I have done, what you suggested, it's the same. Anyways my requirement | is that, after the command is executed on /dev/pts/1, I should be able | to get the return value on the terminal "t1" | | eg: | rc=`echo "service httpd status" > /dev/pts/1" | I thought rc will hold the return value, but it displays nothing.
Ok.
I believe, based on your description, that reading from /dev/pts/1 will collect the output you want.
Try this:
tee -a output.log </dev/pts/1 >/dev/null & teepid=$! echo "service httpd status" >/dev/pts/1 sleep 5 kill $teepid
and then look at the file output.log.
Your `echo .... >/dev/pts/1` incantation did not contain the output because it collects the output of "echo" (specificly, any output not send elsewhere; your >/dev/pts/1 sends it elsewhere and so the output is empty).
Nothing was reading from the pty.
What my suggestion above does is start a "tee" command in the background to read from the pty and copy the data to the file output.log. Then we run your echo, to run the command on the VM. Then we wait a few seconds. Then we kill the "tee" command.
Commentry:
- a simpler command than the "tee" would be: cat /dev/pts/1 >output.log & however, "cat" (like almost all other programs) will be buffering its output for efficiency purposes, so it will never write to output.log before we kill it. "tee" does not buffer.
- the output recorded in output.log (if the above stuff works for you) will be the data stream sent to the terminal. That is, it will probably end lines with both CR and NL characters. Many rc files will emit coloured text in their output if on a terminal; your output.log file will contain the terminal escape sequences used to drive those colours. And so forth.
- you have no real indication of when the "service httpd status" command finishes, hence the dodgy "sleep 5" above.
You would be far better connecting to the VM with a remote command tool like ssh.
Cheers,