Как открыть командную строку в windows 7, 8, 10

Скромное начало: ms-dos

На заре компьютерной индустрии управление большинством компьютеров осуществлялось путём ввода команд в командной строке. За рыночную долю боролись компьютеры под Unix, CP/M, DR-DOS и других. В итоге система MS-DOS стала стандартом де-факто для IBM PC и всех совместимых компьютеров:

MS-DOS 6.0

Как и большинство основных операционных систем того времени, интерпретатор командной строки или «оболочка» в MS-DOS предоставляла простой, но относительно эффективный набор команд и синтаксис командных скриптов для написания batch-файлов (.bat).

Предприятия крупного и малого бизнеса очень быстро взяли на вооружение MS-DOS и в совокупности создали многие миллионы скриптов, некоторые из которых всё ещё используются сегодня! Batch-скрипты применяются для автоматизации настройки ПК, установки/изменения параметров безопасности, обновления программного обеспечения, сборки кода и т.д.

Вы редко или никогда не увидите реальную работу такого скрипта, потому что многие из них выполняются в фоновом режиме, например, при авторизации на компьютере. Но сотни миллиардов скриптов командной строки и команд выполняются каждый день только на Windows!

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

Требуется более удобный и ориентированный на производительность пользовательский интерфейс.

Так что внутри консоли windows?

До Windows 7 инстансы консоли Windows размещались в критически важной подсистеме

! Но в Windows 7 из соображений безопасности и надёжности консоль переместили из CSRSS в следующие бинарники:

• conhost.exe — пользовательский режим консоли Windows UX и механика командной строки
• condrv.sys — драйвер ядра Windows, обеспечивающий коммуникации между conhost и одной или несколькими оболочками командной строки/инструментами/приложениями

Высокоуровневая схема текущей внутренней архитектуры консоли выглядит следующим образом:

Ядро консоли состоит из следующих компонентов (снизу вверх):

• ConDrv.sys — драйвер режима ядра
• ConHost.exe — приложение Win32 GUI:
  • ConHost Core — внутренности и механика
    • Сервер API: преобразует сообщения IOCTL, полученные из приложений командной строки, в вызовы API и отправляет текстовые записи из консоли в приложение командной строки
    • API: реализует консольный API Win32 и логику для всех операций, которые консоль может попросить выполнить
    • Буфер ввода: хранит записи событий клавиатуры и мыши, генерируемые пользовательским вводом
    • VT Parser: если включен, анализирует последовательности VT, извлекает их из текста и генерирует эквивалентные вызовы API
    • Буфер вывода: хранит текст, отображаемый на дисплее консоли. По сути, это 2D-массив структур CHAR_INFO, которые содержат символьные данные и атрибуты каждой ячейки (подробнее о буфере ниже)
    • Другое: в схему не включены инфраструктура сохранения/извлечения значений из реестра и/или файлов ярлыков и т.д.
  • Console UX App Services — слой UX и UI

В windows всё является объектом

Когда проектировалась

, «объекты» рассматривались как будущее в разработке программного обеспечения: «объектно-ориентированные» языки программирования появлялись быстрее, чем тараканы: Simula и Smalltalk уже зарекомендовали себя, а C набирал популярность. За ними последовали другие

, в том числе Python, Eiffel, Objective-C, ObjectPascal/Delphi, Java, C# и многие другие.

Результат предсказуем. Созданная в те пьянящие, объектно-ориентированные дни (около 1989 года) Windows NT разработана с философией, что «всё является объектом». На самом деле одной из самых важных частей ядра NT является Менеджер объектов!

Windows NT предоставляет богатый набор Win32 API для получения и/или управления объектами ОС. Разработчики используют Win32 API для сбора и представления информации, похожей на данные из псевдофайлов и инструментов *NIX, только через объекты и структуры.

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

Итак, возвращаясь к основной дискуссии о консоли Windows: команда NT решила построить «консоль», отличную от традиционного терминала *NIX в нескольких ключевых областях:

Выполнение каких либо действий в заданный интервал времени.

Речь пойдет не о запуске командного файла в определенное время, а
о выполнении какой-то его части только в определенный интервал времени,
например, с 10:00 до 12:00. Решения данной задачи потребует сравнения
текущего времени с указанным промежутком.

