xsel < /tmp/xselection このスクリプトでは機能しません。

私はgvimを終了するまでgvim呼び出しがブロックされず、すぐに返されることを無視しています。したがって、xsel < /tmp/xselectionファイルは編集前に処理されます。

最後に、2つ/3つの回答の情報をマージして次のように生成しました。

#!/usr/bin/env bash
# Edit xselection in gvim

xsel > /tmp/xselection
gvim -f /tmp/xselection
xsel -i < /tmp/xselection

このオプションを使用する必要があります-i。 （-oデフォルトです）

xsel -i </tmp/xselection
# -o, --output   write the selection to standard output.  
# -i, --input   read standard input into the selection.*

このオプションは X で使用できます。基本的な選択肢（クリップボードではない）なので、結果を表示するには中央ボタンをクリックする必要があります。私はそれをテストするために最後のコマンドの前にしばらく停止しました。これにより、最終コマンドを実行する前にいくつかの追加テキストを手動で選択できます。中央をクリックしましたが、うまくいきました...遅れもありませんでした。

しかし、遅滞なくテストしても元の選択がそのまま選択されているので何も証明されません...もちろん同時に他のものを選択するとスクリプトのデフォルト選択を失うことになります。

おそらくあなたの質問は、-iこれら2つのオプションとスクリプトプロセスから分離する方法に対するPaul Tomblinの答えの組み合わせです。gvim

私の以前の答えは少し混雑して不完全になっています（そして編集の繰り返しは一度だけ残りました）。したがって、ここにこれら2つのアイデアの両方を含む修正された答えがあります。オプションそして分離。

Gilesのコメント（以前の回答）に対するフォローアップで述べたように、-iそのオプションが必要な場合（テストUbuntuシステムで）は明らかです。したがって、ここではと -i。-o

"gvim"はスクリプトプロセスから切り離されているので、待たずにすぐに次のコマンドを実行します。 （Paul Tomblinはすでに彼の答えでこれを指摘しています）。

waitbash コマンドは以下でのみ動作するため使用できません。サブプロセス。回避策として待機するループを設定できます。子供ではないプロセスが終了します。これは毎回新しいプロセスで始まるエディタに適用されます（例：この例では「gvim」）。

修正されたスクリプトです

xsel -o >/tmp/xselection

gvim /tmp/xselection 2>/dev/null
pid=$(pgrep -n "gvim")  # get gvim's pid and wait
while kill -0 "$pid" 2>/dev/null; do sleep 0.5; done

xsel -i </tmp/xselection

上記は、制御がスクリプトに戻されたときにgvim`pidがすでに設定されていると仮定しています。高いシステム負荷で次のコマンドが実行されたときにpidがまだ設定されていない場合は、gvimを待つこの方法が機能します。

xsel -o >/tmp/xselection

pre=$(pgrep -n gvim)    # get previous gvim pid
gvim /tmp/xselection 2>/dev/null
while pid=$(pgrep -n "gvim"); [[ "$pid" == "$pre" ]]; do sleep .1; done
while kill -0 "$pid" 2>/dev/null; do sleep 0.5; done

xsel -i </tmp/xselection