Невозможно диагностировать проблему без дополнительной информации, но, возможно, эти советы по устранению неполадок помогут:
Если вы вызываете внешний исполняемый файл (sam) по только имени, ваша проблема должна заключаться в том, что каталог, в котором находится исполняемый файл resides не указан в $env:PATH переменной среды, определенной для текущего процесса.
Однако возможно, что каталог внешнего sam исполняемого файла не в $env:PATH и что sam является вспомогательной командой PowerShell с тем же именем, что знает истинное местоположение sam и вызывает его за кулисами. Например, можно определить псевдоним, например New-Alias sam 'C:\path\to\sam.exe', или функцию, например function sam { & C:\path\to\sam.exe $args }.
Из сеанса PowerShell, в котором найдено sam :
- Чтобы определить, к какому типу команды относится имя
sam в вашем сеансе, используйте следующее и проверьте значение столбца CommandType:
Get-Command sam
Если тип команды - Application, вы действительно имеете дело с внешним исполняемым файлом, и столбец Source сообщит его полный путь < / strong>, из которого можно определить путь к каталогу исполняемого файла (который можно определить напрямую с помощью Split-Path (Get-Command -Type Application sam).Path
- You then need to diagnose why that directory isn't in
$env:Path in the other session - see first section below.
Если тип команды не Application:
- You need to determine where the auxiliary alias or function is defined and why your other session doesn't see it, which, if the problem is reproducible in new sessions, must be connected to what profile files (as reflected in the automatic
$PROFILE variable) were loaded.
Определите причину отсутствия каталога в $env:PATH:
Возможные причины:
Вы только что установили исполняемый файл, а установщик изменил постоянное определение $env:PATH в реестре.
Что-то в вашем текущем сеансе PowerShell (возможно, случайно) удалило каталог sam из внутрипроцессной переменной $env:PATH.
Решение:
- Refresh the in-process
$env:PATH definition from the registry with the following command (note that any prior in-process modifications are then lost):
$env:PATH = [Environment]::GetEnvironmentVariable('Path', 'Machine') + ';' + [Environment]::GetEnvironmentVariable('Path', 'User')
Если эти решения не помогают (постоянно), проблема должна быть связана с тем, какие файлы профиля загружаются в разные среды - см. Следующий раздел.
Определите, какие файлы профиля были загружены в сеанс:
файлы профиля в PowerShell (по умолчанию) загружаются (с использованием точек) при запуске сеанса и позволяют настраивать сеансы, что может включать такие вещи, как определения пользовательских псевдонимов, функции и даже $env:PATH внутрипроцессные добавления.
Существует несколько файлов профиля, все из которых загружаются (по умолчанию), если они есть, по двум независимым измерениям: все пользователи против текущего пользователя и все- хосты по сравнению с текущим хостом (хост - это среда хоста PowerShell, такая как обычное окно консоли или терминал в Visual Studio Code).
автоматическая $PROFILE переменная сообщает путь к файлу профиля текущего пользователя, текущего хоста, но на самом деле имеет обычно невидимые свойства, перечисляющие все пути (вы можете сделать их видимыми с помощью $PROFILE | select * - см. этот ответ).
Какие профили загружаются в сеанс для данного пользователя, определяется следующими факторами:
По сути, подавляется загрузка профиля полностью с помощью переключателя -NoProfile интерфейса командной строки.
Если не подавлено (по умолчанию, даже при вызовах -Command и -File):
Чтобы увидеть, какая командная строка использовалась для вызова текущего сеанса, выполните следующее:
[Environment]::CommandLine
Примечание:
- В интегрированной консоли PowerShell в Visual Studio Code вы всегда увидите
-NoProfile среди параметров, но профили могут все равно загружаться во время запуска, в зависимости от настроек расширения PowerShell
Из вышесказанного следует, что разные среды хоста загружают разные наборы файлов профилей, а в интегрированной консоли PowerShell, предоставляемой расширением PowerShell Visual Studio Code, < em> разные файлы профиля действительно загружаются (если загрузка включена в настройках) - по сравнению с обычными окнами консоли [1]
Если вы хотите, чтобы ваши интегрированные консоли PowerShell загружали тот же профиль текущего пользователя, что и обычные окна консоли:
В настройках кода Visual Studio убедитесь, что параметр PowerShell: Enable Profile Loading включен.
В интегрированной консоли PowerShell запустите psedit $PROFILE, чтобы открыть профиль текущего пользователя для конкретного хоста для редактирования.
Добавьте следующий контент:
. ($PROFILE -replace '\.VSCode', '.PowerShell')
[1] Обратите внимание, что вы можете использовать PowerShell в терминале Visual Studio Code даже без расширения PowerShell, и такой сеанс действительно использует те же профили, что и обычные окна консоли. - см. этот ответ.
person
mklement0
schedule
16.07.2021