Для примера, создадим командный
файл, выполняющий запуск стандартного калькулятора Windows , только в том
случае, если он выполняется в интервале времени от 10:00 до 12:00. Необходимо
получить текущее время и выполнить проверку того, что оно не больше 12:00 и
не меньше 10:00 .Команда IF позволяет выполнить сравнение строк
при использовании формата:

IF /I строка1 оператор_сравнения строка2 команда

где оператор_сравнения принимает следующие значения:

EQU – равно

NEQ – не равно

LSS – меньше

LEQ – меньше или равно

GTR – больше

GEQ – больше или равно

а ключ /I, если он указан, задает сравнение текстовых строк без учета
регистра. Этот обычно используется для сравнения текстовых строк в
форме строка1==строка2. Сравнения проводятся по общему типу данных,
так что если строки 1 и 2 содержат только цифры, то обе строки преобразуются в
числа, после чего выполняется их сравнение.

REM Время меньше 12:00 – перейти на анализ второго условия, иначе – выход

if %time:~0,2% lss 12 goto tst2

exit

:tst2

Rem Время больше 10:00 – перейти к выполнению, меньше – завершить командный файл выполнив exit

if %time:~0,2% gtr 10 goto excalc

exit

:excalc

calc.exe

Подобным же образом можно организовать проверку по дате, учитывая тот факт, что для данного способа
сравнения необходимо использовать только числовые значения из переменных.

Горячие клавиши

Начнем с горячих клавиш, ведь сначала необходимо изучить, что нам может дать рабочая среда.

F1 — В консоли эта клавиша работает в точности как и стрелка вправо, т.е. выводит по одному символу из последней введенной (либо выбранной в истории) команды.F2 <символ> — Выводит последнюю введенную команду до указанного символа. Например, если последняя введенная вами команда выглядела вот так:

ping 192.168.25.1

то после нажатия комбинации клавиш

F2 5

вы получите:

ping 192.168.2

F3

— Выводит последнюю, и только последнюю, в истории команду целиком.

F5

— Выводит последние введенные команды по порядку, также как и стрелка вверх.

F6

— Вставляет символ EOF на текущую позицию командной строки, что аналогично нажатию комбинации Ctrl Z.

F7

— Диалоговое окно, содержащее историю команд.

Alt F7

— Очищает историю команд.

— Перебирает команды, которые начинаются с символов уже введенных в командную строку.

Если перед нажатием

F8

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

F9 <число>

— Вставляет команду из истории под соответствующим номером. К примеру, в ситуации приведенной на скрине выше при нажатии комбинации

F9 4

в консоли появится:

ipconfig

Графический интерфейс идёт в мейнстрим

Добро пожаловать в

, изобретённый в

Вскоре после изобретения появилось много конкурирующих GUI на компьютерах Lisa и Macintosh от Apple, Commodore Amiga (Workbench), Atari ST (DRI GEM), Acorn Archimedes (Arthur/RISC OS), Sun Workstation, X11/X Windows и многих других, в том числе Microsoft Windows.

Windows 1.0 вышла в 1985 году и являлась по сути приложением MS-DOS, которое предоставляло простое окружение GUI с плиточным окном, позволяя пользователям запускать несколько приложений бок о бок:

Windows 1.01 на MS-DOS

Windows 2.x, 3.x, 95 и 98 работали на базе MS-DOS. Более поздние версии Windows начали заменять некоторые функции MS-DOS альтернативами Windows (например, операции с файловой системой), но все они полагались на фундамент MS-DOS.

Примечание: Windows ME (Millennium Edition) стала интересным гибридом. В ней наконец-то заменили поддержку MS-DOS и поддержку реального режима из предыдущих версий Windows несколькими новыми функциями (особенно технологии Gaming & Media). Некоторые функции позаимствованы из Windows 2000 (например, новый стек TCP/IP), но настроены для работы на домашних ПК, которым трудно запустить полноценную NT.

Но Microsoft понимала, что не может бесконечно растягивать архитектуру и возможности MS-DOS и Windows. Требовалась новая операционная система с прицелом на будущее.

Давным-давно в далёкой-далёкой серверной…

С первых дней развития информатики людям нужен был эффективный способ передавать компьютеру команды и данные и видеть результат выполнения этих команд/вычислений.

Одним из первых по-настоящему эффективных человеко-машинных интерфейсов стал Tele-Typewriter или «телетайп». Это электромеханическая машина с клавиатурой для ввода данных и каким-нибудь устройством вывода — сначала использовался принтер, позже экран.

