Les programmes de console série¹ que vous utiliserez à l'autre extrémité de la connexion auront un moyen d'envoyer un fichier du côté distant. La façon dont vous vous y prenez dépend des ressources dont vous disposez sur le système distant.
J'ai lrzsz
ou kermit
du côté distant
Le cas le plus simple est si vous avez un programme de transfert de fichiers binaires solide installé sur le côté distant tel que lrzsz
ou kermit
. C'était une fois de plus courant qu'aujourd'hui, mais votre système particulier pourrait encore en avoir un.
Le programme de console série que vous utilisez du côté local a presque certainement un moyen d'effectuer un téléchargement Zmodem ou Kermit, qui vous permet d'envoyer tout ce dont vous avez besoin directement.
Dans le cas de Zmodem, tapez simplement rz
sur le système distant, qui envoie une chaîne spéciale que le terminal série local doit comprendre, ce qui fait apparaître une boîte de dialogue de sélection de fichiers.
Kermit est un protocole plus simple, vous devez donc démarrer le transfert manuellement dans ce cas.
Je n'ai pas de programme de transfert de fichiers binaires, mais j'ai uuencode
/base64
Il y a plusieurs avantages à utiliser un programme de transfert de fichiers binaire approprié comme lrzsz
ou kermit
: efficacité, somme de contrôle, relances automatiques, reprise de transfert avortée, transfert de fichiers multiples, etc., mais ce sont des luxes . Si vous n'avez besoin d'envoyer qu'un seul fichier, ou si vous envoyez rarement des fichiers, vous pouvez vous en sortir avec les téléchargements ASCII.
Étant donné que les protocoles de terminal interprètent de nombreuses valeurs d'octets qui se produisent dans un fichier de données binaires, vous ne pouvez pas envoyer le fichier directement via la même connexion; si vous le faites, le code d'émulation de terminal à chaque extrémité essaiera d'interpréter certaines des données, corrompant les données et prêtant à confusion également le code de gestion du terminal.
Vous pouvez contourner ce problème en encodant les données binaires en un sous-ensemble sécurisé d'ASCII du côté local, puis en les reconvertissant en données binaires brutes du côté distant. C'est ce que font les programmes uuencode
et base64
, ne différant que par des choix d'algorithmes mineurs.
Sur le système local, vous encodez le fichier: ²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
Ensuite, vous tapez cette commande sur le système distant et envoyez le fichier à l'aide de la fonction "Téléchargement ASCII" de la console série locale:
$ cat | uudecode
Une fois le téléchargement du fichier terminé, appuyez sur Ctrl-Cpour sortir cat
. Vous avez maintenant votre fichier décodé sur le système distant, comme vous le vouliez.
Mais j'ai beaucoup de fichiers à envoyer, et le transcodage ASCII imprimable est pénible!
Il n'est pas difficile de s'initier à un niveau de technologie plus élevé. Si le système distant possède un compilateur C, vous pouvez utiliser la technique antérieure pour envoyer au système distant une copie du lrzsz
code source. Côté local:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
Ensuite, sur le système distant, saisissez ceci via le programme de la console série:
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
Après avoir démarré la première commande, effectuez un "téléchargement ASCII" du lrzsz.tgz.uue
fichier sur le système distant. Le pipeline accepte les données uuencodées et les décode en un tarball binaire pour vous, que vous pouvez décompresser et construire.
Mais je n'ai pas de compilateur C sur le système distant
Si vous n'avez même pas de compilateur sur le système distant, vous pouvez compiler de manière croisée le programme rz
(ou autre) sur le système local et l'envoyer au système distant en utilisant la technique ci-dessus.
Notes de bas de page:
minicom , picocom , PuTTY , VanDyke CRT ...
Vous devez donner le nom du fichier d'entrée à cette version de uuencode
deux fois, une fois pour nommer la source des données d'entrée, et encore pour déclarer ce que le système distant doit appeler le fichier lorsqu'il décode les données dans un fichier de sortie. On peut imaginer que le système distant ait un nom différent pour son fichier de sortie.
Votre version locale de uuencode
peut se comporter différemment.