[Q] Terminal Server
Takahide Nojima
UNIXで動作する文字端末サーバ（と言えば良いのでしょうか？）を探しています。
これはXのように
[1] 文字端末側がサーバで、
[2] クライアント側がアプリケーションという関係
であるものを探しています。(Screenの逆を行くとでも言えばよいでしょうか？）
理想を言えば、[2]のアプリケーションが起動すると、勝手に[1]の端末ソフトの
画面がsplitしてくれたり、接続して良いかのプロンプトが出る等が良いなぁ
と思っています。
いろいろ検索してみましたが、全部[1][2]とは逆のパターン（アプリケーション側
がサーバで、クライアントが端末ソフト）のものばかりでした。
何か情報をおもちの方はいらっしゃいますでしょうか？
maeda...@ialab.is.tsukuba.ac.jp
> 理想を言えば、[2]のアプリケーションが起動すると、勝手に[1]の端末ソフトの
> 画面がsplitしてくれたり、接続して良いかのプロンプトが出る等が良いなぁ
> と思っています。
アプリケーションappを起動する際に，
app
のかわりに
screen -X split
screen -X focus
screen -X screen app
とすれば，画面をsplitしてappが起動します．
接続して良いかどうか尋ねるというのも，ちょっとしたシェルスクリプトを書
けばできるんじゃないでしょうか．
前田敦司
Takahide Nojima
maeda...@ialab.is.tsukuba.ac.jp writes:
> > 理想を言えば、[2]のアプリケーションが起動すると、勝手に[1]の端末ソフトの
> > 画面がsplitしてくれたり、接続して良いかのプロンプトが出る等が良いなぁ
> > と思っています。
>
> アプリケーションappを起動する際に，
> app
> のかわりに
> screen -X split
> screen -X focus
> screen -X screen app
> とすれば，画面をsplitしてappが起動します．
>
> 接続して良いかどうか尋ねるというのも，ちょっとしたシェルスクリプトを書
> けばできるんじゃないでしょうか．
すみません。次のような使い方を想定しています。
[用途] 仕様上どうしても人樣のプログラム（しかもブラックボックス）により
起動させられるプログラムAのデバッグを楽勝で行いたい。ただ、この
プログラムAは、
・起動させるプログラムの関係上どうしてもバックグラウンドプロセスに
移行して実行してしまうし、
・インタプリタ系の言語で出来ている
という状況です。
[自分が想像している使い方]
1) 文字端末サーバをtelnet上で立ち上げ待ち受け状態にする。
2) 文字端末クライアントの改造を施したインタプリタ系の言語のデバッガ
を用意。これがバックグラウンドプロセスで起動する。
（perl -d:tkdbのイメージです）
3) 1)に2)のプロセスから接続が行われ、デバッガの画面が1)の端末上に現れる。
（まるでX端末にリモートのアプリから接続が行われてGUIが出現するような
感覚です）
[補足]
もちろんscreen使えば、screen経由で適当にセッション名定めてスクリプト言語の
デバッガを起動し、telnet端末からscreenコマンドでattachすれば似たようなことは
実現できます。しかし、ここで面倒なのは、
a.attachする為のセッション名をデバッグ作業の時に定める必要がある。
(Xの様にDISPLAY=ホスト名:0とかしておけば何とかなる方が楽で良い）
b.attachする際にいちいちps とってどのプロセス番号かを調べる必要がある。
c.attachして終了させるか、killしないとプロセスにscreenがattachされるのを
待って居座りつづけてしまう
など使い勝手が今一なのです。1)の文字端末サーバが上っていなければ
c.の状態にはならないとかだとさらに安全で良いなあと思っています。
Takahide Nojima
Takahide Nojima <noj...@taito.co.jp> writes:
> [用途] 仕様上どうしても人樣のプログラム（しかもブラックボックス）により
> 起動させられるプログラムAのデバッグを楽勝で行いたい。ただ、この
> プログラムAは、
>
> ・起動させるプログラムの関係上どうしてもバックグラウンドプロセスに
> 移行して実行してしまうし、
>
> ・インタプリタ系の言語で出来ている
>
> という状況です。
もちろん本来、このようにデバッグ為難い環境ではプログラム自身それなりの設計に
しておく等の話もあるのですが、上の引用の機構が可能であれば、素人さんも楽勝で
バックグラウンドプロセスに移行するようなプログラムとかを作れるんで良いなあと
思った次第です。
＃あと、自分もいざとなれば楽できるし...
Hideo Sir MaNMOS Morishita
In article <3988774...@insigna.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> ちなみに知らなかったんだけど、gdb って、既に起動してある
> プログラムもデバッグできるんだよね。おそるべし。
私がマニュアルを翻訳した時点(4.09)ではありましたので、10年以上前からで
すね。
ちなみに、SunONEStudioのdbxもできます。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
maeda...@ialab.is.tsukuba.ac.jp
> 1) 文字端末サーバをtelnet上で立ち上げ待ち受け状態にする。
>
> 2) 文字端末クライアントの改造を施したインタプリタ系の言語のデバッガ
> を用意。これがバックグラウンドプロセスで起動する。
> （perl -d:tkdbのイメージです）
>
> 3) 1)に2)のプロセスから接続が行われ、デバッガの画面が1)の端末上に現れる。
>
> （まるでX端末にリモートのアプリから接続が行われてGUIが出現するような
> 感覚です）
screen -X (起動済みのscreen画面へ外部からコマンドを送る機能) を使うと，
同じようなことができると思うのですが…(いつから入った機能か知りません．
3.09.04には無い機能ですが，3.09.09にはあります．)
セッション名も(screen画面をたくさん立ち上げているとかでなければ) 与え
なくて良いし．与えたければSTY環境変数で与えておけば良いし．
たとえば，下につけるようなシェルスクリプトを使うと，
(1) screenを(telnetでもなんでも文字端末上で)立ち上げ待ち受け状態にする．
(2) on-screen command args... を(バックグラウンドでも何でも)実行すると，
(3) (1)に(2)のプロセスから接続が行なわれ，command の画面が(1)の端末上
に現れる．
わけですが，どのへんが不足なのでしょう?
> a.attachする為のセッション名をデバッグ作業の時に定める必要がある。
> (Xの様にDISPLAY=ホスト名:0とかしておけば何とかなる方が楽で良い）
>
> b.attachする際にいちいちps とってどのプロセス番号かを調べる必要がある。
>
> c.attachして終了させるか、killしないとプロセスにscreenがattachされるのを
> 待って居座りつづけてしまう
>
> など使い勝手が今一なのです。1)の文字端末サーバが上っていなければ
> c.の状態にはならないとかだとさらに安全で良いなあと思っています。
これは screen -r で再attachする場合の話でしょうか．たくさんscreenを立
ち上げていなければ，セッション名やプロセス番号は指定しなくてもかまわな
いと思うんですが．
===
以下の，on-screenとon-screen-doitという2つのスクリプトをPATH中に置いて
おけば，前述したような使い方ができます．
使用例:
$ nohup on-screen w3m http://www.yahoo.co.jp/ &
(バックグラウンドで起動されるコマンドからw3mブラウザを起動し，起動済み
のscreen画面で表示/制御する．)
$ STY=1234.myhost.pts-1; export STY
$ on-screen emacs
(複数のscreenが立ち上がっている時，片方を選んでon-screenでemacsを表示．)
screen画面の中からもon-screenコマンドは使えます．
==> on-screen <==
#!/bin/sh
screen -X split
screen -X focus
screen -X screen on-screen-doit "$@"
==> on-screen-doit <==
#!/bin/sh
case "$1"
in
-i|--ask)
shift
echo -n "Execute '$@' ([y]/n)?"
read ans garbage
case "$ans"
in
n|N|[nN][oO])
screen -X remove
exit 1 ;;
esac
;;
esac
"$@"
screen -X remove
exit 0
===
前田敦司
tesi...@mtf.biglobe.ne.jp
> [用途] 仕様上どうしても人樣のプログラム（しかもブラックボックス）により
> 起動させられるプログラムAのデバッグを楽勝で行いたい。ただ、この
mv A /somewhere/A.org
とか改名して、
#!/bin/sh
xterm -e debugger /somewhere/A.org
と言うスクリプトを A と名乗ったらどうでしょう。
---------------------------------------------------------------------
tesi...@mtf.biglobe.ne.jp
Takahide Nojima
maeda...@ialab.is.tsukuba.ac.jp writes:
> screen -X (起動済みのscreen画面へ外部からコマンドを送る機能) を使うと，
> 同じようなことができると思うのですが…(いつから入った機能か知りません．
> 3.09.04には無い機能ですが，3.09.09にはあります．)
>
> セッション名も(screen画面をたくさん立ち上げているとかでなければ) 与え
> なくて良いし．与えたければSTY環境変数で与えておけば良いし．
>
> たとえば，下につけるようなシェルスクリプトを使うと，
>
> (1) screenを(telnetでもなんでも文字端末上で)立ち上げ待ち受け状態にする．
> (2) on-screen command args... を(バックグラウンドでも何でも)実行すると，
> (3) (1)に(2)のプロセスから接続が行なわれ，command の画面が(1)の端末上
> に現れる．
>
> わけですが，どのへんが不足なのでしょう?
す、すみません。screen -X では接続を待ち受けしている(1)の側のscreenの方が
デバッガプロセスを起動してしまうように思いますが違いますでしょうか？
（See. screen-3.9.13 screen.c main関数中if(cmdflag)～exit(0)まで）
つまり(3)は、
(3) (1)に(2)のプロセスから接続が行われてcommand args...を(1)のプロセス
から実行しなさいと命令され、(1)がcommand args...を自ら実行して
端末に見せる。
となるような...
自分が望んでいるのは、バックグラウンド側で起動されたデバッガプロセスの端末が、
待ちうけしているscreenへ現れるのが欲しいです。
＃でもこれが出来るのはscreenのdetach/attach機能。でも、これだと
＃元投稿の
＃Message-ID: <m3r83w7...@nightmare.hm.taito.co.jp>
＃の[補足]で書いたことが起きてdettach/attachの操作が面倒臭いような...
＃なんとか、スクリプトのデバッガ側に接続機構をこっそり混ぜて、素人さんに使わせ
＃たいなーと...
MAEDA Atusi
> す、すみません。screen -X では接続を待ち受けしている(1)の側のscreenの方が
> デバッガプロセスを起動してしまうように思いますが違いますでしょうか？
おっしゃるとおりです．
> 自分が望んでいるのは、バックグラウンド側で起動されたデバッガプロセスの端末が、
> 待ちうけしているscreenへ現れるのが欲しいです。
たしかに，
「親プロセスが直接デバッガプロセスを起動」
のかわりに，
「親プロセスから指示を受けて(1)のscreenがデバッガプロセスを起動」
になりますけど，それで何がまずいのかが分からないんです．
デバッガが親の環境変数を引き継ぐ必要があるとか?
デバッガの終了を親が待ち合わせて終了ステータスを取る必要があるとか?
いずれも，シェルスクリプトを少し改造すればできますよね．
デバッガが親のファイルディスクリプタを引き継ぐ…のはどうせ無理ですよね．
新たに端末を割り当てるんだから．
次に，attach/detachを使う場合の話しですが，
In <m3r83w7...@nightmare.hm.taito.co.jp>:
> a.attachする為のセッション名をデバッグ作業の時に定める必要がある。
> (Xの様にDISPLAY=ホスト名:0とかしておけば何とかなる方が楽で良い）
>
> b.attachする際にいちいちps とってどのプロセス番号かを調べる必要がある。
えっと，単にscreen -rとかscreen -drとか入力すれば，screenが1つしかなけ
ればそれがattach されるし，2つ以上あればそのセッションの一覧が表示され
ますから，自分で「いちいちps とってどのプロセス番号かを調べる必要」は
ないですよね．
> c.attachして終了させるか、killしないとプロセスにscreenがattachされるのを
> 待って居座りつづけてしまう
screen内で動いているプロセスが終了すれば，勝手にscreenも消えますけど…
前田敦司
Takahide Nojima
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> > バックグラウンド側で起動されたデバッガプロセスの端末が、
> > 待ちうけしているscreenへ現れるのが欲しいです。
>
> たしかに，
> 「親プロセスが直接デバッガプロセスを起動」
> のかわりに，
> 「親プロセスから指示を受けて(1)のscreenがデバッガプロセスを起動」
> になりますけど，それで何がまずいのかが分からないんです．
> デバッガが親の環境変数を引き継ぐ必要があるとか?
その通りです。他にも、
・親が指定してくる引数パラメータの内容、
・親がパイプ経由(STDIN)で送ってくるデータの内容、
・親が実行するカレントディレクトリ
も全部親が実際に起動する時のままにしたいのです。これらを調べあげて
全部シェルスクリプトでエミュレートとかは避けたいです。
> デバッガの終了を親が待ち合わせて終了ステータスを取る必要があるとか?
これは無いです。
> 次に，attach/detachを使う場合の話しですが，
>
> In <m3r83w7...@nightmare.hm.taito.co.jp>:
> > a.attachする為のセッション名をデバッグ作業の時に定める必要がある。
> > (Xの様にDISPLAY=ホスト名:0とかしておけば何とかなる方が楽で良い）
> >
> > b.attachする際にいちいちps とってどのプロセス番号かを調べる必要がある。
>
> えっと，単にscreen -rとかscreen -drとか入力すれば，screenが1つしかなけ
> ればそれがattach されるし，2つ以上あればそのセッションの一覧が表示され
> ますから，自分で「いちいちps とってどのプロセス番号かを調べる必要」は
> ないですよね．
そうですね。
> > c.attachして終了させるか、killしないとプロセスにscreenがattachされるのを
> > 待って居座りつづけてしまう
>
> screen内で動いているプロセスが終了すれば，勝手にscreenも消えますけど…
デバッガですので入力から'quit'とか打込まれるまで待ってしまいます。
Takahide Nojima
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> お、そういう用途か。でしたら、
>
> > 2) 文字端末クライアントの改造を施したインタプリタ系の言語のデバッガ
> > を用意。これがバックグラウンドプロセスで起動する。
>
> こいつの入出力を既にある端末のttyに投げてやれば良いんですね。
> xterm だったら、tty とかすると /dev/ttyp2 とかでるんで、そこ
> に書いてやれば Ok 。それがいやなら、入出力をコピーするコマン
> ドを書いて xterm で起動してやると良いです。というのが、
上の引用に近いことを実現する方法で、後に人から教わったのですが、netcat使って
Reverse Telnet
http://www.onlamp.com/pub/a/onlamp/2003/05/29/netcat.html
という大技があるとのことでした。早速実験しました。
端末A: nc -vv -l -p 8080
で待機します。次に-DGAPING_SECURITY_HOLE済みのnc持ってきて、
端末B: nc 127.0.0.1 8080 -e /bin/bash
（もちろんbashの代りにデバッガ動かすわけですが...）
すると、確かに求めている動作はいけそうです...あとは
・セキリュティの問題と、
・ポートを何かでくるんでユーザに判りやすくする方法
を考えつかないと＞自分
Takahide Nojima
Takahide Nojima <noj...@taito.co.jp> writes:
> 上の引用に近いことを実現する方法で、後に人から教わったのですが、netcat使って
>
> Reverse Telnet
> http://www.onlamp.com/pub/a/onlamp/2003/05/29/netcat.html
>
> という大技があるとのことでした。早速実験しました。
>
> 端末A: nc -vv -l -p 8080
>
> で待機します。次に-DGAPING_SECURITY_HOLE済みのnc持ってきて、
>
> 端末B: nc 127.0.0.1 8080 -e /bin/bash
> （もちろんbashの代りにデバッガ動かすわけですが...）
>
> すると、確かに求めている動作はいけそうです...あとは
>
> ・セキリュティの問題と、
>
> ・ポートを何かでくるんでユーザに判りやすくする方法
>
> を考えつかないと＞自分
と今度はデバッガを起動したらデバッガ自身が端末Bの端末を自分でオープンして
しまう様でそのままでは上手くいきませんでした。残念。
MAEDA Atusi
> > デバッガが親の環境変数を引き継ぐ必要があるとか?
>
> その通りです。他にも、
>
> ・親が指定してくる引数パラメータの内容、
>
> ・親がパイプ経由(STDIN)で送ってくるデータの内容、
>
> ・親が実行するカレントディレクトリ
>
> も全部親が実際に起動する時のままにしたいのです。これらを調べあげて
> 全部シェルスクリプトでエミュレートとかは避けたいです。
なるほど．じゃあ，こういうのはどうですか．
1. 待ち受け側のscreenをあらかじめ立ち上げておく(スクリプトかaliasで，
screen -S parent
とセッション名をつけておく．)
2. バックグラウンドのデバッガは
screen -m -d -S child command args...
として呼び出す．(Detached状態で立ち上げる．)
3. parentの画面をsplitし，その1つで
screen -r -m -S child
を実行して，childをattachする．
2と3については，先のon-screen, on-screen-doitスクリプトを少々変えると
できます．こんな感じ．
==> on-screen <==
#!/bin/sh
screen -S parent -X split
screen -S parent -X focus
screen -m -d -S child on-screen-doit "$@"
sleep 2
screen -S parent -X screen screen -m -r -S child
==> on-screen-doit <==
#!/bin/sh
case "$1"
in
-i|--ask)
shift
echo -n "Execute '$@' ([y]/n)?"
read ans garbage
case "$ans"
in
n|N|[nN][oO])
screen -S parent -X remove
exit 1 ;;
esac
;;
esac
"$@"
screen -S parent -X remove
exit 0
あとは，2の前に「parentが上がっていなければデバッガを起動せず，スクリ
プトをそのまま実行」というチェックを入れれば良いのでは．
前田敦司
Takahide Nojima
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> あとは，2の前に「parentが上がっていなければデバッガを起動せず，スクリ
> プトをそのまま実行」というチェックを入れれば良いのでは．
なるほどです。たしかにそうですね。
＃セッション名使って検出ファイルでも作ってフラグ代りにします。
maeda...@ialab.is.tsukuba.ac.jp
安直には，
==> on-screen <==
#!/bin/sh
if screen -S parent -X split >/dev/null 2>&1
then
screen -S parent -X focus
screen -m -d -S child on-screen-doit "$@"
sleep 2
screen -S parent -X screen screen -m -r -S child
else
exec "$@"
fi
で良さそうです．
前田敦司
Takahide Nojima
maeda...@ialab.is.tsukuba.ac.jp writes:
> > なるほどです。たしかにそうですね。
> >
> > ＃セッション名使って検出ファイルでも作ってフラグ代りにします。
>
> 安直には，
> ==> on-screen <==
> #!/bin/sh
>
> if screen -S parent -X split >/dev/null 2>&1
> then
...中略...
> exec "$@"
> fi
>
> で良さそうです．
ありがとうございました。参考にさせていただきます。
Takahide Nojima
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
...中略...
> > 2) 文字端末クライアントの改造を施したインタプリタ系の言語のデバッガ
> > を用意。これがバックグラウンドプロセスで起動する。
>
> こいつの入出力を既にある端末のttyに投げてやれば良いんですね。
> xterm だったら、tty とかすると /dev/ttyp2 とかでるんで、そこ
> に書いてやれば Ok 。それがいやなら、入出力をコピーするコマン
> ドを書いて xterm で起動してやると良いです。
>
perlなんかだと、
[1] 端末A(ttyは例えば/dev/pts/0)を用意し、
(/dev/pts/0なんかのパーミッションは適当にしてください）
[2] 端末A上でシェルの標準入出力を潰すため、
sleep 100000
とかをforground processで起動して待ちうけ状態にし、
[3] debug対象のperlスクリプト(foo.pl)が
env PERLDB_OPTIONS='TTY=/dev/pts/0' perl -d foo.pl
とかの状態でバックグラウンドで起動するようにする
と端末Aにいきなりdebuggerが出現してそのままdebug出来るんですね。
最近知りましたです...はい。