10 votes

Comment puis-je copier dans le presse-papiers de OSX à partir d'une coquille à distance en utilisant iTerm2 ?

En utilisant iTerm2, je lance une session SSH interactive vers une machine Linux distante (où pbcopy n'est pas disponible). Sur la machine Linux distante, je voudrais capturer la sortie d'une commande arbitraire (par exemple ls *.foo), et la faire apparaître magiquement dans le presse-papiers de mon OSX, de sorte que lorsque je fais +v elle apparaisse dans l'application OSX dans laquelle je viens de coller. Est-ce possible? J'ai essayé les codes d'échappement mentionnés sur la page de documentation d'iTerm2 et je n'arrive pas à les faire fonctionner.

0 votes

0 votes

@klanomath -- merci, je vais prendre ça en considération (je ne suis pas sûr de vouloir configurer un accès à nouveau à ma machine via des clés SSH, même si cela pourrait être protégé par un code secret, bien sûr.)

0 votes

Il nécessite X sur le serveur distant, qui n'est pas là, et XQuartz qui tourne sur le serveur local, ce qui fait chauffe ma machine. Mais c'est peut-être ma meilleure option -- merci !

5voto

Joe Casadonte Points 1155

Solution

En rassemblant de nombreuses informations provenant de différentes sources, voici ce que j'ai trouvé.

Démon Local

Depuis l'ordinateur local (OSX), configurez un démon pour écouter sur un port spécifique, via launchd (voir les liens ci-dessous). Le processus du démon appellera simplement pbcopy, qui prendra tout ce qui est passé via STDIN et le mettra dans le presse-papiers. Pour ce faire, vous devez configurer un fichier plist launchd. Le mien ressemblait à ceci :

    Label
    local.pbcopy.9999
    UserName
    joe
    Program
    /usr/bin/pbcopy
    StandardOutPath
    /tmp/pb9999.out
    StandardErrorPath
    /tmp/pb9999.err
    Sockets

        Listeners

            SockNodeName
            localhost
            SockServiceName
            9999

    inetdCompatibility

        Wait

Par convention, le nom du fichier plist devrait être le nom de l'étiquette avec .plist ajouté, donc pour l'exemple ci-dessus, ce serait local.pbcopy.9999.plist. Si vous souhaitez utiliser un port autre que 9999, changez-le partout (en gardant à l'esprit qu'il doit être quelque chose au-dessus de 1024 et ne doit pas être un port connu que vous pourriez déjà utiliser). Une fois que tout fonctionne, vous pouvez supprimer les clés et les chaînes StandardOutPath et StandardErrorPath, car elles ne sont nécessaires que pour le débogage.

Pour charger le démon, exécutez la commande suivante :

$ launchctl load local.pbcopy.9999.plist

Vous pouvez voir s'il est chargé ou le retirer avec les commandes suivantes :

$ launchctl list local.pbcopy.9999
$ launchctl remove local.pbcopy.9999

Si vous souhaitez que cela se charge à chaque fois que vous vous connectez, placez le fichier plist dans le répertoire ~/Library/LaunchAgents.

Remarque : vous devrez configurer ceci sur chaque hôte local sur lequel vous voulez que cela fonctionne.

Transfert de Port SSH

Comme je pourrais accéder à la machine distante depuis plusieurs ordinateurs locaux différents, je ne peux pas indiquer en dur l'envoi des données sur la machine distante à un hôte spécifique. Pour rendre cela aussi indolore et dynamique que possible, j'ai utilisé le transfert de port SSH pour créer un lien dynamique de la machine distante vers l'ordinateur local (les comment et pourquoi sont au-delà de cette réponse ; voir ci-dessous pour plus d'informations). Spécifiquement, je crée un lien du port 9997 de la machine distante au port 9999 de l'ordinateur local, qui a maintenant un démon qui écoute, grâce aux éléments launchd ci-dessus. Je pourrais utiliser le port 9999 à la fois sur la machine distante et sur l'ordinateur local, mais je n'en ai pas besoin.

