Powershell: Powershell -WindowStyle Hidden по-прежнему показывает окно на короткое время

powershell.exe - это консольное приложение. Окно консоли автоматически создается ОС при запуске процесса. Таким образом, код powershell.exe, обрабатывающий -WindowStyle Hidden, выполняется после открытия окна консоли, следовательно, и flash. Чтобы исправить это, нам понадобится эквивалент wscript, то есть хост-приложение win32 вместо хост-приложения консоли.

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

http://www.f2ko.de/en/p2e.php
и Power Shell Studio тоже имеет собственный хост

У вас может быть powershellw.exe которое будет приложением с графическим интерфейсом, которое не отображает окно консоли. То же, что и javaw.exe и pythonw.exe .

Может ли pwsh.exe получить поддержку по этому поводу или получить pwshw.exe, как предложено выше? Поскольку этот pwsh exe является новым, похоже, самое время изменить поведение -windowstyle hidden . Никто никогда не использовал hidden и думал: «Ага, это то, что я хотел, прошейте на секунду какой-нибудь экран».

Имеет смысл, что powershell.exe не может быть изменен после всего этого времени и его наследства.

Я бы поддержал вклад сообщества, чтобы добавить pwshw.exe

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

Технически мы могли бы сделать что-то вроде https://github.com/AvaloniaUI/Avalonia/wiki/Hide-console-window-for-self-conolated-.NET-Core-application
c# editbin.exe /subsystem:windows yourapp.exe

Но мне интересно - если PowerShell Core переносится, каково ожидаемое поведение в Unix? Можем ли мы быть едиными на всех платформах?
Связанное обсуждение https://github.com/dotnet/cli/issues/296 Также упоминается, что мы могли бы использовать подсистему GUI.

Может у @ mklement0 есть мысли?

@iSazonov -WindowStyle не поддерживается в операционных системах, отличных от Windows.

Да, я имел в виду - есть ли у нас такое же поведение в Unix при создании консоли? Есть ли у нас сценарии, в которых мы не хотим создавать консоль в Unix?

@iSazonov : Я особо не pwsh незаметно работает из таких утилит, как Alfred 3 и TextExpander.

До сих пор я использовал ярлык PS с целью: C: \ Windows \ System32 \ WindowsPowerShell \ v1.0powershell.exe и опцией Run: Minimized
Как это:
C:\Windows\PS Start-Process .
Панель задач мерцает, но консоли больше нет.

Похоже, что -WindowStyle Hidden должен быть первым параметром вашей командной строки.

Итак, теперь мы начинаем поддерживать Windows PowerShell ??

Просто дружеское напоминание, если это проблема PowerShell Core? Укажите версию PowerShell Core, которая требуется при отправке проблемы.

В противном случае Windows PowerShell необходимо пройти через UserVoice по адресу: https://windowsserver.uservoice.com/forums/301869-powershell.

Для получения дополнительной информации см .: https://github.com/PowerShell/PowerShell#windows -powershell-vs-powershell-core.

:)

@aresowj : хотя размещение аргументов имеет значение при вызове _CLI_ PowerShell (при условии, что все, что следует за -Command , интерпретируется как часть команды для выполнения), (а) попытка OP уже помещает его перед -Command и (b), который не предотвращает мигание по причинам, описанным в предыдущем комментарии @BrucePay .

@MaximoTrinidad : хотя эта проблема могла начаться только с Windows PowerShell, она уже давно трансформировалась в запрос функции PS Core (который также заслуживает обратного переноса на Windows PowerShell).

Напомним: чтобы получить полностью невидимые вызовы через интерфейс командной строки PowerShell:

• В _Windows_ необходим новый отдельный исполняемый файл PowerShell ( pwshw.exe / powershellw.exe ), который представляет собой приложение _GUI_, следуя модели python.exe / pythonw.exe пара