Вводимые оператором символы локально буферизуются и отправляются с телетайпа на соседний компьютер или мейнфрейм в виде серии сигналов по электрическому кабелю (например, RS-232) со скоростью 10 символов в секунду (110 бод, бит в секунду, bps):

Телетайп Model 33 ASRПримечание: Дэвид Гессвейн ведёт отличный сайт по PDP-8, где можно найти больше информации об ASR33 (и соответствующей технологии PDP-8), в том числе фотографии, видео и др.

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

Затем технология улучшилась, скорость передачи выросла до 19200 bps, а шумные и дорогие принтеры заменили ЭЛТ-дисплеями (широко распространённый тип дисплеев в 80-е и 90-е годы), как на популярном терминале DEC VT100:

Терминал DEC VT100

Хотя технология улучшилась, но эта модель — терминал отправляет символы программе на компьютере, а он выдаёт текст для пользователя — осталась и сегодня как фундаментальная модель взаимодействия всех командных строк и консолей на всех платформах!

Архитектура терминала и командной строки

Модель по-своему элегантна. Одна из причин — в сохранении простоты и цельности каждого компонента: клавиатура выдаёт символы которые буферизуются как электрические сигналы. Устройство вывода просто выдаёт на дисплей (бумагу/экран) символы, полученные с компьютера.

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

Изучение системной информации

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

• NOW — отображает текущую системную дату и время в 24-часовом формате, например Sal May 9 12:30:45 2003. Доступна только в Windows Server 2003 Resource Kit;
• WHOAMI — сообщает имя пользователя, зарегистрированного в системе на данный момент, например adatumadmi-nistrator;
• WHERE — выполняет поиск файлов по шаблону поиска (search pattern) и возвращает список совпавших результатов.

Чтобы использовать NOW или WHOAMI, просто введите команду в окне командной оболочки и нажмите Enter. Наиболее распространенный синтаксис для WHERE выглядит так:

  
  where /r базовый_каталог_имя_файла

Здесь параметр /r указан для рекурсивного поиска, начиная от указанного каталога (базовый_каталог) и включая все его подкаталоги, а имя_файла — полное или частичное имя искомого файла, которое может включать символы подстановки (wildcards): знак ? заменяет один символ, а знак * — группу символов, например data???.txt или data*.*.

   
  where /r C: data*.txt

Также можно найти файлы всех типов, имена которых начинаются с data:

   
  where /r C: data*.*

Иногда нужно получить информацию о конфигурации системы или о системном окружении. В критически важных системах эту информацию можно сохранить или распечатать для справки. Ниже перечислены команды, позволяющие собирать информацию о системе.

• DRIVERQUERY — выводит список всех установленных драйверов устройств и их свойства, в том числе имя модуля (module name), отображаемое имя (display name), тип драйвера и дату сборки (driver link date). В режиме отображения всей информации (/V) сообщается статус (status) и состояние (state) драйвера, режим запуска, сведения об использовании памяти и путь в файловой системе. Параметр /V также включает вывод детальной информации обо всех неподписанных драйверах.
• SYSTEMINFO — выдает подробную информацию о конфигурации системы, в том числе сведения о версии, типе и изготовителе операционной системы, процессоре, версии BIOS, объеме памяти, региональных стандартах, часовом поясе и конфигурации сетевого адаптера.
• NLSINFO — отображает подробную информацию о региональных стандартах, включая язык по умолчанию (default language), кодовую страницу Windows, форматы отображения времени и чисел, часовой пояс и установленные кодовые страницы. Эта команда доступна лишь в Windows Server 2003 Resource Kit.

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

Итак, на чём мы остановились?

Дорогой читатель, если вы прочитали всё вышенаписанное, спасибо вам, и примите поздравления — теперь вы знаете больше о консоли Windows, чем большинство ваших друзей, и, вероятно, даже больше, чем вы

сами

хотели узнать! Какая удача!

Мы многое рассмотрели в этой статье:

