Programy konsoli szeregowej¹, których użyjesz na drugim końcu połączenia, będą miały sposób na przesłanie pliku na stronę zdalną. To, jak dokładnie to zrobisz, zależy od zasobów dostępnych w systemie zdalnym.
Mam lrzsz
lub kermit
po drugiej stronie
Najłatwiejszym przypadkiem jest, jeśli na stronie zdalnej jest zainstalowany solidny program do przesyłania plików binarnych, taki jak lrzsz
lub kermit
. To było kiedyś bardziej powszechne niż dzisiaj, ale twój konkretny system może nadal mieć jeden z nich.
Program konsoli szeregowej, którego używasz po stronie lokalnej, prawie na pewno ma sposób na przesłanie Zmodem lub Kermit, co pozwala wysłać wszystko, czego potrzebujesz bezpośrednio.
W przypadku Zmodem po prostu wpisz rz
w zdalnym systemie, który wysyła specjalny ciąg znaków, który lokalny terminal szeregowy powinien zrozumieć, powodując wyświetlenie okna dialogowego wyboru plików.
Kermit jest prostszym protokołem, dlatego w takim przypadku musisz rozpocząć transfer ręcznie.
Nie mam programu do przesyłania plików binarnych, ale mam uuencode
/base64
Istnieje wiele korzyści z wykorzystaniem odpowiedniego programu transferu plików binarnych jak lrzsz
lub kermit
: efektywność, sum kontrolnych, automatycznych prób, poronionych wznowienia transferu, wielokrotnego przesyłania plików, itp, ale są to luksusy . Jeśli musisz wysłać tylko jeden plik lub rzadko wysyłasz pliki, możesz uniknąć przesyłania plików ASCII.
Ponieważ protokoły terminali interpretują wiele wartości bajtów występujących w pliku danych binarnych, nie można wysłać pliku bezpośrednio przez to samo połączenie; jeśli to zrobisz, kod emulacji terminalu na obu końcach spróbuje zinterpretować niektóre dane, uszkadzając dane i prawdopodobnie wprowadzając w błąd także kod obsługi terminalu.
Można obejść ten problem, kodując dane binarne w bezpieczny podzbiór ASCII po stronie lokalnej, a następnie przekształcając je z powrotem w surowe dane binarne po stronie zdalnej. To jest to, co uuencode
i base64
programy zrobić, różnią się tylko drobnymi wyboru algorytmu.
W systemie lokalnym kodujesz plik: ²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
Następnie wpisz to polecenie w systemie zdalnym i wyślij plik za pomocą funkcji „Przesyłanie ASCII” na lokalnej konsoli szeregowej:
$ cat | uudecode
Po zakończeniu przesyłania pliku naciśnij, Ctrl-Caby wyjść cat
. Teraz masz zdekodowany plik w systemie zdalnym, tak jak chcesz.
Ale mam wiele plików do wysłania, a transkodowanie ASCII do druku to ból!
Nie jest trudno załadować się na wyższy poziom technologii. Jeśli zdalny system ma kompilator C, możesz użyć wcześniejszej techniki, aby wysłać zdalnemu systemowi kopię lrzsz
kodu źródłowego. Po stronie lokalnej:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
Następnie w systemie zdalnym wpisz to za pomocą programu konsoli szeregowej:
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
Po uruchomieniu pierwszego polecenia wykonaj „przesyłanie ASCII” lrzsz.tgz.uue
pliku do systemu zdalnego. Rurociąg akceptuje nieokodowane dane i dekoduje je do binarnego pliku tar, który można rozpakować i skompilować.
Ale nie mam kompilatora C w systemie zdalnym
Jeśli nie mają nawet kompilator na zdalnym systemie, można przejechać skompilować ten rz
program (lub cokolwiek) w systemie lokalnym i wysłać go do systemu zdalnego przy użyciu powyższej techniki.
Przypisy:
minicom , picocom , PuTTY , VanDyke CRT ...
Musisz podać nazwę pliku wejściowego do tej wersji uuencode
dwa razy, raz, aby nazwać źródło danych wejściowych, i jeszcze raz zadeklarować, co system zdalny powinien wywołać plik, gdy dekoduje dane do pliku wyjściowego. Można sobie wyobrazić, że system zdalny ma inną nazwę dla pliku wyjściowego.
Twoja lokalna wersja uuencode
może zachowywać się inaczej.