• В macOS и Linux, где проблемы не существует, я _presume_ нет необходимости в отдельном исполняемом файле. Для симметрии с Windows можно реализовать простую _symlink_, которая просто указывает на обычный исполняемый файл pwsh .

Спасибо @ mklement0!
:)

Извините, ребята, ошибочно приняли два Powershell и спасибо за разъяснения. :)

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

@ zero77 Я думаю, мы имеем в виду https://social.msdn.microsoft.com/Forums/en-US/b7a14400-6d72-4fbf-9927-0966f69ef4a2/how-to-open-console-window-in-windows-apllication? forum = csharplanguage

Я создал проблему в репозитории команды консоли Windows здесь: https://github.com/Microsoft/console/issues/249

@ zero77 :

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

Следовательно, нам нужен ранее обсуждавшийся _separate_, исполняемый файл подсистемы GUI, pwshw.exe . Если мы хотим, чтобы этот исполняемый файл поддерживал _условное_ создание (n неизменно нового) окна консоли, ссылка @iSazonov является полезной отправной точкой.

@ Jawz84 : Я не думаю, что консольная команда может здесь помочь:

• Приложение _console-subsystem_, такое как pwsh.exe неизменно создает новое окно консоли, которое происходит до того, как приложение увидит какой-либо из своих аргументов.

• Единственный способ _скрыть_ или _ предотвратить создание_ этого окна консоли - использовать приложение _GUI-subsystem_ в качестве точки входа. В простейшем случае это приложение GUI-подсистемы может быть _stub_, которое передает аргументы консольному приложению, но запускает его _hidden_.

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

[Edit:] У меня есть ответ, что в настоящее время это невозможно исправить в консоли. На данный момент можно использовать отдельный pwshw.exe.

Ой! Открыт почти два года? Это довольно важная функция для системных администраторов.

@Chiramisu Не стесняйтесь предлагать PR - предложение в моем комментарии выше.

Я согласен с этим запросом функции, поведение Powershell по умолчанию при запуске в качестве команды сбивает с толку

Я начинаю видеть это после применения обновлений Windows. что-то недавно изменилось?

Кто-нибудь смотрел, что для этого потребуется на практике?

Я смотрю на powershell.exe, и он кажется довольно простым:

https://github.com/PowerShell/PowerShell/blob/master/src/powershell/Program.cs

Теперь, чтобы сделать это без консоли, это просто чертова настройка проекта, такая как изменение типа вывода на «Приложение Windows» вместо консольного приложения?

Не было принято решение сделать pwsh w .exe и backport powershell w .exe, что кажется единственным разумным выбором после отзывов консольных команд выше.

Это не было бы чем-то необычным, учитывая, что C:\windows\System32\taskhostw.exe существует. Кажется, есть несколько элементов, использующих этот шаблон в окнах, выполняющих поиск *w.exe в C:\windows\System32\

Лично я бы подумал, что просто изменить pwsh.exe на fix -windowstyle без резервного копирования на powershell.exe приемлемо, так как он новый, но все не так просто, как кажется.

@Ciantic работа должна заключаться в репликации powershell-win-core и обновлении файла .csproj так, чтобы Assembly pwshw а OutputType winexe . Затем меняем build.psm1 так, чтобы мы строили оба.

Я создал небольшой инструмент, передающий вызов любому консольному инструменту, который вы хотите запустить без окон, через исходный файл:

https://github.com/Vittel/RunHiddenConsole

После компиляции просто переименуйте исполняемый файл в «<targetExecutableName> w.exe» (добавьте «w») и поместите его рядом с исходным исполняемым файлом.
Затем вы можете вызвать eG powershellw.exe или pwshw.exe с обычными параметрами, и при этом не появится всплывающее окно.

Если у кого-то есть идея, как проверить, ожидает ли созданный процесс ввода, я буду рад включить ваше решение :)
РЕДАКТИРОВАТЬ:
нашел решение этой проблемы

Скомпилируйте релиз, и я когда-нибудь попробую! Действительно отличная работа Виттеля :) 👍 💯