• Основные строительные блоки консоли Windows:
  • Condrv.sys — коммуникационный драйвер
  • ConHost.ехе — UX консоли и механика:
    • Сервер API — сериализует вызовы API и текстовые данные с помощью сообщений IOCTL, отправляемых в/из драйвера
    • API — функциональность консоли
    • Буферы — буфер ввода, хранящий пользовательский ввод, и буфер вывода, хранящий выходной/отображаемый текст
    • Парсер VT — преобразует последовательности ANSI/VT из текстового потока в вызовы API
    • UX консоли — состояние UI консоли, настройки, функции
    • Другое — технические данные, безопасность и проч.
• Что делает консоль
  • Отправляет пользовательский ввод в подключенное приложение командной строки
  • Получает и отображает выходные данные из подключенного приложения командной строки
• Чем консоль отличается от терминалов *NIX
  • NIX: «Всё представляет собой файл/текстовый поток»
  • Windows: «Все представляет собой объект, доступный через API»
• Проблемы консоли
  • Консольные приложения и приложения командной строки взаимодействуют через запросы вызовов API и текст, сериализованный в Сообщения IOCTL
  • Консольный API могут вызвать только приложения командной строки Windows
    • Сложнее портировать приложения на/из Windows
  • Приложения взаимодействуют с консолью через Windows API
    • Затрудняет удалённое взаимодействие с приложениями и средствами командной строки Windows
  • Зависимость от IOCTL нарушает схему «обмен символами» терминала
    • Затрудняет эксплуатацию инструментов командной строки удалённого с не-Windows машин
  • Запуск приложений командной строки Windows является «необычным»
    • К приложениям командной строки можно присоединить только ConHost.exe
    • Сторонние терминалы вынуждены создавать внеэкранную консоль, отправлять туда символы и скрапить экран
  • Windows исторически не понимает последовательности ANSI/VT
    • В основном исправлено в Windows 10
  • У консоли ограниченная поддержка Юникода и в настоящее время проблемы с хранением и рендерингом UTF-8 и глифов, которые нуждаются в соединительных символах нулевой ширины

В следующих нескольких статьях этой серии мы более подробно разберём консоль и обсудим решение этих проблем… и не только!

Как всегда, следите за обновлениями.

Обработка юникода

К сожалению, консоль Windows и её API появились до изобретения Юникода!

Консоль Windows хранит текст (который впоследствии выводится на экран) как символы кодировки UCS-2 с двумя байтами на символ. Эта кодировка поддерживает кодирование первых 65536 позиций символов, что известно как плоскость 0 или основная многоязычная плоскость (Basic Multilingual Plane, BMP).

Приложения командной строки выводят текст в консоли с помощью Console API. Обрабатывающие текст интерфейсы, бывают двух видов: функции с суффиксом А обрабатывают однобайтовые/символьные строки, функции с суффиксом W обрабатывают двухбайтовые (wchar)/символьные строки.

Например, функция WriteConsoleOutputCharacter компилируется в WriteConsoleOutputCharacterA() для проектов ASCII или в WriteConsoleOutputCharacterW() для проектов на Юникоде. Код может напрямую вызвать функцию с суффиксом …A или …W, если необходима обработка конкретного типа.

Примечание: каждый W API поддерживает UCS-2, потому что это всё, что существовало в момент разделения на A/W, и мы думали, что так будет хорошо. Но многие W API уже обновились для поддержки ещё и UTF-16 на том же канале.

Не все W API понимают UTF-16, но все они знают хотя бы UCS-2.

Кроме того, консоль не поддерживает некоторые новые функции Юникода, включая соединительные символы нулевой ширины (

), которые используются для объединения отдельных символов в арабских и индийских письменностях, а также для объединения символов эмодзи в один визуальный глиф.

Как же ввести эмодзи кота-ниндзя или сложные многобайтовые китайские/арабские символы в консоль? К сожалению, никак!

Мало того что консольный API не поддерживает символы Юникод больше двух байт на глиф (эмодзи NinjaCat требует 8 байт!), но внутренний буфер UCS-2 консоли тоже не может хранить дополнительные байты данных. Что ещё хуже, текущий GDI-рендерер консоли не сможет отрисовать глиф, даже если тот поместится в буфер!

Эх… Таковы радости legacy-кода.

Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье. Оставайтесь с нами!

Перезагрузка и капитальный ремонт windows console

В конце 2021 года проект по созданию подсистемы Windows для Linux (WSL) шёл полным ходом, и на фоне взрыва оживлённого интереса пользователей к командной строке стало очевидно, что консоль Windows явно нуждается в некотором апгрейде.

