Linux端末エミュレータのテキストをShift +矢印キーで強調表示できないのはなぜですか？
これらは、ターミナルエミュレーター以外のLinuxアプリケーションで文字どおりテキストを編集するときに常に使用する標準のテキスト編集キーボードショートカットです。
- 左+右矢印で左+右に移動
- ctrl +矢印キーで単語全体を移動
- 行の開始/終了に移動するホーム/終了
- コピー/貼り付けするにはctrl + c/ctrl + v [一部の端末ではshift-ctrl-C/shift-ctrl-Vを使用できます。これは良い代替品です]
- shift +矢印でテキストをハイライト
- shift + Ctrl +矢印で単語全体をハイライト
このリストの最後の2つの項目を許可するシェルとターミナルエミュレーターの組み合わせを見つけたことはありません。明らかに、端末エミュレータは強調表示をサポートし（マウスはそれを行うことができます）、修飾子としてのCtrlキーとShiftキーの使用をサポートします（これらは、Word全体のカーソルの移動と文字の大文字化にそれぞれ使用できます。[編集：]それらを一緒に使用して、shift-ctrl-Cおよびshift-ctrl-Vでコピー/貼り付けすることもできます。この機能を妨げている問題は何ですか？いくつか質問があります。
- これは私のターミナルエミュレーターまたは私のシェル（bash、私は喜んで変更します）の問題ですか？
- ターミナルエミュレーター/シェルが、なぜこれ以外の普遍的な標準に準拠しないのですか？
- 実際の理由がある場合、それは古くて時代遅れですか、それともかなりの数のdesktop linuxユーザーに関連していますか？
- 何か回避策はありますか？
- これをサポートする私が使用できる不明瞭なプログラムはありますか？
- これをサポートするために、たとえばgnome-terminalのソースを変更することは可能ですか？
テキストはマウスでコピー/貼り付けできることを知っています。それは私が求めていることではありません。ターミナルエミュレーターのキーボードでこれらのことができない理由を尋ねています。
これを一度に一枚持っていけば一番便利だと思います。一般的な問題は次のとおりです：キーを押す対象は誰ですか？端末、または端末内で実行されているプログラム？
一例として、端末の一種である「画面」は、 Ctrl+A コマンドの接頭辞として、実行中のプログラム自体に向かうものと区別します。 （そして、送信する方法を提供します Ctrl+A。）
gnome-terminalには、さまざまなことを実行するためにキャプチャするキーがいくつかあります。
端末の「強調表示」は、端末のカーソル位置とは別であることにも注意してください。一部の端末には、まったく強調表示する機能がありません。
ここで、このキーの組み合わせを一度に取得します。
左+右矢印で左+右Ctrl +矢印でWord全体を移動/終了して行の先頭/末尾に移動
何を左右に動かしますか？ Bashはこれを行うように構成でき、通常はデフォルトです。通常、これらはカーソル位置を移動します。
コピー/貼り付けするにはctrl + c/ctrl + v
まず、コピー/貼り付けは意味がありますか？ VTにいる場合、特にXが実行されていない場合は、クリップボードはありません。
一部の端末は出力のテキストをコピーでき、一部はクリップボードの内容の入力をシミュレートして「貼り付け」ます。 Ctrl+Shift+Vたとえば、gnome-terminal、それが役立つかもしれません。 （そして Ctrl+Shift+C はコピーです。）前述のように、 Ctrl+C そして Ctrl+V 一般的な端末/プログラムコマンドと重複しています。 （Ctrl+C 送信割り込み（SIGINT）であり、 Ctrl+V 逐語的です。）
一部の端末は、データをコピーする2つのモードもサポートしています。より通常の「単なるコピー」と、「ブロック選択」または「ブロックコピー」と呼ばれるものです。 （ホールド Ctrl、次にgnome-terminal 例えば。）
さらに、xsel -bを使用して、クリップボードの内容をパイプすることができます。 xselと端末のバージョンのpasteのどちらがより役立つかは、正確な状況によって異なります。見る man xsel。
shift +矢印でテキストを強調表示Shift + Ctrl +矢印でWord全体を強調表示
端末のハイライト（この機能がある場合）は、カーソル位置とは異なります。繰り返しになりますが、利用可能なキーコンボの不足がおそらく要因です。ハイライトには開始位置と終了位置、または左上隅と右下隅の2つの位置があることに注意してください。両方をどのように管理しますか？
最後に、多くのGUI端末では、Wordをダブルクリックすると強調表示されることに注意してください。 （そしてXでは、1次選択にコピーします。）
例として、screenには、バッファ（前の出力）を移動してコピー/貼り付けするモードに切り替えるキーがあります。
xselと一次選択を適切に使用すると、クリップボード操作がまれであり、マウスを使用するのに十分なほど複雑であることがわかります。
Thanatosが述べたように、ターミナルエミュレータ（X WindowsまたはWaylandで実行）との間には違いがあります）端末内で実行されるプログラム（そうではないかもしれませんが、「シェル」と呼びましょう）;これら2つは互いに分離されています（ 技術的な詳細 を参照）。
リストの最初の項目（矢印キー、Home/Endなど）はターミナル内のプログラムによって直接処理されるため、カーソル位置端末内のプログラムによって制御されます。
一方、コピーと貼り付けのショートカット（Ctrl + Shift + CおよびCtrl + Shift + V）は、ターミナルエミュレーターによって処理されます。ターミナルエミュレーターは、マウスを理解します（したがって、マウスでテキストを選択できます）。画面上で（コピーできるように）、キープレスを内部のプログラムに送信できます（貼り付けることができます）。
Shift + LeftおよびShift + Rightをサポートするには、ターミナルエミュレーターまたはシェルのいずれかがキーストロークを処理する必要があります。どちらにしても問題があります：
- 最終的には選択したテキストをクリップボードにコピーする必要があるため、シェルはこれらのキーを簡単に処理できません。クリップボードはXウィンドウの概念であり、シェルは必ずしもアクセスできるわけではありません（ただし、
xclipを参照）。 ）。そして、私が知る限り、シェルがテキスト選択をサポートしている場合、Linuxは何が選択されているかをターミナルエミュレーターに通知するメカニズムを定義していません。 - その間、端末エミュレータはカーソルの位置を担当していません。端末エミュレータがカーソルの位置を変更できたとしても、現在のテキスト行がどこで始まりどこで終わるかは、おそらくわかりません。たとえば、端末には
~ $ ls -lのようなテキストが含まれていて、端末エミュレータはls -lの部分のみがユーザーに属していることを認識していません。
Shift +矢印での選択をサポートするターミナルエミュレーターを想像するのは難しくありませんが、シェルのカーソルを非表示にし、何かを選択するために一時的に存在する独自の「偽のカーソル」を導入し、Ctrlキーを押す必要があると思います+ C/Ctrl + Shift + C/Ctrl + Insでコピーし（またはEscでキャンセル）、実際のカーソルをもう一度表示します。もちろん、これは通常の選択のすべての機能を備えているわけではありません-特に切り取りと削除は存在しません。
答えは、なぜこれが難しいのかについての良い説明です。これはgnome-terminalでセットアップするためにできることです ctrl-c そして ctrl-v コピーアンドペーストするには、端末分野の他のキーをsttyで再バインドしてSIGINTを送信し、文字をそのまま挿入します。一部のプログラムは端末規則を無効にし、「^ C」および「^ V」を送信できないため、これは完全なソリューションではありません。詳細 ここ 。
シェルの起動スクリプト（例：~/.bashrc、~/.zshrc、~/.rcrc）、 行う
stty intr '^Q' 2>/dev/null # To send SIGINT I will use ctrl-q
stty lnext '^A' 2>/dev/null # To insert a character verbatim I will use ctrl-a
次に、gnome-terminalの[編集]> [設定]> [ショートカット]で、コピーと貼り付けをctrl-cとctrl-vにバインドできます。端末は、何かが端末デバイスに送信される前に主要なイベントを取得することに注意してください。そのため、それ以降は、端末で実行中のプロセスに「^ C」と「^ V」を送信できなくなります。
私はこれをやっただけで、それがどうなるのか、そしてそれがどのような問題を引き起こすのかがわかります。 Xを実行している場合にのみそれらを適用するように、条件付きでsttyを実行しました。
これらは、あなたが説明するCUAキーボードバインディングであり、80年代半ばのIBMの標準です。
https://en.wikipedia.org/wiki/IBM_Common_User_Access
それらは通常、それ以降に作成されたすべてのデスクトップ環境に実装されます。 DOS、Windows、Motif、さらにはNetwareツールでさえ、すべてこの標準に集中しています。 1つの例外はMacで、同じ期間から非常によく似ていますが異なるセット（CtrlではなくCmd）を使用します。
ただし、Unix端末はこの標準よりはるかに古いものであり、ほとんど無視されていました。また、これらのキーバインディングを実装している場合は、他の機能にすでにそれらを使用しているTUIプログラムに干渉する可能性があります。したがって、技術的には実行可能ですが、問題もあります。
アプリ：
microテキストエディターは、DOSテキストeditに似ていますが、GUIエディターをエミュレートするのに私が見た中で最高ですが、Sublime Textのような最新の機能を備えています。 neはDebianリポジトリの古いバージョンであり、nanoでも適切なキーバインディングで構成できます。しかし、裸の端末/シェル、いいえ。
libvteを使用すると、これらのキーバインドを自分で処理する初歩的な仮想端末を簡単に構築できます。ただし、わずかな利益のために多くの作業が必要です。
（編集：これらはWindowsのcmd端末キーです。Linuxを使用していることに気づきませんでした）
それが役立つ場合：
テキスト全体を使用してコピーできます Alt+Space、 E、 S、 Enter （1秒以下かかります）
そしてもちろん、VS Codeのようなまともなエディタを使用して、関連する部分をプルすることができます（数秒かかります）。
コピーしたテキストは、 Alt+Space、 E、 P。
そして、使用後に画面をスクロールすることができます Alt+Space、 E、 L。
元の質問に答えるには：
最初に、私はこの機能が存在する必要があることに完全に同意します。
現在の端末設計者がなぜそれを使用しないのかについて、タナトスは 彼の答え で言及しました。しかし、それを使用し、キーを必要とするシェルアプリの回避策を備えたターミナルアプリケーションが存在する場合があります。
古い端末設計者がそのような伝統を作成した理由（テキストの選択にキーを使用した場合、シェルアプリはそれらを使用しませんでした）については、ハードコピー端末がビデオ端末と最初のテキストエディターに取って代わられたためと思われます 出現しました 、テキスト選択のこの素晴らしいUIのアイデアが出るまでにまだ15年かかりました 存在するようになりました！ :)
私はこれと同様の問題を通じて仲間を助けただけで、クリップボードマネージャーのクリップが犯人であることがわかりました。
Sudo apt-getは、クリップを削除します
彼のためにすべてを正常に稼働させることができました。それが他の誰かを助けるかもしれないことを願っています。