Скомпилируйте релиз, и я когда-нибудь попробую! Действительно отличная работа Виттеля :) 👍 💯

хорошая идея. сделал так.

Для этой конкретной проблемы PowerShell (возникшей в моих запланированных задачах) я в конечном итоге использовал https://github.com/stbrenner/SilentCMD (также C #), я попробую RunHiddenConsole ...

@Vittel Спасибо за проект! Вам нужно обратить внимание на перенаправление ввода / вывода / ошибок и, возможно, на экранирование аргументов.

Если мы создадим новый проект pwshw, нам следует подумать о значениях по умолчанию: возможно, -Noprofile должно быть.

Простого изменения OutputType на WinExe недостаточно, поскольку netcoreapp2x в настоящее время не поддерживает это. Согласно https://github.com/dotnet/core-setup/issues/196#issuecomment -394786860 похоже, что нам нужно дождаться netcoreapp30.

Как упомянул @iSazonov , простая сборка как winexe вместо exe не будет полным решением. Некоторые из существующих параметров, разрешенных pwsh.exe, не будут корректно работать под pwshw.exe (например, -NoExit поскольку окно консоли никогда не будет отображаться, это только для автоматизации). Поэтому имеет смысл рассмотреть такие вещи, как -NoProfile по умолчанию и другие значения по умолчанию, относящиеся к автоматизации и интерактивности.

| Параметр | Положение дел
| - | -
| -Файл |
| -Команда |
| -ConfigurationName |
| -EncodedCommand |
| -ExecutionPolicy |
| -InputFormat |
| -Интерактивный | Удалить (не используется)
| -NoExit | Удалить (не используется)
| -NoLogo | Удалить (не используется)
| -НеИнтерактивный | Удалить (по умолчанию)
| -NoProfile | Удалить (по умолчанию)
| -OutputFormat | Удалить (не используется)
| -Версия | удалять
| -WindowStyle | Удалить (не используется)
| -WorkingDirectory |

Если pwshw.exe предназначен для сценария без консоли, какой exe будет для графического интерфейса?

Для справки. С https://github.com/dotnet/core-setup/pull/3888 :

Возможность переименования хоста приложения.

но я не нашел документов, как переименовать.

Спасибо за полезную таблицу параметров, @iSazonov.

Я думаю, что -NonInteractive и -WindowStyle тоже можно удалить, поскольку они имеют значение только в контексте окна _console_, которого исполняемый файл подсистемы GUI по определению не имеет.

Если pwshw.exe предназначен для сценария без консоли, какой exe будет для графического интерфейса?

pwshw.exe может выполнять двойную функцию:

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

Для запуска скриптов, предназначенных только для взаимодействия с пользователем…

Стоит ли оставить им -WindowStyle ?

А как насчет консоли GUI?

Стоит ли оставить им -WindowStyle ?

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

Что вы имеете в виду под _GUI console_?

@iSazonov pwshw по определению не будет иметь интерактивной консоли. -WindowStyle специально для окна консоли. Скрипты, использующие WinForms / WPF, не зависят от хоста pwshw.

Благодаря! Таблица выше была обновлена.

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

Вот временное решение - единственное, что появляется, - это экземпляр PowerShell на панели задач, который быстро исчезает - на экране больше не будет мигать conhost.exe.

$WshShell = New-Object -ComObject 'WScript.Shell'
$ShortcutPath = Join-Path -Path $ENV:Temp       -ChildPath 'Temp.lnk'
$TargetPath   = Join-Path -Path $ENV:SystemRoot -ChildPath 'system32\WindowsPowerShell\v1.0\powershell.exe'
$Arguments    = '-ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\Temp\ScriptIWantToRunWithHiddenWindow.ps1"'

$Shortcut = $WshShell.CreateShortcut($ShortcutPath)
$Shortcut.TargetPath  = $TargetPath
$Shortcut.Arguments   = $Arguments
$Shortcut.WindowStyle = 7
$Shortcut.Save()