В частности, консоли не хватало многих функций, привычных для современных *NIX-совместимых систем, таких как возможность парсинга и вывода последовательностей ANSI/VT, широко используемых в мире *NIX для вывода насыщенного и подсвеченного текста и текстовых UI.

В чём тогда смысл разработки WSL, если пользователь не сможет корректно использовать инструменты Linux?

Ниже пример того, что отображает консоль Windows 7 и Windows 10: обратите внимание, что Windows 7 (слева) не в состоянии правильно отобразить VT, сгенерированный линуксовыми программами tmux, htop, Midnight Commander и cowsay, но они корректно выглядят в Windows 10 (справа):

Сравнение консоли Windows 7 и Windows 10

Так, в 2021 году была сформирована небольшая «группа Windows Console». На неё возложили задачу распутать, понять и улучшить кодовую базу Windows Console… которой к этому времени было около 28 лет — больше, чем программистам, которые работают над этим проектом.

Как подтвердит любой разработчик, которому когда-либо приходилось брать старый, грязный, плохо поддерживаемый код, улучшение такого кода представляет собой сложную задачу. Ещё сложнее не нарушить существующее поведение. Для обновления самой часто запускаемой программы в Windows, не нарушив работу миллионов клиентских скриптов, инструментов, скриптов авторизации, систем сборки, производственных систем, систем анализа и прочих, требуется немало «внимания и терпения». 😉

Для разработчиков проблема усугубилась, когда они поняли всю строгость требований к консоли со стороны клиентов. Например, если производительность консоли изменялась на 1−2% от сборки к сборке, то срабатывали сигналы тревоги в группе Windows Build, что приводило… гм… к «быстрой и прямой обратной связи», то есть требованию немедленного исправления.

Итак, когда мы будем обсуждать улучшения консоли и новые функции, помните, что есть несколько незыблемых принципов, которым должно соответствовать каждое изменение, в том числе:

1. НЕ допускать новых уязвимостей
2. НЕ ломать инструменты, скрипты, команды и т. д. у существующих клиентов (внутренних или внешних)
3. НЕ снижать производительность и не увеличивать потребление памяти/IO (без чётких и хорошо доведённых причин)

За последние три года команда Windows Console провела следующую работу:

И работа продолжается! В настоящее время мы завершаем реализацию нескольких захватывающих новых функций.

К чему был этот урок истории?

Я надеюсь, вы поняли, что командная строка остаётся ключевым компонентом стратегии, платформы и экосистемы Microsoft.

Хотя для конечных пользователей Microsoft продвигала графический интерфейс, сама компания и её технические клиенты/пользователи/партнёры в значительной степени полагались на командную строку для выполнения множества технических задач.

На самом деле Microsoft буквально не смогла бы создать ни Windows, ни любой другой из своих программных продуктов без быстрой, эффективной, стабильной и безопасной консоли!

На протяжении эпох MS-DOS, Unix, OS/2 и Windows командная строка оставалась, пожалуй, самым важным инструментом в наборе инструментов каждого технического пользователя. Даже многие пользователи, которые никогда не вводили команды в окно, в реальности используют консоль каждый день!

Переходы и метки.

В командных файлах можно использовать команды условного перехода,
меняющие логику их работы в зависимости от возникновения определенных условий.
В качестве иллюстрации создадим командный
файл, целью которого будет присвоение заранее определенной буквы для
съемных носителей.

Условия таковы – есть 2 съемных диска, один из которых должен быть виден в проводнике как диск X: а второй – как диск Y: независимо от того, в какой
порт USB они подключены и какие буквы присвоены им операционной системой.
Для примера, будем считать, что реальные диски могут быть подключены как F: или G:

Flashd1.let – на первом диске

Flashd2.let – на втором

Таким образом, задача командного файла заключается в том, чтобы проверить
наличие на сменных дисках F: и G: файлов Flashd1.let
или Flashd2.let и, в зависимости от того, какой из них присутствует,
присвоить диску букву X: или Y:

Для поиска файла на диске воспользуемся командой IF EXIST:

IF EXIST имя_файла команда

В качестве команды, которая будет выполнена при удовлетворении условия используем SUBST, которая предназначена для сопоставления каталога и виртуального диска.

SUBST X: C: – – создать виртуальный диск
X:, содержимым которого будет корневой каталог диска C:

   
Для решения поставленной задачи, создаем командный файл, например с именем setletter.bat, следующего содержания:

