{
  "index": 335,
  "slug": "editorial-2018-09-mechanism-windows-dev-env",
  "title": "Windows: почему одна команда запускает не тот бинарник",
  "excerpt": "PowerShell выбирает команду из нескольких слоёв: профиля, alias, функций, PATH и PATHEXT. Разбираем, как увидеть фактический выбор, отделить кодировку консоли и проверить гипотезу без глобальной правки системы.",
  "contentHtml": "<p><strong>Симптом:</strong> в одной консоли <code>node --version</code> показывает ожидаемую версию, а в другой — старую. Иногда команда отрабатывает, но русское сообщение превращается в нечитаемые символы. Цена ошибки — не только одна неудачная сборка. Можно исправить не тот <code>node.exe</code>, повредить текстовый файл или навсегда засорить системный <code>PATH</code> ради разовой проверки.</p>\n<p>Имя команды не равно конкретному файлу. PowerShell учитывает команды текущей сессии, затем ищет приложения через переменные среды. Кодировка вывода живёт рядом, но не управляет выбором бинарника. Эти слои надо проверять раздельно.</p>\n<h2>Тезис: сначала докажите, что именно запустилось</h2>\n<p>Первый вопрос диагностики: какой объект получил это имя в текущем процессе? Им может оказаться alias, функция, cmdlet, скрипт или приложение. Только последний вариант связывает команду с файлом на диске.</p>\n<p><code>PATH</code> задаёт каталоги для поиска исполняемых файлов. В Windows каталоги разделяет точка с запятой. <code>PATHEXT</code> перечисляет расширения, которые оболочка считает исполняемыми. Поэтому команда без расширения может привести к <code>tool.exe</code> или <code>tool.cmd</code>. До поиска в <code>PATH</code> PowerShell может выбрать функцию или alias с тем же именем.</p>\n<h2>Механизм процесса и наследование</h2>\n<p>Каждый процесс получает собственный набор переменных среды. Дочерний процесс наследует копию от родителя. Если в PowerShell выполнить <code>$env:Path = ...</code>, изменится текущая сессия и программы, запущенные из неё. Системные настройки от этого не меняются.</p>\n<p>Изменение в окне настроек Windows не обновляет уже открытый терминал. Новая консоль получит новое значение, старая продолжит работать со старым. Поэтому после правки нужно открыть новый процесс. Иначе проверка сравнивает ожидание с устаревшим снимком.</p>\n<figure><img src='/assets/editorial/2018/windows-dev-env-resolution-2018.svg' alt='Схема выбора команды в PowerShell: процесс получает PATH и PATHEXT, Get-Command показывает команды, where.exe ищет файлы, а кодовая страница проверяется отдельно' /><figcaption>Путь к бинарнику и отображение текста — две ветви одной диагностики. Совпадение версии не доказывает, что консоль правильно прочитала файл.</figcaption></figure>\n<h2>Get-Command и where.exe отвечают на разные вопросы</h2>\n<p><code>Get-Command -Name node -All</code> показывает все найденные команды в порядке приоритета PowerShell. Колонка <code>CommandType</code> отделяет приложение от функции, alias, cmdlet и скрипта. Первый элемент — кандидат, который оболочка выберет при обычном вводе имени.</p>\n<p><code>where.exe node</code> ищет файлы в текущем каталоге и каталогах из <code>PATH</code>. Он полезен для инвентаризации физических файлов, но не видит функцию из профиля PowerShell и не описывает полный приоритет оболочки. Поэтому одна команда не заменяет другую.</p>\n<pre><code>$names = @('node', 'npm', 'php', 'git')\nforeach ($name in $names) {\n  Write-Host ('== ' + $name + ' ==')\n  Get-Command -Name $name -All -ErrorAction SilentlyContinue |\n    Select-Object CommandType, Name, Version, Source, Definition |\n    Format-Table -AutoSize\n  where.exe $name 2&gt;$null\n  if (Get-Command -Name $name -ErrorAction SilentlyContinue) {\n    &amp; $name --version\n    Write-Host ('exitCode=' + $LASTEXITCODE)\n  }\n}</code></pre>\n<p>Учебный пример показывает способ наблюдения, а не production-результат. В реальном проекте список должен соответствовать README и lock-файлам. Аргумент <code>--version</code> подходит не каждой утилите. Для такой команды укажите документированный аргумент.</p>\n<h2>Проверка гипотезы через процессный PATH</h2>\n<p>Безопасная гипотеза звучит так: проект запускает старый файл, потому что он раньше нужного каталога в <code>PATH</code>. Её проверяют в текущем процессе, не меняя системные настройки.</p>\n<pre><code>$requiredTools = 'C:\\Tools\\node-20'\nif (-not (Test-Path (Join-Path $requiredTools 'node.exe'))) {\n  throw ('Нет node.exe: ' + $requiredTools)\n}\n$env:Path = $requiredTools + ';' + $env:Path\nGet-Command node -All | Select-Object CommandType, Definition, Version\nnode --version\n# Затем повторяется исходная команда проекта.</code></pre>\n<p>Путь в примере условный. Его нельзя копировать без требования проекта и проверки файла. Команды меняют только текущий PowerShell. Если версия и исходная ошибка не изменились, гипотеза не подтверждена. Окно можно закрыть без отката постоянных настроек.</p>\n<h2>Кодовая страница — отдельная ветвь</h2>\n<p><code>chcp</code> показывает активную кодовую страницу консоли. <code>[Console]::OutputEncoding.WebName</code> показывает настройку вывода .NET. Кодировка сохранённого файла — третья сущность. Она может не совпадать ни с одной из двух.</p>\n<p>Нечитаемый текст только в одной консоли не доказывает неправильный бинарник. Сначала зафиксируйте кодовую страницу, настройку вывода и байты конкретного файла. Не переключайте системный язык и не добавляйте UTF-8 в глобальные настройки до проверки. Старое приложение может ожидать другую кодировку.</p>\n<pre><code>&amp; cmd.exe /d /c chcp\n[Console]::OutputEncoding.WebName\n[Text.Encoding]::Default.WebName\n$env:Path = 'C:\\Tools\\node-20;' + $env:Path\nGet-Command node -All\nnode --version</code></pre>\n<p>Эти команды дают снимок процесса и консоли. Они не исправляют кодировку файла и не доказывают совместимость всей сборки. Если проблема относится к файлу, откройте его байты или настройку конкретной программы. Если к выводу — повторите запуск в новом процессе.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td><code>node --version</code> показывает старую версию</td><td>Другой кандидат стоит раньше в <code>PATH</code></td><td><code>Get-Command node -All</code> и <code>where.exe node</code></td><td>Временно поставить документированный каталог первым</td></tr><tr><td><code>where.exe</code> показывает файлы, но запускается функция</td><td>Профиль перекрывает приложение</td><td><code>CommandType</code> и запуск с <code>-NoProfile</code></td><td>Проверить профиль, не менять <code>PATH</code> наугад</td></tr><tr><td>Русский вывод нечитаем только в одной консоли</td><td>Различается кодовая страница или OutputEncoding</td><td><code>chcp</code> и свойства <code>Console</code></td><td>Сравнить новый процесс и кодировку файла</td></tr><tr><td>После правки результат прежний</td><td>Работает старый процесс</td><td>Новая сессия без профиля</td><td>Повторить исходную команду в новом окне</td></tr><tr><td>Версия совпала, но сборка падает</td><td>Причина в lock-файле, правах, DLL или сети</td><td>Полный лог следующей ошибки</td><td>Прекратить правку <code>PATH</code></td></tr></tbody></table></div>\n<h2>Порядок действий</h2>\n<ol><li>Сохраните точную команду, каталог запуска, commit и полный текст ошибки. Не меняйте систему до первого снимка.</li><li>В той же консоли выполните <code>Get-Command -All</code>, <code>where.exe</code> и команду версии.</li><li>Откройте новый PowerShell с <code>-NoProfile</code> и повторите наблюдения.</li><li>Если расходится путь, добавьте нужный каталог только в <code>$env:Path</code> текущего процесса.</li><li>Повторите исходную команду и запишите версию, ошибку и код возврата.</li><li>Если текст расходится, отдельно зафиксируйте <code>chcp</code>, <code>OutputEncoding</code> и кодировку файла.</li><li>Постоянную настройку меняйте только после подтверждённого временного опыта и опишите требование в README.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Совпадение команды, пути и версии не делает машины одинаковыми. На результат влияют разрядность, DLL, права, антивирус, прокси, кеш, локальные файлы и политика выполнения. Не отключайте защиту и не переустанавливайте Windows, пока отдельное наблюдение не укажет на такую причину.</p>\n<p><code>chcp 65001</code> не является универсальным решением. Старые программы могут читать ввод и писать вывод по собственным правилам. Если смена кодовой страницы не меняет симптом, вернитесь к байтам файла и API чтения. Если временный <code>PATH</code> не меняет сборку, перестаньте редактировать <code>PATH</code>.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Диагностика завершена, когда можно показать, какой объект выбран, какой файл напечатал проверенную версию и какая кодировка относится к проблемному тексту. После исправления новый PowerShell повторяет исходную команду с тем же commit, получает требуемую версию и не возвращает исходную ошибку. Если совпала только версия, готовность не достигнута.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/get-command?view=powershell-7.6' target='_blank' rel='noopener noreferrer'>Microsoft Learn: Get-Command и параметр -All</a></li><li><a href='https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-7.6' target='_blank' rel='noopener noreferrer'>Microsoft Learn: about_Environment_Variables</a></li><li><a href='https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp' target='_blank' rel='noopener noreferrer'>Microsoft Learn: команда chcp</a></li></ul>"
}