ご存知の方に質問です。
ターミナルを連続動作させる方法は有りますか。
具体的には、
ls パス1
ls パス2
ls パス3
...
とか
rm パス1
rm パス2
rm パス3
...
とかを
数十から数百行連続させる方法です。
本来は、スクリプトの仕事なのでしょうが、
私、スクリプト音痴で、
学習の手間暇と本人の誤記を避けたいので、
確実なコマンドの羅列を使用しています。
しかし、
なぜか、
行数が多いと、ターミナルの動作が不安定？です。
単独実行可能なコマンドが、ファイルやディレクトリは無いと言い出します。
ちなみに、
ファイルからの実行ではなく、クリップボードからターミナルへ
全行を複写してます。
コマンドのデリミターですが、
";"を付けてもだめでした。
え？改行の代わりにセミコロン（;）ですよね？
その方法だと、「間に割り込む」余地がないので、今までの理屈上は動作するはずなのですが。
ペースト元のテキストファイルに、何かゴミの制御コードが入っていませんか？
ターミナルから日本語ファイル名（フォルダ名）コピーして、エディタ上で整形して、、、等という方法を行うと、目に見えないゴミが入り込む可能性もある気がします。
試しにセミコロンの方法で前半だけとか後半だけとか半分ずつ試してみてください。
早速の応答ありがとうございます。
はい、
セミコロンです。
ただし、
文字データとしては、asciiで
0x3b,0x0aになってると思います。
エディター上では改行してますので、
209行になってます。
編集するときの設定は
UTF-8のLFにしてあります。
また、
ゴミを気にして新規の
英数文字列の記号空白無しのディレクトリ構造でも
試しましたが、
No such file or directory
が出ます。
多少はましな状態にはなるので、
全くの無効ではないようです。
位置的には、
ls行の24〜25行目の
表示行の89行以降になるので、
小分けは結構細かくなるかと。
実際、
100行前後で分けると、
前
正常
後
No such...有り
です。
はい、
セミコロンです。
ただし、
文字データとしては、asciiで
0x3b,0x0aになってると思います。
エディター上では改行してますので、
って、改行(LF)の『代わりに』セミコロンじゃなくて改行の前にセミコロンになってるじゃないですか。
それだと、デリミタが0x3b+0x0aです。0x0aは不要です。0x3bのみをデリミタにして試してください。
100行前後で分けると、
前
正常
後
No such...有り
です。
それなら、後半の行に正常に動作しない行が含まれるということでは？
後半をさらに半分に、エラーの出る方をさらに半分に・・・ としていき、正常に動作しない行を特定すればいいのではないかと思います。
# というか、アウトプットを確認したら、どの行からおかしくなっているか特定できませんか？
まさか、209行分の連続一行ですか、
と言うよりも、
期待する形じゃなくなるので試してませんでした。
結果は
当然のように、正常です。
結果の見た目は、
ファイルからの入力と同じ。
つまり、
bashから見た入力元は同じという、
コンソールもファイルと同じという
聞いたことあるような話です。
従って、
bashは誤動作してない、
ということになります。
しかしながら、
操作上の見た目と出力結果の見た目が、
期待する形にならない
入力行の確認ができない
入出力行の対比ができない
ので、
ファイルできっちり記述する以外はないですね。
ところが、
これがまた微妙で...。
入力行を
100行前後に減らしても
問題の現象は発生します。
が、
出たり出なかったりで。
同じ物を繰り返して
入力しても、
決まった場所に出ません。
傾向はあるようにも見えますが...。
ディレクトリ名は、
適当な（任意の？）可読アスキー文字列で
新規に作成したディレクトリ構造なので、
特定文字の影響は無いのを期待するのですが...。
それとも、文字数か？？？。
問題の現象は、
エコーバックの表示がおかしくなった後に
発生し、
正常に動作していても、
エコーバックからプロンプトが抜け落ちていたり
します。
セミコロンでの結果を受けて、
ターミナルとシェルとの間か
ターミナルに問題があるのだと思います。
直接張り付けるためには、
待ち時間を入れる方法を見つけないと
いけないということでしょうか。
>問題の現象は、
>エコーバックの表示がおかしくなった後に
>発生し、
エコーバックがおかしいということは、入力文字列が長過ぎるのでは？
入力用のバッファーがあると思いますので、極端に長い文字列では動作しないこともあると思います。コピー＆ペーストで入力しているということだと、関係するバッファーもいろいろなところにあるでしょうから、どのバッファーの問題かも分かりません。
HALさんじゃないけど、あまり極端なことは想定されてないとする方がいいのでは？改行が200以上もあるということだと、1行50 bytesとしても10 kbytes にもなります。入力バッファーというのはそんなに用意されてないことも多いと思います。
極端なことをやろうとして出来なくてバグだ、と言われても、、、
しかし、スクリプトをファイル化することがどうして嫌なんでしょう？
自分などは、ファイルにして残しておけば、以前にやったことも間違いなく再現できるので、むしろ何でもスクリプトにしておきますけど。
当方でも344バイトの同一行を６行くりかえすと再現しました。
１行のサイズを減らすと耐えられる総文字数が多くなるようです。
気になったので他のシェルでも試してみました。以下まとめ
| シェル | 動作 |
|---|---|
| bash | 異常 |
| sh(bash) | 異常 |
| tcsh | 正常 |
| csh(tcsh) | 正常 |
| zsh | 正常 |
| ksh | 正常 |
※()は実際の動作シェル
ターミナル上でのペーストによる作業をお望みなら他のシェルを試してみてはいかがでしょうか。
ご指摘ありがとうございます。
バイト数については、
気にしてませんでした。
全体では20K弱です。
そう言われれば大きいかな...。
入力バッファが小さくても、
OSが補っていると期待しています。
しかし、誤動作が起きているのは事実で、
それを何と表現するかは、重要に感じません。
仕様なら制限事項がどうなっているのかを知りたいだけで、
やっちゃいけないことをやりたくないだけです。
なので、
誤動作をやらかしてルートで（！）リムーブですから、
安全策でファイル化をぼちぼちしてます。
エコーバックで結果を見るのは安直だったのに...。
といっても
Linux音痴はすぐに解決しないので、
試行錯誤と求める結果との積で、
ファイルの数かファイルの行数はどんどんふくれます。
何が良くて何が悪かったか分からなくなりそうで、
またしくじるのが恐ろしい。
ありがとうございます。
私も試そうかと思いましたが、
shとcshぐらいしか思いつかないし、
それに、
訳分からなくなりそうなので止めました。
この結果を受けて、
他のシェルを使ってみたいと思います。
どうしても
直接張り付けで
実行結果を見てみたい時があって...。
それに、
文字数は、1行100バイト以上がざらなので。
実行結果を得たいなら、ターミナルにたよるのはますます不適です。
コマンド > ファイル名
とコマンドの後ろに「大なり不等号」その後ろにファイル名指定で結果をテキストに流し込めます。
任意のファイルに追加したいときは
コマンド >>ファイル名
です。
詳しくは「リダイレクト」で検索を
実行結果を得たいなら、ターミナルはますます不適です。
コマンド > ファイル名
とコマンドの後ろに「大なり不等号」その後ろにファイル名指定で結果をテキストに流し込めます。
任意のファイルに追加したいときは
コマンド >>ファイル名
です。
詳しくは「リダイレクト」で検索を
リダイレクトまで言及いただき
たいへんに恐縮です。
今回の敗因は、
OSXへの期待と過信があったからですが、
こんな落とし穴もあるという、
貴重な経験にもなりました。
リダイレクトは、
きっちり書かないと期待した内容が
ファイルに反映しないとか、
動いてる状態が見えないとか、
ありますので、
良い教材としてシェルの理解につなげたいと思います。
ターミナルの誤動作
