РЕДАКТИРОВАТЬ: Изменен основной пример с 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

и читать необработанный ввод (включая управляющие и escape-символы!) из COM порта:

C:\> type <COM4

но я не могу делать оба одновременно, в одном и том же или в отдельных процессах.

Я пытался использовать PuTTY и RealTerm, но оба из них позволяют мне управлять Apple только с компьютера с Windows, что доказывает, что соединение работает, но в точности противоположно тому, что я хочу. Как разместить консольное приложение Windows для доступа с подключенного терминала?

1 ответ1

1

Изменить: «Повторно ответил» после уточнения вопроса

Согласно Microsoft (я не могу найти раздел Using command redirection operators для Windows новее, чем XP):

Дублирующие ручки

Оператор & redirection дублирует вывод или ввод из одного указанного дескриптора в другой указанный дескриптор. Например, чтобы отправить вывод 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 to >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 ...

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .