Você está perdendo o fato de que a chamada para o gvim não bloqueia até que você saia do gvim, ele retorna imediatamente. Então, o xsel < /tmp/xselection está processando o arquivo antes de editá-lo.
Estou tentando usar o seguinte script:
#!/usr/bin/env bash
# Edit xselection in gvim
xsel > /tmp/xselection
gvim /tmp/xselection
xsel < /tmp/xselection
Mas a linha final não parece estar carregando corretamente o arquivo no xselection. Se eu executar essa linha imediatamente após chamar o script, ele será bem-sucedido. Eu não entendo porque. O que estou perdendo?
Acabei incorporando informações das duas / todas as três respostas para gerar o seguinte:
#!/usr/bin/env bash
# Edit xselection in gvim
xsel > /tmp/xselection
gvim -f /tmp/xselection
xsel -i < /tmp/xselection
Você precisa usar a opção -i . ( -o é o padrão)
xsel -i </tmp/xselection
# -o, --output write the selection to standard output.
# -i, --input read standard input into the selection.*
Estes optons funcionam na seleção X primária (não na área de transferência), então você precisa clicar com o botão central para ver o resultado. Eu testei com uma pausa antes do comando final. Isso me permitiu selecionar manualmente algum outro texto antes do comando final ser executado. O eu clicou no centro e funcionou bem ... e funciona sem o atraso.
No entanto, testá-lo sem o atraso não prova muito, porque a seleção original ainda está selecionada ... e, claro, se você selecionar outra coisa nesse meio tempo, perderá a seleção principal do script.
Talvez seu problema seja uma combinação da opção -i e da resposta de Paul Tomblin sobre a maneira como o gvim se destaca do processo de script.
Minha resposta anterior estava ficando um pouco lotada e estava incompleta (e tinha apenas uma iteração de edição). Então, aqui está uma resposta emendada que inclui as duas idéias ... opções e desanexando .
Como eu mencionei em um comentarista de acompanhamento ao comentário de Giles (resposta anterior), a opção -i é definitivamente necessária em algumas situações (no sistema Ubuntu de teste) .. então -i e -o são usados aqui.
Como o 'gvim' se destaca do processo do script, ele não espera, e o próximo comando é executado imediatamente. (Paul Tomblin já apontou isso em sua resposta).
Você não pode usar o comando wait do bash, pois ele só funciona para processos filho . Como solução alternativa, você pode configurar um loop que aguarda o término do processo não-filho . Isso funciona para um editor que começa com um novo processo a cada vez (como 'gvim' faz neste caso).
Aqui está o script modificado
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
O acima assume que gvim 'pid já está estabelecido pelo controle de tempo que é passado de volta para o script. Se, sob uma alta carga do sistema, o pid não foi estabelecido ao executar o próximo comando, então este método de espera pelo gvim deve funcionar.
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