Para manter minhas configurações sãs entre os ambientes, achei uma ótima ideia fazer o seguinte no MacOS.
ln -s /usr/bin/pbcopy /usr/local/bin/xclip
No entanto, meu xclip
link simbólico não age exatamente como pbcopy
. Em vez disso, por algum motivo, ele atua como um arquivo pbpaste
.
$ echo hello | /usr/bin/pbcopy
$ echo hello | /usr/bin/pbpaste
hello
$ echo hello | /usr/local/bin/xclip
hello
Esperava-se que o terceiro comando se comportasse como o primeiro comando, não como o segundo comando.
Alguma ideia?
Isso normalmente acontece com programas que implementam vários comportamentos e decidem em qual agir inspecionando o nome pelo qual foram chamados.
Essa técnica é usada em algumas ferramentas populares, como a
busybox
que fornece a maioria dos utilitários padrão típicos do Linux/Unix em um único binário.Nesse caso, parece que o mesmo binário está implementando o comportamento "copiar" e "colar" e está agindo como "colar" por padrão (exceto quando o nome chamado corresponde
pbcopy
exatamente).Você pode facilmente contornar isso, criando
xclip
um script de shell que chamapbcopy
em vez de um link simbólico. Isso seria aproximadamente o equivalente ao que você tem atualmente:As
exec
garantiaspbcopy
serão executadas no mesmo processo, substituirão o shell, que não estará mais disponível durante a execução.O
"$@"
irá passar qualquer argumento literalmente parapbcopy
(shells mais antigos precisavam de algo como${1+"$@"}
não manipular argumentos corretamente, mas esse não é o caso com implementações modernas do shell.) Isso é o mesmo que acontece com argumentos ao usar a abordagem de link simbólico.Não se esqueça de tornar o script executável:
Não tenho certeza se os argumentos esperados por
xclip
realmente correspondem aos interpretados porpbcopy
, mas meu palpite é que eles não deveriam. Se você quiser traduzir os argumentos normalmente tomados porxclip
para aqueles analisados porpbcopy
, este script também seria um local apropriado para fazer isso.