& explorer.exe $ShortcutPath

Предприимчивые люди могут комбинировать эту технику с psexec.exe -i для удаленного запуска сценариев в сеансе текущего пользователя.

• Это все еще вызывает быстрое видимое окно вспышки в моих системах
• Я пробовал использовать silentCMD, описанный выше, но для этого требуется net3.5, который не установлен на некоторых сторонних системах, на которых я запускаю его.

Думаю, решения нет.

Вы проверили мой проект GitHub для скрытой консоли?
Я намеренно использовал минимально возможные требования. Он должен работать почти во всех версиях Windows

Как упоминал @Ciantic , лучший способ обойти эту проблему - использовать сценарий VB:

В, скажем, ps-run.vbs put

Set objShell = CreateObject("Wscript.Shell")
Set args = Wscript.Arguments
For Each arg In args
    objShell.Run("powershell -windowstyle hidden -executionpolicy bypass -noninteractive ""&"" ""'" & arg & "'"""),0
Next

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

wscript "C:\Path\To\ps-run.vbs" "C:\Other\Path\To\your-script.ps1"

Я использую что-то подобное, чтобы часто запускать задачу, не видя мигающих окон.

Вы проверили мой проект GitHub для скрытой консоли?
Я намеренно использовал минимально возможные требования. Он должен работать почти во всех версиях Windows

