1

.cファイルをコンパイルして実行中のリモートサーバーで実行し、自分のマシンに制御を戻す短い単純なスクリプトがありますtcsh（これは学校用です。プログラムがラボコンピューターで適切に動作する必要がありますが、それらを編集したいです）など）。この方法でコマンドを実行します。

ssh -T user@server << EOF
cd cs4400/$dest
gcc -o $efile $file
./$efile
EOF

これまでのところ問題なく動作しますが、これを行うたびに次の警告が表示されます。

Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.

これが技術的に問題ではないことはわかっていますが、非常に面倒です。私は学校の課題をやろうとしていて、自分のプログラムの出力などをチェックしていますが、これはすべてを混乱させ、嫌いです。

マシンでこのバージョンの ssh を実行しています。

OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012

サーバー上の tcsh のこのバージョン:

tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux)

そして、サーバー上のこのバージョンの ssh:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
4

3 に答える 3

1

OS X では、同様の問題 (Vagrant でのスクリプト プロビジョニング) を( 2 回来ることにssh -t -t注意してください) で解決しました。-tssh BSD man ページに基づくアドバイス:

-T 疑似端末割り当てを無効にします。

-t 疑似端末割り当てを強制します。これは、リモート マシン上で任意の画面ベースのプログラムを実行するために使用できます。これは、メニュー サービスを実装する場合などに非常に役立ちます。複数の -t オプションを指定すると、ssh にローカル tty がない場合でも、tty の割り当てが強制されます。

于 2016-02-28T11:37:49.733 に答える
1

メッセージは実際にはシェル (この場合は tcsh) によって出力されます。使用できます

strings  /usr/bin/tcsh | grep 'no access to tty'

それが自分のものであることを確認しtcshます。

これは ssh に非常に大まかに関連しています。つまりssh、この場合は原因ではなく単なるトリガーです。

アプローチを変更し、使用しないでくださいHERE DOCUMENT。代わりに、実行可能な custom_script を配置し/path/custom_scriptて、ssh 経由で実行します。

# this will work
ssh user@dest '/path/custom_script'

または、複雑なコマンドをワンライナーとして実行するだけです。

# this will work as well
ssh user@dest "cd cs4400/$dest;gcc -o $efile $file;./$efile"
于 2020-05-05T15:29:01.353 に答える