Программы последовательной консоли¹, которые вы будете использовать на другом конце соединения, будут каким-то образом отправлять файл на удаленную сторону. Как именно вы это сделаете, зависит от того, какие ресурсы у вас есть в удаленной системе.
У меня есть lrzsz
или kermit
на удаленной стороне
Самый простой случай - если у вас установлена удаленная двоичная программа для передачи файлов, например, lrzsz
или kermit
. Это было когда-то более распространено, чем сегодня, но ваша конкретная система может все еще иметь один из них.
Программа последовательной консоли, которую вы используете на локальной стороне, почти наверняка имеет способ сделать загрузку Zmodem или Kermit, которая позволяет вам отправлять все, что вам нужно напрямую.
В случае Zmodem просто введите rz
на удаленной системе, которая отправляет специальную строку, которую должен понимать локальный последовательный терминал, вызывая его всплывающее диалоговое окно выбора файлов.
Kermit - более простой протокол, поэтому в этом случае вы должны начать передачу вручную.
У меня нет программы передачи двоичных файлов, но у меня есть uuencode
/base64
Использование правильной программы передачи двоичных файлов имеет несколько преимуществ, таких как lrzsz
или kermit
: эффективность, проверка контрольных сумм, автоматические повторные попытки, возобновление отмененной передачи, многократная передача файлов и т. Д., Но это роскошь . Если вам нужно отправить только один файл, или вы отправляете файлы редко, вы можете избежать загрузки ASCII.
Поскольку терминальные протоколы интерпретируют многие байтовые значения, встречающиеся в двоичном файле данных, вы не можете отправить файл напрямую через одно и то же соединение; если вы это сделаете, код эмуляции терминала на любом конце попытается интерпретировать некоторые данные, повредить данные и, вероятно, также запутать код обработки терминала.
Вы можете обойти это, кодируя двоичные данные в безопасное подмножество ASCII на локальной стороне, а затем превращая их обратно в необработанные двоичные данные на удаленной стороне. Это то , что uuencode
и base64
программы делают, отличаясь лишь в незначительном выборе алгоритма.
В локальной системе вы кодируете файл: ²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
Затем вы вводите эту команду в удаленной системе и отправляете файл с помощью функции «ASCII upload» локальной последовательной консоли:
$ cat | uudecode
Когда загрузка файла завершится, нажмите, Ctrl-Cчтобы выйти cat
. Теперь у вас есть декодированный файл в удаленной системе, как вы и хотели.
Но у меня много файлов для отправки, и перекодировка в ASCII для печати - это боль!
Нетрудно загрузить себя на более высокий уровень технологий. Если в удаленной системе есть компилятор C, вы можете использовать предыдущую технику для отправки удаленной системе копии lrzsz
исходного кода. На местной стороне:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
Затем в удаленной системе введите это через программу последовательной консоли:
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
После запуска первой команды выполните «ASCII-загрузку» lrzsz.tgz.uue
файла в удаленную систему. Конвейер принимает данные в кодировке uuenco и декодирует их в двоичный архив, который вы можете распаковать и собрать.
Но у меня нет компилятора C в удаленной системе
Если вы даже не компилятор на удаленной системе, вы можете пересечь скомпилировать в rz
программу (или любой другой ) на локальной системе и отправить его на удаленной системе , используя описанную выше технику.
Примечания:
Миником , picocom , PuTTY , VanDyke CRT ...
Вы должны uuencode
дважды указать имя входного файла для этой версии , один раз, чтобы указать источник входных данных, и снова объявить, как удаленная система должна вызывать файл, когда она декодирует данные в выходной файл. Можно предположить, что удаленная система должна иметь другое имя для своего выходного файла.
Ваша локальная версия uuencode
может вести себя по-другому.