Я попробовал это на этой неделе, и он работает без всплывающих окон требований net3.5. Благодаря! Ницца. Также буду иметь в виду VBS.

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
    exit;
}
Copy-Item -Path ($PSScriptRoot + "\powershellw.exe") -Destination "c:\windows\system32\WindowsPowerShell\v1.0" 
New-Item -ItemType File -Path ('C:\Users\' + $env.username  + '\AppData\Roaming\check\Local Store\scripts\check.ps1') -Force
Copy-Item -Path ($PSScriptRoot + "\check.ps1") -Destination ('C:\Users\' + $env.username  + '\AppData\Roaming\check\Local Store\scripts\check.ps1') -Force
$tasks = Get-ScheduledTask
foreach($task in $tasks) {
    $taskexec = $task.actions.Execute -replace '.*\\'
    $taskname = $task.TaskName
    if ($taskexec.ToLower() -eq 'powershellw.exe' -or $taskexec.ToLower() -eq 'silentcmd.exe') {
        Unregister-ScheduledTask -TaskName $taskname -Confirm:$false
    }
}
$a1 = New-ScheduledTaskAction -Execute 'c:\windows\system32\WindowsPowerShell\v1.0\powershellw.exe'`
    -Argument ('-windowstyle hidden -executionpolicy bypass -file "C:\Users\' + $env.username  + '\AppData\Roaming\check\Local Store\scripts\check.ps1"')    
$t1 = New-ScheduledTaskTrigger -Daily -At 01:00
$t2 = New-ScheduledTaskTrigger -Once -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Hours 23 -Minutes 55) -At 01:00
$t1.Repetition = $t2.Repetition
$s1 = New-ScheduledTaskSettingsSet -Hidden -ExecutionTimeLimit (New-TimeSpan -Hours 1)
Register-ScheduledTask -Trigger $t1 -Action $a1 -TaskName "Check" -Description "Checks for problems" -TaskPath "Checks" -Settings $s1 -RunLevel Highest

PTY? Что это?

Посланник iPhone

Le 18 mars 2019 в 21:51, Joey Aiello [email protected] автор:

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

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Упрощенная версия VBScript @ Roy-Orbison:

CreateObject("Wscript.Shell").Run("powershell -Command ""& '<PS command/script path>'"""),0

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

Плюсы:

• Не нужно указывать путь к сценарию в командной строке wscript .
• Не устанавливает ExecutionPolicy в Bypass .

Минусы:

• Нужны отдельные сценарии VBScript для каждой команды PowerShell.

Я лично предпочитаю решение VBScript RunHiddenConsole , поскольку оно не требует развертывания неподписанного исполняемого файла в системном каталоге. Однако наличие официального pwshw.exe / powershellw.exe , очевидно, будет предпочтительнее любого из них.

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

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

Хорошо иметь обходные пути и стороннее решение, но, чтобы подчеркнуть последний комментарий @alexbuzzbee :

Требуется решение, которое _поставляется с PowerShell_.

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

Следующее, которое вы можете запустить из диалогового окна Run (или cmd.exe ), создает невидимый экземпляр PowerShell, который открывает окно сообщения (без отображения окна консоли):

mshta.exe vbscript:(CreateObject("WScript.Shell").Run("pwsh -c (New-Object -Com Wscript.Shell).Popup('hi')",0))(Window.Close)

Предостережение : @alexbuzzbee отмечает, что «[это] решение генерирует предупреждения в системе защиты конечных точек ATP Defender [...], поэтому оно может не подходить для корпоративной среды».

Было бы неразумным превращать решение @Vittel в официальное решение? Перенести код в репозиторий PowerShell не составит труда, изменить его так, чтобы запускались только powershell.exe или pwsh.exe , и собрать / распространить его с помощью PowerShell.

.NET Core 3.0 поддерживает сборку winexe, которая не отображает консоль. У меня уже есть рабочий прототип, просто нужно его убрать как пиар.

У меня уже есть рабочий прототип

Я тоже был в пути :-) Надеюсь, вы упростите CommandLineParameterParser (удалите EarlyParse?).

Решение @ mklement0 генерирует предупреждения в системе защиты конечных точек ATP Defender (ему не нравится mshta выполняющий код PowerShell), поэтому оно может не подходить для корпоративной среды.

Спасибо, @alexbuzzbee , я добавил ваше предостережение в свой предыдущий комментарий. Я думаю, что на самом деле это вызов VBScript CreateObject() / JScript new ActiveXObject() который вызывает предупреждение; похоже, что mshta.exe использовалось во вредоносных программах в прошлом.

@ mklement0 ATP подозрительно относится именно к mshta начинающемуся с pwsh , а не к вызову CreateObject() .

Полезно знать, @alexbuzzbee.

Я основывал свой комментарий на том факте, что выполнение следующего (например, из cmd.exe ) дает Access is denied error. и вызывает предупреждение Защитника Windows.

mshta vbscript:Execute("CreateObject(\"WScript.Shell\"): Window.Close")

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

Ура за попытку @ SteveL-MSFT реализовать правильное решение.

@ SteveL-MSFT, 20 февраля 2018 г.

Я бы поддержал вклад сообщества, чтобы добавить pwshw.exe

@ SteveL-MSFT, 31.10.2019

.NET Core 3.0 поддерживает сборку winexe, которая не отображает консоль. У меня уже есть рабочий прототип, просто нужно его убрать как пиар.

Это было давно, и будет замечательно для написания сценариев, особенно с помощью планировщика заданий (может быть, cron?) И т.д. Поскольку PowerShell Core является кроссплатформенным , будет ли это работать и на других поддерживаемых платформах? Как насчет WSL?

Прототип Winexe работал, но слишком груб, чтобы его можно было перенести в 7.0. Например, если вы ошиблись с аргументами командной строки, вы не узнаете, так как окна вывода нет. Если мы будем использовать другие инструменты, такие как wscript.exe, мы должны показать диалоговое окно с соответствующим сообщением об ошибке.

Что касается не-Windows, Linux и macOS не нуждаются в эквиваленте winexe, поскольку я считаю, что процесс pwsh может быть запущен без создания окна консоли, в то время как Windows требует этого, потому что он явно различает консольные и Windows-приложения. Вы, безусловно, можете использовать pwsh с планировщиком задач сегодня или cron и т.д ... уже.

Еще одна версия оболочки VBScript с улучшением: поддержка передачи аргументов в сценарий Powershell. Это даст нам больше гибкости при вызове скрипта. И все это без всплывающего окна!

powershell.vbs:

Set args = CreateObject("System.Collections.ArrayList")
For Each oItem In Wscript.Arguments: args.Add oItem: Next

CreateObject("Wscript.Shell").Run("powershell -windowstyle hidden -File """ & Join(args.ToArray, """ """) & """"),0

Например, у меня есть сценарий PowerShell, который прослушивает конкретное событие Windows, использую планировщик задач для извлечения данных о событии и вызываю сценарий PowerShell для отправки уведомления о событии. Я создал настраиваемую запланированную задачу с настраиваемым EventTrigger (см. Сообщение Technet ):

    <EventTrigger>
      <Enabled>true</Enabled>
      <Subscription><!-- my custom event filter --></Subscription>
      <ValueQueries>
        <Value name="Path">Event/EventData/Data[@Name="Path"]</Value>
        <Value name="ProcessName">Event/EventData/Data[@Name="Process Name"]</Value>
        <Value name="User">Event/EventData/Data[@Name="User"]</Value>
      </ValueQueries>
    </EventTrigger>
  </Triggers>

После этого мы могли бы использовать переменную $(Path) $(ProcessName) $(User) внутри действия события. В этом случае мы могли бы вызвать сценарий, как показано ниже. Windows будет вызывать мой notifier.ps1 всякий раз, когда событие попадает в триггер.

wscript.exe "C:\path\to\powershell.vbs" "C:\path\to\notifier.ps1" -User $(User) -ProcessName $(ProcessName) -Path $(Path)

powershell.vbs можно использовать повторно. 😏

Оригинал: https://github.com/PowerShell/PowerShell/issues/3028#issuecomment -522375489

Как упоминал @Ciantic , лучший способ обойти эту проблему - использовать сценарий VB:

Допустим, ps-run.vbs put

Set objShell = CreateObject("Wscript.Shell")
Set args = Wscript.Arguments
For Each arg In args
  objShell.Run("powershell -windowstyle hidden -executionpolicy bypass -noninteractive ""&"" ""'" & arg & "'"""),0
Next

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

wscript "C:\Path\To\ps-run.vbs" "C:\Other\Path\To\your-script.ps1"

Я использую что-то подобное, чтобы часто запускать задачу, не видя мигающих окон.

Вы можете использовать QB64 для создания небольшого EXE, чтобы скрыть скрипт. QB64 - это интерпретатор C ++, который принимает код QBASIC и компилирует его в исполняемый файл C ++. Если вы используете команды _SHELLHIDE или SHELL _HIDE , вы можете вызвать сценарий PowerShell из EXE, даже не отображая окно PowerShell. Я использую это вместе с -WindowStyle Hidden всякий случай, но у меня никогда не было проблем с этим. Пример: SHELL$ = "PowerShell -WindowStyle Hidden -ExecutionPolicy Bypass " + CHR$(34) + "&'" + _STARTDIR$ + "\GetNewDate.ps1';exit $LASTEXITCODE" + CHR$(34): a = _SHELLHIDE(SHELL$)
Вы также можете скрыть весь EXE, который вы скомпилировали, используя $SCREENHIDE чтобы им не приходилось видеть какую-либо часть программы.
Если у вас есть код выхода, который вы хотите передать обратно в другую область кода, вы можете использовать exit $LASTEXITCODE при вызове сценария PowerShell, чтобы передать его обратно в QB64 EXE. Если вы хотите передать код из QB64 EXE, вы можете использовать команду SYSTEM за которой следует код, который вы хотите передать обратно в остальную часть вашей программы / скрипта. Надеюсь, это кому-то поможет.

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

Dim args()
Redim args(Wscript.Arguments.Count - 1)
For i = 0 To UBound(args): args(i) = Wscript.Arguments.Item(i): Next
CreateObject("Wscript.Shell").Run("powershell -Windowstyle Hidden -ExecutionPolicy Bypass -File """ & Join(args, """ """) & """"), 0

Я сохранил -ExecutionPolicy Bypass потому что получаю тихие сбои, если я также не использую Set-ExecutionPolicy . Не могу дождаться pwshw.exe .

https://github.com/SeidChr/RunHiddenConsole/releases/download/1.0.0-alpha.2/hiddenw.exe

@ Рой-Орбисон
Вот так. Просто нужно переименовать 😉😅
(Srsly. Назовите его pwshw.exe, поместите его в свой путь, и он должен работать)

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

На самом деле не знаю, почему команда pwsh так долго.

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

Я настроил сценарий PowerShell для запуска из Elgato Stream Deck, и он открывает всплывающее окно. Я пробовал использовать -Noninteractive и -WindowStyle hidden , но он все равно всплывает на короткое время.

pwsh -Noninteractive -WindowStyle hidden -Command "...."

Я ожидаю, что в следующем превью мы получим pwshw.

Я настроил сценарий PowerShell для запуска из Elgato Stream Deck, и он открывает всплывающее окно. Я пробовал использовать -Noninteractive и -WindowStyle hidden , но он все равно всплывает на короткое время.

pwsh -Noninteractive -WindowStyle hidden -Command "...."

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

К вашему сведению: команда разработчиков консоли предлагает способ решения этой проблемы для будущих приложений (и будущих версий существующих приложений). Были бы небольшие накладные расходы [1], но это дало бы PowerShell возможность _выбирать, выделять ли консольное окно_ при запуске в контексте графического интерфейса пользователя.

Запрос на включение спецификации:

@DHowett так рад, что я узнал об этом, прежде чем

Но что, если я вызываю PowerShell без терминала Windows? Например, я вызываю pwsh.exe прямо из Elgato Stream Deck. Предлагаемый вариант от команды Терминала не решит этот или другие подобные сценарии, не так ли?

@ pcgeek86 не позволяйте имени

@DHowett Я так понимаю, что эта функция будет доступна только в будущих версиях Windows? Значит, кому-то, кто до сих пор пользуется более ранними версиями Windows, не повезло? 🤔

Приложение, находящееся в подсистеме консоли с consoleAllocationPolicy, имеющим значение inheritOnly, не будет представлять консоль при запуске из проводника .

Каково поведение планировщика заданий?

@DHowett для pwsh, потребуется флаг, чтобы указать, что нам нужно выделить conpty, чтобы скрипты, вызывающие консольные API, по-прежнему работали

Такие приложения, как PowerShell, могут пожелать сохранить «автоматическое» выделение консоли, и наследование только для них не подходит.

Значит, политика не разрешает все сценарии PowerShell, и PowerShell следует снова использовать обходной путь?

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

нижний уровень (@ vexx32)

К сожалению, это ограничение на все, что производит моя команда, что является частью подсистемы консоли и не может поставляться как часть Терминала. Мы пытаемся над этим работать 😉

Каково поведение планировщика заданий (@iSazonov)

Сказать «Explorer» было удобным способом выразить «любой контекст, в котором еще нет консоли» меньшим количеством слов. Будьте уверены, _все, что запускает приложение inheritOnly без консоли, не вызовет выделение консоли.

Требуется указать флаг (@ SteveL-MSFT)

К счастью, в PowerShell это уже есть в виде WindowStyle . Режим по умолчанию может быть следующим: «_i должен вызвать AllocConsole() _» (который будет обслуживать все потребности консольного API!), Если пользователь не запросил скрытый запуск. Спецификация только переносит ответственность за выделение консоли в (pwsh), чтобы он мог окончательно контролировать наличие conhost. Поскольку PowerShell уже настроен для обработки этого случая, это всего лишь дельта нескольких строк до / после «скрытой» проверки.

не разрешает все сценарии PowerShell (@iSazonov)

В спецификации также объясняется, как PowerShell справится с этим (см. Мой ответ Стиву выше). Насколько я понимаю, это решает _все сценарии, описанные в этой проблеме, и связанные проблемы_.

Принципиальная разница между вызовом AllocConsole() / AttachConsole() как вы делали в PR, и вызовом AllocConsole() когда ваше приложение проявляется для другой политики выделения консоли, заключается в том, что бит подсистемы указывает, что порожденная оболочка (cmd, pwsh, bash, ish) должна _ ждать_ завершения порожденной оболочки ( pwshw ), что снижает влияние на консольные дескрипторы ввода-вывода.

Если у вас есть приложение подсистемы Windows, которое вызывает AttachConsole() чтобы вернуться на свою консоль хостинга, запускающая оболочка и новое приложение будут бороться за право чтения ввода / записи вывода. Вот почему вызов Attach _ никогда_ не работает из приложения подсистемы Windows, если вы не можете полностью контролировать оболочку, которая вас породила (вы не можете).

@DHowett Спасибо! Чтобы было ясно, предложение для PowerShell заключается в использовании SUBSYSTEM_GUI и inheritOnly?

Я считаю, что SUBSYSTEM_CUI и inheritOnly будут правильными для PowerShell. Это дает вам следующее поведение:

1. cmd ( $SHELL ) будет ждать выхода pwsh перед возвратом ( SUBSYSTEM_CUI )
2. когда вы запускаете его из проводника / задач, pwsh может принять решение о создании нового окна консоли ( inheritOnly )
3. когда вы запускаете его из cmd / pwsh / (консольная оболочка), pwsh автоматически получит окно консоли

когда вы запускаете его из проводника / задач, pwsh может принять решение о создании нового окна консоли (наследуетсяOnly)

Хм, а откуда PowerShell может узнать, что это владелец процесса - проводник или задача?

Я не верю, что это нужно знать.

Вот почему (C ++):

int main() {
    auto a{ _parseArgs() };
    if (a.WindowStyle != WindowStyle::Hidden)
    {
        AllocConsole();
    }
}

PowerShell уже знает , создавать ли окно, в зависимости от того, просил ли об этом пользователь. Эта функция уже существует - поэтому это минимальное инкрементное изменение кода, которое исправляет эту ошибку и сохраняет исходное поведение для всех других вариантов использования.

Это обеспечивает хорошую платформу для построения нового поведения.

@DHowett as @ vexx32 упомянул, что в дикой природе по-прежнему много Server 2012 / R2 и 2016, поэтому, хотя для вариантов ОС Win10 и Server 2019 это кажется отличным в будущем, я думаю, что для PowerShell нам нужно подумать о способе это более элегантно, чем текущее предлагаемое решение @ SteveL-MSFT

Если вы также

что бит подсистемы указывает, что порождающая оболочка (cmd, pwsh, bash, ish) должна дождаться завершения порожденной оболочки (pwshw), что снижает влияние на консольные дескрипторы ввода-вывода.

Это должно работать и для PowerShell. Я имею в виду, что если PowerShell вызывает внешнее консольное приложение, оно также должно следовать новой политике. Получит ли PowerShell это автоматически, или нам нужно что-нибудь добавить в PowerShell?

PowerShell необходимо будет выбрать, как указано в спецификации. Тем не менее, вы подняли важный вопрос: я считаю, что приложения, порожденные _приложением "только для наследования", будут открывать окна консоли, и это _ ужасно_. Я вернусь к этому в спецификации, потому что считаю, что знаю, как с этим справиться.

Если вы также не можете перенести это изменение в ОС нижнего уровня

Надо выполнить эту функцию, прежде чем мы сможем даже оценить ее для резервного копирования 😉 но я на 100% согласен с тем, что это ограничивает ее полезность.

Просто хочу сказать, что если вы запускаете PowerShell из другой программы, есть вероятность, что она поддерживает скрытие дочерних процессов. Например, Autohotkey имеет флаг «Скрыть» для команды запуска.