Подсистема windows для linux (wsl)

Основанные на GNU/Linux «дистрибутивы» (сочетания ядра Linux и коллекций инструментов пользовательского режима) становятся всё популярнее, особенно на серверах и в облаке. Хотя в Windows имелась POSIX-совместимая среда выполнения, но SFU не мог запускать многие инструменты и двоичные файлы Linux из-за дополнительных системных вызовов и различий в поведении по сравнению с традиционной Unix/POSIX.

После анализа обратной связи от разработчиков и технически подкованных пользователей Windows, а также в связи с растущим спросом внутри самой Microsoft, компания изучила несколько вариантов, и в конечном итоге решила позволить на Windows запуск оригинальных немодифицированных бинарных файлов Linux!

В середине 2021 года Microsoft сформировала группу разработки того, что станет подсистемой Windows для Linux (WSL). WSL впервые анонсировали в сборке Build 2021, а вскоре предварительная версия вышла на канале Windows 10 Insider.

С тех пор WSL обновляется в большинстве инсайдерских сборок и в каждом крупном выпуске ОС с момента Anniversary Update осенью 2021 года. В каждой новой версии увеличивается функциональность, совместимость и стабильность WSL: в первой версии это был интересный эксперимент, который мог запускать лишь несколько распространённых программ Linux.

