Socat linux virtual com port

Ubuntu Documentation

Introduction

Virtual serial ports are commonly used in development of programs using serial connection as well as debugging existing applications — to check what kind of data is transmitted over a serial connection.

The idea of virtual serial port is to create two virtual serial ports linked with a null modem cable, attaching one end to tested application and the other end to (usually) serial terminal (e.g. Cutecom).

Installing prerequisites

To create a pair of ports you will need a utility called «socat». It is located in «universe» repository, so you should be able to find it in Synaptic. Alternatively install using

Creating ports

After installing socat you have to execute following command:

That should create and link the virtual port pair for as long as socat is running.

If you are like me and want a little more feedback on what is happening instead of a command line that is hanging, use verbose mode instead:

You can put the -d argument up to four times, increasing the information fed back to you each time.

Checking file names

Using socat

The easiest way to tell which file names are assigned to these virtual ports is to tell socat to print information about opened pseudo terminals during initialization using following options (verbose mode):

Your applicantion should connect to these files.

Using lsof

Another way is to list socat’s open files:

You should notice file /dev/ptmx, that is pseudo terminal multiplexer and directly below each entry should be listed /dev/pts/X file, which are the ends of created pair.

External Links

VirtualSerialPort (последним исправлял пользователь janisozaur 2010-10-28 11:21:26)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

/dev/blog

25 июн. 2013 г.

Проброс последовательного порта по сети в Linux (serial over ip)

Ссылки

Входные данные

Способ 1: socat

Самый простой способ – использовать socat. С его помощью можно соединить последовательное устройство и сокет.
На server создаем сокет на tcp-порту 12345, привязанный к /dev/ttyS0 :
На client создаем виртуальный терминал в /dev/pts/N и привязываем его к сокету server:12345 :
При такой схеме передаются данные, но не управляющая информация. Настройка виртуального терминала на хосте client никак не отражается на реальном терминале на хосте server. Это значит, что приложения, которые используют ioctl(2) или termios(3) , не будут работать так, как ожидается.

Способ 2: RFC 2217

Сервер

• ser2net
  ser2net реализует телнет-сервер RFC 2217.
  Запускаем на хосте server на порту 23:
  ser2net можно также запускать в режиме демона или с помощью inetd .

• sredird
  sredird – другая реализация сервера RFC 2217. Он лучше совместим с клиентом cyclades-serial-client .
  Запускаем на хосте server на порту 23 с помощью netcat:
  sredird можно также запускать с помощью inetd .

• sercd
  sercd – еще одна реализация. Он основан на sredird .

Клиент

• telnet
  После запуска сервера к удаленному терминалу можно подключиться по телнет:

• ckermit
  Вместо telnet можно использовать C-Kermit, который поддерживает RFC 2217:
  С ним помимо телнет будут также доступны команды для конфигурирования порта.

• cyclades-serial-client

  cyclades-serial-client – клиент для сервера RFC 2217. Он работает с помощью трюка с LD_PRELOAD .

  Для каждого удаленного терминала создается:

  1. Виртуальный терминал /dev/pts/N .
  2. Символическая ссылка на него /dev/NAME .
  3. Локальный сокет /dev/NAME.control .

  Затем пользователь с помощью LD_PRELOAD может заставить приложение, использующее терминал /dev/NAME , перенаправлять вызовы ioctl(2) и tcsetattr(3) в сокет /dev/NAME.control , откуда они будут прочитаны демоном cyclades-ser-cli и отправлены в удаленный терминал.

  Настраиваем конфиг клиента /etc/cyclades-devices (без этого не будет работать трюк с LD_PRELOAD ):
  Запускаем демон, обслуживающий виртуальный терминал:
  Можно также запускать демон с помощью cyclades-serial-client .
  Проверяем передачу данных:
  Cообщение hello должен получить тот, кто подключен к порту /dev/ttyS0 на хосте server .
  Проверяем настройку baud rate :
  На хосте server у терминала /dev/ttyS0 должно обновиться значение:
  У меня этот клиент работает с сервером sredird , но не работает с ser2net .

  Другие проблемы:

  • Не все параметры ioctl() реализованы.
  • Подход с использованием LD_PRELOAD для ioctl() и tcgetattr() работает не для всех приложений. У меня так и не заработала команда setserial(8) .

