Los programas de consola serie¹ que usará en el otro extremo de la conexión tendrán alguna forma de enviar un archivo al lado remoto. La forma exacta en que lo haga depende de los recursos que tenga disponibles en el sistema remoto.
Tengo lrzszo kermiten el lado remoto
El caso más fácil es si tiene un programa sólido de transferencia de archivos binarios instalado en el lado remoto, como lrzszo kermit. Esto fue una vez más común que hoy, pero su sistema particular aún podría tener uno de estos.
El programa de consola en serie que está utilizando en el lado local casi seguramente tiene una forma de hacer una carga de Zmodem o Kermit, que le permite enviar lo que necesite directamente.
En el caso de Zmodem, simplemente escriba rzen el sistema remoto, que envía una cadena especial que el terminal serial local debe entender, haciendo que aparezca un cuadro de diálogo de selección de archivos.
Kermit es un protocolo más simple, por lo que debe iniciar la transferencia manualmente en ese caso.
No tengo un programa de transferencia de archivos binarios, pero sí tengo uuencode/base64
Existen varias ventajas al usar un programa de transferencia de archivos binarios adecuado como lrzszo kermit: eficiencia, suma de verificación, reintentos automáticos, reanudación de transferencia abortada, transferencia de archivos múltiples, etc., pero estos son lujos . Si solo necesita enviar un archivo, o rara vez envía archivos, puede salirse con las cargas ASCII.
Debido a que los protocolos de terminal interpretan muchos de los valores de byte que ocurren en un archivo de datos binarios, no puede enviar el archivo directamente a través de la misma conexión; si lo hace, el código de emulación de terminal en cualquiera de los extremos intentará interpretar algunos de los datos, corrompiendo los datos y probablemente también confundiendo el código de manejo del terminal.
Para evitar esto, codifique los datos binarios en un subconjunto seguro de ASCII en el lado local, y luego vuelva a convertirlos en datos binarios en bruto en el lado remoto. Esto es lo que hacen los programas uuencodey base64, que difieren solo en las opciones de algoritmos menores.
En el sistema local, codifica el archivo: ²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
Luego escribe este comando en el sistema remoto y envía el archivo utilizando la función de "carga ASCII" de la consola serie local:
$ cat | uudecode
Cuando finalice la carga del archivo, presione Ctrl-Cpara salir cat. Ahora tiene su archivo decodificado en el sistema remoto, como quería.
¡Pero tengo muchos archivos para enviar, y la transcodificación ASCII imprimible es una molestia!
No es difícil iniciarse en un nivel superior de tecnología. Si el sistema remoto tiene un compilador de C, puede usar la técnica anterior para enviar una copia del lrzszcódigo fuente al sistema remoto . En el lado local:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
Luego, en el sistema remoto, escriba esto a través del programa de consola serie:
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
Después de iniciar el primer comando, realice una "carga ASCII" del lrzsz.tgz.uuearchivo al sistema remoto. La canalización acepta los datos sin codificar y los decodifica en un tarball binario para usted, que puede desempaquetar y construir.
Pero no tengo un compilador de C en el sistema remoto
Si ni siquiera tiene un compilador en el sistema remoto, puede realizar una compilación cruzada del programa rz(o lo que sea) en el sistema local y enviarlo al sistema remoto utilizando la técnica anterior.
Notas al pie:
minicom , picocom , PuTTY , VanDyke CRT ...
uuencodeDebe dar el nombre del archivo de entrada a esta versión dos veces, una vez para nombrar la fuente de los datos de entrada y nuevamente para declarar cómo debe llamar el sistema remoto al archivo cuando decodifica los datos en un archivo de salida. Es posible que desee que el sistema remoto tenga un nombre diferente para su archivo de salida.
Su versión local de uuencodepuede comportarse de manera diferente.