Сегодня (середина 2021 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.

Команда WSL продолжает улучшать WSL в части выполнения задач Linux, повышения производительности и интеграции с Windows.

Поиск в локальной сети включенных компьютеров.

В данном примере речь идет о создании командного файла, позволяющего “собрать” список IP-адресов узлов локальной сети, включенных на данный момент времени. Ничего принципиально нового в плане создания командных файлов здесь нет, но тем не менее, задача поиска включенных узлов в локальной сети встречается довольно часто, и решить ее описанными выше способами, с использованием ping.exe и net view удается далеко не всегда, поскольку в современных версиях операционных систем семейства Windows настройки брандмауэров по умолчанию, задают довольно жесткие правила, блокирующие сетевые соединения извне, и ответы на эхо-запрос.

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

При любой передаче пакетов IP-протокола с данного компьютера на IP-адрес другого сетевого устройства в локальной сети, программные средства сетевых протоколов выполняют процедуру определения физического адреса сетевого адаптера получателя ( MAC-адрес получателя).

Всем сетевым устройствам отправляется специальный широковещательный запрос ( запрос который будет принят всеми компьютерами данной подсети), означающий “чей MAC – адрес соответствует такому-то IP-адресу”. Если какое-либо сетевое устройство опознало свой собственный IP-адрес, оно отправит ARP-ответ, содержащий соответствующий MAC-адрес, который будет сохранен в специальной таблице соответствия адресов IP и MAC, хранящейся в оперативной памяти компьютера, отправившего ARP-запрос.

Запись информации в данную таблицу выполняется только при необходимости передачи любых данных по протоколу IP, что можно инициировать, например, пингованием опрашиваемого устройства. Даже если настройками брандмауэра полностью закрыты все соединения извне и блокируется протокол ICMP ( устройство не «пингуется» ) , в буферной памяти сервиса
ARP будет присутствовать запись соответствия IP и MAC, если устройство было подключено к локальной сети и участвовало в процедуре разрешения адреса .

Для просмотра содержимого ARP-кэш можно воспользоваться командой

arp -a – отобразить все записи в таблице ARP

Пример отображения таблицы ARP:

Интерфейс: 192.168.0.29 — 0xa

адрес в Интернете Физический адрес Тип

192.168.0.1 00-1e-13-d6-80-00 динамический

192.168.0.3 60-eb-69-08-18-d2 динамический

. . .

Интерфейс: 192.168.234.1 — 0xf

адрес в Интернете Физический адрес Тип

192.168.234.255 ff-ff-ff-ff-ff-ff статический

224.0.0.22 01-00-5e-00-00-16 статический

224.0.0.252 01-00-5e-00-00-fc статический

239.255.255.250 01-00-5e-7f-ff-fa статический

Как видно из приведенной таблицы, например IP – адресу 192.168.0.1 соответствует физический адрес сетевого адаптера, равный 00-1e-13-d6-80-00 . Если же сетевой адаптер с данным адресом будет недоступен, то такой записи в таблице не будет.

Для понимания алгоритма опроса сети необходимо учесть следующее:

Разрешение адресов ARP используется только при передаче данных по IP-протоколу в пределах сегмента локальной сети, задаваемого маской. Так, например, для примера с IP адресом 192.168.0.1 и маски 255.255.255.0 это будет диапазон IP от 192.168.0.1 до 192.168.0.254.

Работа с графическими приложениями windows.

Допустим, вам нужно из одного и того же командного файла запустить notepad.exe
и cmd.exe. Если просто вставить строкиnotepad.execmd.exeто после запуска notepad.exe выполнение командного файла приостановится и пока не
будет завершен notepad, cmd.exe не запустится.

start /MAX notepad.exestart “This is CMD.EXE” /MIN cmd.exenet send %COMPUTERNAME% NOTEPAD and CMD running.

После выполнения этого командного файла вы увидите стартовавшие, в развернутом окне
(ключ /MAX) блокнот, в свернутом окне (ключ /MIN) командный процессор CMD.EXE и
окно с сообщением net.exe. Стандартный заголовок окна cmd.exe заменен на текст
“This is CMD.EXE”.

Обратите внимание на то что заголовок окна можно опускать, но
особенность обработки входных параметров командой start может привести к
неожиданным результатам при попытке запуска программы, имя или путь которой содержит
пробел(ы). Например при попытке выполнить следующую команду:start “C:

Program FilesFARFAR.EXE”Из-за наличия пробела в пути к исполняемому файлу,
строка для запуска FAR.EXE должна быть заключена в двойные
кавычки, однако формат входных параметров для start предполагает наличие заголовка
окна, также заключаемого в двойные кавычки, в результате чего “C:

Если вам все же потребуется расширенное управление окнами приложений,
придется воспользоваться сторонним программным обеспечением, например, широко известная утилита cmdow.exe

Версия cmdow.zip, используемая при написании этой статьи. ZIP-архив, закрытый паролем novirus

Современная командная строка

Современные компьютеры значительно мощнее «тупых терминалов» прошлого и обычно работают под управлением десктопной ОС (например, Windows, Linux, macOS) с графическим пользовательским интерфейсом (GUI). Такое окружение GUI позволяет нескольким приложениям работать одновременно в отдельных окнах на экране и/или невидимо в фоновом режиме.

Cmd, PowerShell и Ubuntu Linux под WSL работают на независимых инстансах консоли

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

Аналогично и приложения командной строки, к которым подключены терминалы, работают как и раньше: получают входные символы, решают, что делать с этими символами, (необязательно) выполняют работу — и могут выдать текст для отображения пользователю. Только вместо связи по медленным каналам TTY терминальные приложения и приложения командной строки на одной машине общаются по очень скоростным каналам Pseudo Teletype (PTY) в памяти.

Современная командная строка

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

Только для windows

Многие средства командной строки и приложения широко используют

В чём проблема? Они работают только под Windows.

Таким образом, в сочетании с другими различиями (например, в жизненном цикле и т.д.), приложения командной строки Windows не всегда легко переносятся под *NIX и наоборот.

Из-за этого в экосистеме Windows распространены свои собственные, часто похожие, но обычно отличающиеся средства командной строки и приложения. Это означает, что при использовании Windows пользователям приходится изучать один набор приложений и инструментов командной строки, оболочек, языков сценариев и т.д., а при использовании *NIX — другой набор.

У этой проблемы нет простого решения: консоль Windows и командную строку нельзя просто выбросить и заменить на bash и iTerm2 — существуют сотни миллионов приложений и сценариев, которые зависят от консоли Windows и оболочек Cmd/PowerShell.

Сторонние инструменты, такие как Cygwin, отлично переносят многие основные инструменты GNU и библиотеки совместимости в Windows, но не могут запускать непортированные, неизменённые бинарники Linux. Это очень важно, так как многие пакеты и модули Ruby, Python, Node зависят от бинарных файлов Linux и/или зависят от поведения *NIX.

Эти причины привели к тому, что Microsoft расширила совместимость с Windows, разрешив запуск аутентичных двоичных файлов и средств Linux в подсистеме Windows для Linux (WSL). С помощью WSL пользователи теперь могут загружать и устанавливать один или несколько дистрибутивов Linux бок о бок на одной машине, а также использовать apt/zypper/npm/gem/др. для установки и запуска подавляющего большинства инструментов командной строки Linux вместе с их любимыми приложениями и инструментами Windows.

Тем не менее, у нативной консоли остаётся функциональность, которая отсутствует в сторонних терминалах: в частности, Windows Console предоставляет сервисы command-history и command-alias, чтобы каждой оболочке (в частности) не пришлось повторно реализовать одинаковую функциональность.

Часто встречающиеся ошибки при написании командных файлов.

• Командный файл вручную выполняется успешно, но запущенный с помощью планировщика не работает.

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

MYPROG.EXE и если каталог D:SCRIPTS не прописан в путях поиска (переменная PATH ) то модуль MYPROG.EXE может быть найден и выполнен только если текущим каталогом является D:SCRIPTS. Но если вы укажете полный путь к myprog.exe:D:SCRIPTSmyprog.exeто программа будет найдена и выполнена в любом случае.

Кроме того, нередко программа, указанная в командном файле использует для поиска своих компонент (dll, ini и т.п. ) собственный каталог. Но на момент ее выполнения текущим каталогом может быть любой (чаще всего – системный каталог Windows). Естественно, компоненты не находятся и программа не выполняется.

Rem Сменим текущий дискD:Rem перейдем в каталог SCRIPTSCD D:SCRIPTSmyprog.exe

Также для переходов по каталогам можно воспользоваться командами pushd и popd, описание и примеры использования которых имеются в разделе сайта со списком команд Windows.

Неправильно отображаются русские имена файлов, служб и т.п.

Причина в том, что при создании командных файлов вы
использовали текстовый редактор, в котором русские символы представлены
не в DOS-кодировке. Если в приведенном выше примере перезапуска службы “DNS-клиент”
вы используете неверную кодировку, то русская часть имени службы не будет опознана
из-за неверной кодировки и будет выдано сообщение, что указанная служба не
установлена.

Чтобы избежать проблем с русскими символами в командных файлах,
используйте редактор с поддержкой DOS-кодировки, например, встроенный редактор
файлового менеджера Far Manager. Переключение между кодировками в редакторе осуществляется нажатием F8 .

Командный файл выполняется на одном компьютере успешно, но на другом – не работает.

Обычно это вызвано применением в командных файлах абсолютных значений для дисков, файлов и каталогов вместо переменных среды окружения. Вместо C:WINDOWS правильнее использовать %SYSTEMROOT%, потому,
что на другом компьютере система может быть установлена в другой каталог или на другой диск.

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

DIR %ProgramFiles%

не выдаст вам содержимого каталога C:Program Files , поскольку из-за наличия пробела будет
интерпретирована как

DIR C:Program

Командная строкаDIR “%ProgramFiles%”выполнится верно.

    Старайтесь использовать команды Setlocal и Endlocal, чтобы не оставлять мусор
из переменных, созданных или модифицированных командным файлом.

Использование командных файлов в сценариях регистрации
пользователей .

   
Командные файлы
удобно использовать для выполнения каких-либо
действий при регистрации пользователя в
домене. Делается это с помощью вкладки
Profile

свойств пользователя домена.

Сами командные файлы должны
находиться в сетевой папке
Netlogon
(WINDOWSSYSVOL DOMAINSCRIPTS) контроллера домена.

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

Дополнительные материалы по командной строке Windows:

Раздел со списком команд
CMD Windows. Имена большинства команд представляют собой ссылку на
страницы с их описанием и примерами.

Настройка окна командной строки
Windows. Малоизвестные возможности по изменению свойств консоли Windows.

Работа с сетью в
командной строке Windows – Описание и примеры использования
утилит командной строки для работы с сетью.

Запуск командных файлов от имени администратора без запроса UAC – использование планировщика заданий для запуска приложений
от имени Администратора без запроса системы контроля учетных записей UAC.

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

Если вы желаете поделиться ссылкой на эту страницу в своей социальной сети, пользуйтесь кнопкой “Поделиться”

В начало страницы         |        
На главную страницу сайта

Похожее:

Windows 10 1080P, 2K, 4K, 5K HD wallpapers free download | Wallpaper Flare Эквалайзеры. Полное руководство Windows 10 — Wikipedia Republished // WIKI 2 Appwiz.cpl.mui – Как исправить ошибки [РЕШЕНО]