• Network Virtual Terminal
  nvtty – это драйвер ядра, реализующий виртуальный терминал, перенаправляющий все запросы удаленному серверу RFC 2217. Патч основан на cyclades-serial-client .

  And this is still something that should be done in userspace if necessary
  by fixing up the tty layer to support pty/tty pair modem lines and
  termios change reporting, or some kind of generic vt that can also
  expose all the config other net protocols might need.

  TTYredirector

  Способ 3: Serial to Ethernet Converter

  Serial to Ethernet Converter – устройство, преобразующее RS-232 (и/или другие протоколы) в Ethernet и обратно.

  Есть как минимум два производителя, поставляющие вместе со своими преобразователями драйвер для Linux, который создает виртуальный COM-порт и перенаправляет все запросы к нему в сеть:

  • Tibbo VSPDL (Virtual Serial Port Driver for LINUX)
  • Perle TruePort

  Источник

  Виртуальный последовательный порт для Linux

  Мне нужно протестировать приложение последовательного порта в Linux, однако моя тестовая машина имеет только один последовательный порт.

  Есть ли способ добавить виртуальный последовательный порт в Linux и протестировать мое приложение, эмулируя устройство через оболочку или скрипт?

  Примечание: я не могу переназначить порт, он жестко запрограммирован на ttys2, и мне нужно протестировать приложение, как оно написано.

  Для этого вы можете использовать pty («псевдотелетайп», где последовательный порт является «настоящим телетайпом»). С одного конца откройте /dev/ptyp5 , а затем прикрепите свою программу к /dev/ttyp5 ; ttyp5 будет действовать так же, как последовательный порт, но будет отправлять / получать все, что он делает, через / dev / ptyp5.

  Если вам действительно нужно, чтобы он разговаривал с файлом с именем /dev/ttys2 , просто уберите старый /dev/ttys2 и создайте символическую ссылку с ptyp5 на ttys2 .

  Конечно, вы можете использовать другое число, кроме ptyp5 . Возможно, выберите один с большим числом, чтобы избежать дублирования, поскольку все ваши терминалы входа также будут использовать ptys.

  В Википедии есть дополнительная информация о ptys: http://en.wikipedia.org/wiki/Pseudo_terminal

  Дополняя ответ @ slonik.

  Вы можете протестировать socat для создания виртуального последовательного порта, выполнив следующую процедуру (проверено на Ubuntu 12.04):

  Откройте терминал (назовем его Terminal 0) и запустите его:

  Приведенный выше код возвращает:

  Откройте другой терминал и напишите (Терминал 1):

  имя порта этой команды может быть изменено в зависимости от компьютера. это зависит от предыдущего вывода.

  вы должны использовать номер, доступный в выделенной области.

  Откройте другой терминал и напишите (Терминал 2):

  Теперь вернитесь в Терминал 1, и вы увидите строку «Тест».

  Для этого используйте socat:

  Также существует tty0tty http://sourceforge.net/projects/tty0tty/, который является настоящим эмулятором нуль-модема для Linux.

  Это простой модуль ядра — небольшой исходный файл. Я не знаю, почему он получил отрицательные отзывы на sourceforge, но мне он подходит. Самое лучшее в нем то, что он также эмулирует аппаратные контакты (RTC / CTS DSR / DTR). Он даже реализует команды TIOCMGET / TIOCMSET и TIOCMIWAIT iotcl!

  В недавнем ядре вы можете получить ошибки компиляции. Это легко исправить. Просто вставьте несколько строк вверху источника module / tty0tty.c (после включений):

  Когда модуль загружен, он создает 4 пары последовательных портов. Устройства: от / dev / tnt0 до / dev / tnt7, где tnt0 подключен к tnt1, tnt2 подключен к tnt3 и т. Д. Вам может потребоваться исправить права доступа к файлам, чтобы иметь возможность использовать устройства.

  Думаю, я немного поторопился со своим энтузиазмом. Хотя драйвер выглядит многообещающе, он кажется нестабильным. Я не знаю наверняка, но думаю, что это разбило машину в офисе, над которым я работал из дома. Я не могу проверить, пока не вернусь в офис в понедельник.

  Во-вторых, TIOCMIWAIT не работает. Код, кажется, скопирован из какого-то примера кода «крошечного терминала». Обработка TIOCMIWAIT кажется на месте, но она никогда не просыпается, потому что соответствующий вызов wake_up_interruptible () отсутствует.

  Авария в офисе действительно произошла по вине водителя. Отсутствовала инициализация, и полностью непроверенный код TIOCMIWAIT вызвал сбой машины.

  Вчера и сегодня потратил на переписывание драйвера. Было много проблем, но теперь у меня все хорошо. По-прежнему отсутствует код для аппаратного управления потоком данных, управляемого драйвером, но он мне не нужен, потому что я сам буду управлять контактами, используя TIOCMGET / TIOCMSET / TIOCMIWAIT из кода пользовательского режима.

  Если кому-то интересна моя версия кода, напишите мне, и я отправлю его вам.

  Источник

  Пробрасываем порт UART из Linux в Windows через SSH-соединение

  Не так давно в нашем сервисе All-Hardware произошло знаковое событие. Если раньше порт UART был подключён только к терминалу внутри браузера, то теперь можно установить в Windows специальный драйвер, через который этот порт будет проброшен в вашу локальную систему. Теперь работа с удалённой платой даёт что-то большее, чем написание «Hello World». Вы можете запустить на своей локальной машине программы, которые работают с COM-портом, и обмениваться с удалённой платой по сложным протоколам. Из того, что уже реализовано на практике, – измерение тока потребления платой STM32G474RE DPOW1 Discovery.

  Лично я в эпопее по внедрению данной функциональности участия не принимал, так как в то время одомашнивал оборотней (осваивал работу с синтезируемым ядром RISC-V — SweRVolf), но расспросил участников, какие технологии они применяли. В этой статье я покажу физические принципы, лежащие в основе проброса. Практический выхлоп будет состоять в том, что вы сможете пробрасывать порт, не устанавливая никаких драйверов, но реализуя особую (а не универсальную) логику в своей программе. Ну, и вы поймёте, как можно пробросить порт не только для нашего сервиса, а вообще из ОС Linux.

  

  1. Введение

  Сначала стоит напомнить, что такое сервис All-Hardware. Подробно про него можно почитать в моих предыдущих статьях (раз и два). Есть также статья моего коллеги. А если кратко, то это такой сайт, через который можно поработать с отладочными платами на базе микроконтроллеров. Сейчас там есть STM32 и NXP. При этом вы пишете и компилируете код на своей машине, а затем просто подключаетесь отладчиком к нашему серверу. Все современные средства отладки позволяют работать не только локально, но и удалённо, и сервис эту возможность использует. Ну, а для обратной связи на сервере имеется видеокамера, которая снимает состояние платы (её светодиоды и экран).

  Но реальная работа с платами обычно подразумевает что-то большее, чем пошаговую отладку и просмотр экрана. Платы должны что-то делать. И для этого у них имеются порты. С древнейших времён в нашем сервисе был терминал, через который можно было общаться с UART. Однако интерактивная работа – это хорошо, но работа собственных программ – лучше. И при внедрении платы STM32G474RE DPOW1 Discovery производитель решил, что на локальных машинах пользователей просто необходимо запускать готовую программу, которая в обычной жизни общается с платой через COM-порт Windows. Ребята написали драйвер уровня ядра, благодаря которому на локальных машинах появляется обычный COM-порт. Но физически он пробрасывается на наш сервер. Какие при этом используются технологии – мы сейчас и рассмотрим. Свой драйвер мы не сделаем. Но при разработке своей программы под Windows нет особой разницы, общаться с COM-портом или вызывать иные функции. А вот вызывать функции, которые будут реализовывать проброс на любой Линуксовый сервер, а не только наш – мы научимся.

  Однако сначала я просто обязан упомянуть про конкурс разработки прошивок для плат, размещенных на сервисе All-Hardware, который идёт как раз в то время, когда статья выкладывается в публикацию. Вдруг это будет кому-то интересно. Конкурс продлится до 24 апреля.

  2. Теория со стороны Linux

  2.1 Полезная утилита socat

  Центральным элементом для проброса портов является забавная утилита socat. Она позволяет пробрасывать данные из одного источника в другой. Список возможных источников – просто широчайший. Установите эту программу:
  sudo apt-get install socat

  и затем – подайте:
  socat –h

  Под катом – простыня, описывающая все возможности пробросов…

  Впечатляет? Сейчас мы попробуем при помощи этой утилиты пробросить порт UART в терминал. Я подключил к системе наш интеллектуальный контроллер реле, который был описан в этой статье. В ней же был описан способ, как определить имя получившегося устройства.

  

  Собственно, конкретно у меня в системе сейчас имеется всего один последовательный порт, но если бы их было несколько, я бы догадался, с каким из них работать, по ID (голубая часть идентификатора). Для простоты, я буду использовать короткое имя (оранжевая часть идентификатора). В общем, имя – /dev/ttyACM0.

  Вбиваю вот такое заклинание:

  Это я запустил программу socat, соединив устройство tty (терминал) с последовательным портом. Работа неблокирующая, данные передаются в сыром виде. Все служебные сообщения уйдут в пустоту.

  

  И тишина. Но зная, что наш контроллер интеллектуального реле реагирует на символ «знак вопроса», я нажимаю его и вижу ответ «abc»:

  

  Нажимая управляющие клавиши для контроллера, я вижу, что вообще-то нахожусь в терминале для последовательного порта, так как все они прекрасно обрабатываются USB-устройством.

  Наверняка, кто-то уже хочет задать вопрос, как это я так лихо настроился на работу с портом, не указав его скорость? Ну, просто контроллер интеллектуально реле – это USB-устройство с интерфейсом CDC. Данные из канала USB сразу попадают в память, а в физический интерфейс UART они никогда не поступают. Именно поэтому я эту поделку и взял для проверки. Минимум возможных мест для сбоя! Но вопрос про скорость – верный. Чтобы её задать, перед запуском socat следовало подать команду вида:

  То есть, совсем честный запуск терминала должен был выглядеть так (на самом деле, можно обойтись и без sudo, как – скоро расскажу):

  Для проверки я подключу к системе настоящий переходник USB-UART и задам скорость не 115200, а какую-нибудь не самую типовую. Скажем, 38400. Это надо, чтобы исключить случайное совпадение, вдруг мы запросили стандартную скорость, а она уже была выставлена. Сначала я хотел задать совсем нестандартную, но система не дала мне это сделать. В Windows таких проблем не возникало, хочу 12345 – задаю 12345. Линукс так не позволил.

  После установки скорости я пошлю свой любимый символ «U» (его код 0x55, то есть, чередующиеся нули и единицы) и измерю фактическую скорость при помощи курсорных измерений осциллографа.

  

  

  Скорость установлена верно (c поправкой на погрешность переходника). Замечательно. Мы смогли пробросить терминал ОС в последовательный порт. Теперь надо подключиться к системе и начать работать с этим терминалом. Но желательно сделать это с максимальным уровнем автоматизации. Давайте рассмотрим, как это сделали наши разработчики.

  2.2 Специально настроенный пользователь

  При работе сторонних пользователей с нашим сервером не стоит давать им вводить команды в терминал. И дело даже не в безопасности (хотя, и в ней тоже). Дело в том, что пользователь зашёл на сервис All-Hardware, чтобы поработать с микроконтроллерами, а не для того, чтобы поработать с Линуксом. Своё отношение к работе с ним я уже многократно высказывал. Лично мне эта работа не нравится. 50 на 50, что приходящие на сервис пользователи будут такого же мнения. Скрываем работу с ОС, и вопрос «нравится или нет» исчезает сам собой. Поэтому мы создадим пользователя, при подключении которого к системе, автоматически будет проброшен порт. И пользователь, работая через SSH-терминал, сразу будет общаться именно с этим портом. Никакой подготовительной работы от него не потребуется.

  Итак, начинаю цитировать методичку. Создаём аккаунт пользователя с именем, скажем, uart01:

  Важный ключик здесь «-s». Он задаёт скрипт, который будет запускаться при входе пользователя. У меня на языке крутится имя autoexec.bat или, скажем, STARTS.COM, если кто-то такое ещё помнит. Но здесь файл будет называться /var/lib/redd/bin/uart/uart01.

  В скрипте бесполезно использовать команду sudo – некому вводить пароль. Чтобы созданному пользователю разрешали запускать программы socat, stty и прочие, работающие с портами, без прав администратора, добавляем его в группу dialout, для чего подаём команду:

  Что мы видим, когда подключаемся к удалённой машине по SSH? А давайте проверим на практике:

  

  Чтобы эта простыня не выдавалась на экран при каждом подключении, надо подать следующую команду, настраивающую свойства пользователя:

  Ну что ж. Методичку я с умным видом процитировал. Давайте хоть сам проверю, сработает ли эта последовательность.

  

  Да-с. Фальстарт… Но мы знаем, что не хватает прав – добавляй sudo. Пробуем ещё раз, применяя это знание:

  

  Было предупреждение, что нет того самого autoexec.bat, но мы его сейчас добавим. В остальном –всё чистенько. Как выяснилось в дальнейшем, чего в методичке не хватает, так это пароля для пользователя. Немного погуглив, я выяснил, что его можно назначить так:

  

  2.3 Пишем autoexec.bat

  На самом деле, боевой вариант скрипта у нас на сервере просто огромен. Сначала полтора экрана занимает зачистка ресурсов. Она необходима на случай, если предыдущая сессия неожиданно завершилась.

  Даже основная работа занимает пол экрана. Там прописан цикл, на случай, если у переходника UART->USB будет отключено питание, ведь чаще всего мы пользуемся портом UART из состава JTAG-адаптера. Обесточили плату – обесточился и адаптер, физически распаянный на ней. Тогда утилита socat вылетит с ошибкой, но бесконечный цикл не даст вылететь сессии, а восстановит соединение.

  Дальше большой участок занимает установка скорости UART в зависимости от заранее заданных параметров.

  Но для понимания принципа всё это нам не только бесполезно, но ещё и крайне вредно. Мы утонем в куче строк, и рискуем не приметить слона. Поэтому для статьи я сделаю совершенно спартанский вариант скрипта. Он будет состоять из тех двух строк, которые мы вводили выше вручную. Первая задаёт скорость порта (я вбил константу 115200), вторая – делает проброс (опять же, я вбил имя пробрасываемого порта намертво). Ну, и перед ними – чисто технологическая строка.

  3. Практическая проверка со стороны Linux

  3.1 Сбойный прогон

  Хорошо, пользователь добавлен, файл autoexec.bat – создан. Давайте попробуем подключиться к системе по SSH от имени этого пользователя:

  

  Ошибка авторизации. Почему? Начальник, знающий Linux в совершенстве, объяснил мне, что ответ на этот вопрос можно найти в файле
  /var/log/auth.log

  Начальник посоветовал мне написать:

  но я, будучи в душе мышевозником, решил поправить атрибуты через утилиту mc, для чего навёлся в ней на файл и выбрал пункт меню «Файл->Права Доступа»:

  

  И надобавлял прав запуска там (вновь установленные флаги отмечены звёздочкой).

  

  3.2 Успешный прогон

  

  Ошибок нет… Нажимаю «знак вопроса».

  

  Работает! Есть проброс!

  Ну всё. Через обычный терминал мы уже можем достучаться. На самом деле, это, конечно, лучше, чем терминал в браузере, но не сильно. Поэтому приступаем к работе из собственной Windows-программы. Ведь цель проброса порта – именно реализовывать сложный обмен своей программы с удалённым контроллером.

  4. Работа со стороны Windows на C#

  4.1 Почему C#

  Вообще, со стороны Windows необходимо и достаточно взять любую библиотеку, реализующую функцию SSH-клиента. Но всё не так просто. У разных библиотек разные лицензии. Как объяснил мне разработчик, принимавший соответствующее решение, библиотека SSH.NET от Renci бесплатна для коммерческих применений. А та же библиотека для C++ уже платная. Именно поэтому за основу в нашей системе был взят .NET вариант. С его разбора и начнём.

  4.2 Как добыть и подключить библиотеку

  Создаём проект на языке C#. Я в своё время немного работал с этим языком через Windows Forms, поэтому создал именно такой проект. В дереве проектов нажимаем правую кнопку «Мыши» и выбираем пункт меню «Управление пакетами NuGet».

  

  В открывшемся окне выбираем вкладку «Обзор» и вбиваем в поиск слово SSH. У меня нужная библиотека оказалась первой в списке.

  

  У меня проект в решении один, но, когда меня обучали, мне разработчик рассказывал, что он затем выбирал вкладку «Установлено» и отмечал, в какие проекты эту библиотеку добавить. Но это я пересказываю на уровне «слышал звон, да не знаю, где он». Просто вдруг у вас будут проблемы – вы будете знать, как их решать. А для случая первичной установки при одном проекте в решении – всё. У нас всё получилось. Вот она сама добавилась в зависимости моего проекта:

  

  Я добавлю на форму три элемента – кнопку «Открыть соединение», строку для отсылки в UART и текст, принятый из UART.

  В программе должна быть переменная-член:

  4.3 Подключаемся к серверу

  В сервисе All-Hardware мы подключаемся к серверу с использованием SSL-сертификата. Но для демонстрации можно использовать и метод попроще, с использованием имени пользователя и пароля. Тогда вся функциональность умещается в две строки плюс немного технологической мишуры:

  4.4 Создание потока данных

  Для того чтобы передавать данные, надо обязательно создать поток (не тот поток, который Thread, а который Stream). Для этого вызываем функцию CreateShellStream(). Удивительно, но ей надо передать массу сведений о консольном окне (число строк, число столбцов, размер окна в точках), хотя никакого физического терминала создано не будет. Просто так надо. Ну, и последний параметр функции – размер буфера. Итого, функция открытия соединения разрастается на одну строку и теперь выглядит так:

  Теперь мы можем передавать данные, пользуясь этим потоком.

  4.5 Передача на сервер

  Как мы видим, функции библиотеки SSH.NET достаточно простые. Работать с нею – одно удовольствие. Функция передачи не является исключением в целом, но имеет один нюанс в частности. Если просто вызывать её, то данные сначала будут копиться в большом буфере, а затем – оптом улетят из него. Латентность системы окажется весьма высокой. Чтобы этого избежать, необходимо и достаточно, записав минимально необходимый блок (какой именно – это уже виднее прикладному программисту, он же знает, какие данные гоняет через порт), вызвать функцию Flush. В моём тестовом примере получаем (ловлю исключений я не стал добавлять, чтобы не перегружать пример, а так-то она нужна):

  4.6 Приём с сервера

  Для чтения есть блокирующая и асинхронная функции. Давайте я в примере сделаю приём через асинхронную функцию по таймеру.

  4.7 Проверяем

  Для проверки открываем соединение, после чего шлём строку из трёх знаков вопроса. Убеждаемся, что пришли три ответа (а каждый ответ у интеллектуального реле выглядит, как строка из символов abc). Значит, система работает.

  

  5. Работа со стороны Windows на прочих языках

  Как пробросить данные из .NET библиотеки в обычную программу, я расскажу весьма тезисно. Дело в том, что тема, с одной стороны, для полного раскрытия требует ещё одной большой статьи, а текущую, боюсь, уже все устали читать. Так что если вдруг интересно – можно сделать ещё одну. С другой же стороны, тема весьма хорошо документирована, хоть в MSDN, хоть у того же Джеффри Рихтера.

  Итак. Для проброса данных между процессами в Windows предусмотрен механизм именованных каналов (Named Pipes). В WIN32 API это функция CreateNamedPipe() с последующими ReadFile/WriteFile. В .NET можно воспользоваться классом NamedPipeClientStream. Правда, разработчик нашей системы сказал (напомню, в этой статье я – простой корреспондент, всё пишу с чужих слов), что очень важно даже для однонаправленного канала задавать направление PipeDirection.InOut. Почему-то у него в иных случаях ничего не работало.

  Собственно, всё. Создаём канал от .NET к обычному коду и канал от обычного кода к .NET, создаём потоки (на этот раз – которые Thread) и начинаем обмениваться данными.

  Муторно? Согласен. Но с организационной точки зрения, так было проще всего. Иначе пришлось бы либо покупать библиотеку для работы с SSH, либо писать свою, что вышло бы сложнее. По крайней мере, так мне сказали.

  6. Заключение

  Мы рассмотрели механизмы, позволяющие пробросить порты UART из ОС Linux в ОС Windows. Именно на таком методе реализован проброс портов и в сервисе All-Hardware, но для полной унификации ещё разработан драйвер виртуального порта. Поэтому все программы, которые работают с COM-портом, смогут работать и с проброшенным портом, как будто он установлен на локальной Windows-машине.

  Пользуясь описанными методиками, пользователи смогут подключаться к нашему сервису, не устанавливая драйвера.

  А лично автор при подготовке данной статьи почерпнул вещь, никак не связанную с её темой. В скриптах есть запись вида:
  anyUtility 2>log.txt

  Оказывается, это всё работает даже в Windows (не само перенаправление, а именно перенаправление с двойкой). Теперь автор умеет сохранять перечень ошибок, выдаваемых GNU компилятором, в файл. Перенаправлять поток надо именно так. Как учит народная мудрость: «Век живи – век учись».

  Источник

  Читайте также:  Обновление приостановлено windows 10