Shell Programming and Scripting

Corona, methyl & citaylor Thank you very much.

@Crona:
Now I got what you mean and thanks for this valuable information.
So, I need some programming but between "expect" and "C Programming" I will choose the second one

@methyl:
You told that "CRT terminals in the 1980s were capable of repeating the screen output".
Could you please give me some more info about How they did that "repeating"?

@citaylor:
Yes, your answer was complicated but at last I figured it out
And many thanks for that "pseudoterminal (pty)" hint, I read the code before but I didn't get that ponit.

---------- Post updated at 11:06 AM ---------- Previous update was at 10:57 AM ----------

P.S: I'm going to build a simple remote system manager which will acts as a remote desktop but in text-mode. The difference is: Administrator from a single screen can connects, monitor and interact with N (>100) machines simultaneously.
So, It would not be a keylogger, password cracker or virus!!!

There is a version of Expect for Perl too if you are more familar with that...

Have you investigated the command "screen" at all ? Might give you some ideas...

Good luck

yes, a little. but I will check it again if you think that would be helpful...

One example of many was the DEC VT102 VDU Video Display Terminal Information ? VT100.net. It had a serial cable to the computer (or modem) and a serial output port for a printer. It was possible to pass control codes to the terminal to cause data to go to the printer or the screen or both. The feature is known as "passthru" and still exists in some modern terminal emulators. Most modern terminal emulators actually emulate the DEC vt220 which has a similar keyboard layout to a modern PC keyboard.

Attachmate Reflections unix terminal emulator includes a feature to log screen output to a file. The product also includes a keyboard scripting language where you can do "one button" full sessions.

Nothing bad happens with trivial examples.

Code:

$ cat /usr/share/dict/cracklib-small > /dev/tty
10th
1st
2nd
3rd
4th
...
zoroaster
zounds
z's
zucchini
zurich
zygote
$ read VAR < /dev/tty
asdf
$ echo $VAR
asdf
$cat < /dev/tty
asdf
asdf
qwertyuiop
qwertyuiop
^D
$

And almost nothing bad happens with non-trivial examples:

Code:

$ cat /lib/libc.so.6 > /dev/tty
<unending pages of garbage>
$ 6;92;c^C
$ nano > /dev/tty < /dev/tty 2> /dev/tty
(normal nano behavior)
$

Which makes sense when you think about it. (nearly) any program run by the shell runs gets direct read/write access to the terminal from the get-go anyway -- if your program gets access to the terminal at all, the shell can't intermediate how you talk with it. Programs deal with the terminal direct. Reopening the terminal device isn't really different from the access you'd get from the first.

Now if that program started altering terminal settings out from under the shell that might be a different matter -- except the shell also runs programs that alter terminal settings all the time: Interactive editors, less, top, and others. The shell's expected to not go weird when running these. As long as they politely leave the terminal as they found it when they're done, nothing explodes. Even when they don't, reset\n is usually enough to put things where they belong.

In many shells, it's actually switching terminal modes by itself all the time -- putting the terminal into canonical mode whenever you run something, and switching back to non in order to process raw keystrokes. Any shell that lets you edit the commandline in a vi or emacs like fashion does this.

Finally:

Code:

$ ssh some.server.or.other > /dev/null 2> /dev/null < /dev/null
Password:

It's able to prompt me for a password with no open references to the terminal at all! When I strace it and grep for /dev/tty, it finds this:

Code:

open("/dev/tty", O_RDWR)                = 5

So ssh is quite prepared to go to the source when no other means is available.

(on further checking: In fact it seems to do so even when other means are available.)