
РЕДАКТИРОВАТЬ:Основной пример изменен с Zork Dungeon на оболочку ОС по умолчанию.
У меня есть консольное приложение, работающее на современной машине. У меня также есть Apple //e с Super Serial Card, что позволяет ему функционировать как тупой терминал через последовательное COM-соединение (подробности за его пределами бесполезны). Я могу прекрасно соединить эти два устройства, используя последовательный порт USB.
Когда на современной машине загружен Linux, настроив параметры COM и предоставив себе права на группу, к которой принадлежит файл устройства, я могу запустить
$ bash </dev/ttyUSB1 >/dev/ttyUSB1 2>/dev/ttyUSB1
и получить сеанс bash на Apple - машина Linux выступает в качестве сервера и запускает программу, но ввод и вывод идут на Apple, который является простым клиентом. Это также работает с более специализированными программами, такими как dungeon
(Zork).
Как сделать то же самое в Windows? Очевидно, что я не могу в точности повторить вышеприведенное решение, поскольку Windows позволяет мне COM
открывать порт только в одном месте за раз - запустив аналог вышеуказанной команды в Windows,
C:\> cmd <COM4 >COM4 2>COM4
выдает ошибку «Отказано в доступе».
Я могу отправить данные на COM-порт:
C:\> echo "Hello" >COM4
и считываем необработанный ввод (включая управляющие и экранированные символы!) с COM-порта:
C:\> type <COM4
но я не могу делать и то, и другое одновременно, в одном и том же или отдельных процессах.
Я пробовал использовать PuTTY и RealTerm, но оба они позволяют мне управлять Apple только с машины Windows, что доказывает, что соединение работает, но это совершенно противоположное направление того, что мне нужно. Как разместить консольное приложение Windows для доступа с подключенного терминала?
решение1
Редактировать:«Отвечено повторно» после уточнения вопроса
В соответствии сМайкрософт(Я не могу найти Using command redirection operators
раздел для Windows новее XP):
Дублирование ручек
Оператор перенаправления & дублирует вывод или ввод из одного указанного дескриптора в другой указанный дескриптор. Например, чтобы отправить вывод dir в File.txt и отправить вывод ошибки в File.txt, введите:
dir>c:\file.txt 2>&1
Когда вы дублируете дескриптор, вы дублируете все характеристики исходного появления дескриптора. Например, если дескриптор имеет доступ только для записи, все дубликаты этого дескриптора имеют доступ только для записи. Вы не можете дублировать дескриптор с доступом только для чтения в дескриптор с доступом только для записи.
Итак, хорошие новости:
- Вы можете изменить
<COM4 >COM4 2>COM4
на<COM4 >&1 2>&1
.
Плохая новость:
- Вы смешиваете требования к доступу дескриптора только для чтения
<COM4
и только для записи>&1 2>&1
и меняетеAccess Denied
наThe handle could not be duplicated during redirection of handle 1
.
Если вы измените:
<COM4 >&1 2>&1
в>COM4 2>&1 <&1
(только для чтения и только для записи все еще смешаны), что работает и дает вам пригодный для использованияSTDOUT
иSTDERR
, ноSTDIN
все еще кажется* сломанным. (*)Я провел несколько тестов, но, похоже, этоSTDIN
не работает...
Однако я вижу один способ исправить это:
- Использовать
com0com
эмулятор нуль-модемаи определить 3 пары виртуальных портов:COM_O
-COM_O4
дляSTDOUT
;COM_E
-COM_E4
дляSTDERR
;COM_I
-COM_I4
дляSTDIN
.
Создайте последовательный концентратор с
hub4com.exe
(com0com
частью) изCOM_O4
,COM_E4
,COM_I4
иCOM4
:hub4com.exe --route=0:1 --route=2,3:0 --baud=19200 --data=8 --parity=no --stop=1 --octs=off --odsr=off --ox=off --ix=off --idsr=off --ito=0 \\.\COM4 \\.\COM_I4 \\.\COM_E4 \\.\COM_O4
- Не забудьте настроить правильные (свои) параметры передачи:
--baud
...
И
<\\.\COM_I >\\.\COM_O 2>\\.\COM_E
сформируйте командную строку.
Наконец, для:
hub4com.exe --route=0:1 --route=2,3:0 --octs=off \\.\COM4 \\.\COM_I4 \\.\COM_E4 \\.\COM_O4
и:
cmd <\\.\COM_I >\\.\COM_O 2>\\.\COM_E
у вас есть командная строка Windows COM4
на 19200 8N1
...