Pour configurer ce tunnel, exécutez la commande suivante :

$ ssh -R 9997:localhost:9999 utilisateur@remote.com

Vous pouvez vous connecter à plusieurs machines distantes différentes avec la même commande et tout fonctionnera comme prévu. Vous pouvez vous connecter plusieurs fois à la même machine distante avec la même commande, et cela fonctionnera plus ou moins comme prévu ; voir la note ci-dessous.

Si vous ne voulez pas taper -R 9997:localhost:9999 à chaque invocation SSH, vous pouvez mettre la définition de transfert distant dans le fichier de configuration SSH pour le faire automatiquement. Voici un exemple de mon fichier ~/.ssh/config :

Host ufo*
  RemoteForward 9997 localhost:9999

Avec cela, à chaque fois que je me connecte en SSH à un hôte dont le nom commence par 'ufo', le transfert distant de 9997 à localhost:9999 sera automatiquement configuré. Consultez le lien de la page de manuel du fichier de configuration pour plus d'options.

Envoi de Données

À l'extrémité distante, j'utilise netcat pour envoyer le contenu souhaité au démon en écoute.

$ date | nc localhost 9997

Vous pouvez rendre les choses aussi compliquées que vous le souhaitez :

$ nc localhost 9997 < `ls -ld *`
> `date`
> EOF

Vous pouvez même décider dynamiquement d'envoyer ou non des données, en fonction de la présence ou non d'une écoute (il y a probablement une manière plus efficace de faire cela, mais cela fonctionne) :

#!/bin/bash
cnt=`(netstat -lnptu 2>/dev/null) | grep 127.0.0.1:9999 | grep -v grep | wc -l`
if [[ $cnt -eq 1 ]]; then
    date | nc localhost 9999
fi

Observations & Avis

Choses que j'ai notées :

  • pbcopy fonctionne bien avec Copy'em Paste
  • si vous lancez plus d'une session SSH avec le même transfert de port distant vers la même machine distante, seule la première aura un effet ; aucune erreur de "port en double" ne sera signalée d'un côté ou de l'autre
  • de même, si vous vous connectez depuis plusieurs ordinateurs locaux différents à la même machine distante en utilisant le même port distant (par ex. 9997), seule la première aura un effet

Liens de Référence

1 votes

Si vous n'avez pas nc sur votre hôte distant, cela fonctionne - du moins sur RHEL : echo "comment ça va" > /dev/tcp/localhost/9997

0 votes

J'ai utilisé cette solution pendant plus d'1 an, mais j'ai récemment remarqué qu'elle ne prend pas en charge l'unicode. Par exemple, le presse-papiers a été rempli de test‚ûú abc après echo "test abc" | nc -w 0 localhost 9999, ce qui signifie que est converti en ‚ûú en cours de route. Est-ce que quelqu'un a une idée à ce sujet ?

3voto

hyperknot Points 215

remote pbcopy pour iTerm2 semble être un logiciel spécialement conçu pour ce problème.

2voto

user784637 Points 9855

Si vous utilisez iTerm2, il y a une manière plus simple. Cette fonctionnalité est intégrée aux capacités de Shell Integration d'iTerm2 via la commande it2copy:

Utilisation: it2copy
          Copie dans le presse-papiers depuis l'entrée standard
       it2copy nomfichier
          Copie dans le presse-papiers depuis un fichier

Pour que cela fonctionne, choisissez l'élément de menu iTerm2-->Installer Shell Integration lorsque vous êtes connecté à l'hôte distant, pour l'installer sur votre propre compte. Une fois que cela est fait, vous aurez accès à it2copy, ainsi qu'à une série d'autres commandes aliasées qui fournissent des fonctionnalités intéressantes.

Les autres solutions ici sont de bons contournements mais celle-ci est tellement indolore en comparaison.

0voto

Michael Zhou Points 167

Vous pouvez le faire

ssh -ttt user@location "ksh -c 'ls *'" | pbcopy

0 votes

J'ai besoin d'une solution pour une session shell interactive - je vais clarifier ci-dessus.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X