command line

É possível ter scripts executados no Terminal Windows por defeito

Tenho pouca concha de poder e scripts cmd que corro de vez em quando.Quando clico num script de morcego,abre uma janela CMD clássica.Quando corro um script PS1,abre a janela clássica do PowerShell.

É possível ter estes abertos no novo Terminal Windows por defeito quando os executo? Não,não quero abrir o terminal,navegar para o script e executá-lo.Só quero clicar no .bat e pô-lo a correr na janela CMD que está dentro da aplicação do Terminal Windows.

Isto pode ser feito?

Tentei encontrar o exe terminal para que pudesse configurar os ficheiros ps1 para abrir com ele,mas recebo um erro quando tento fazer isso.Ver imagem de ecrã.

Thanks!


Estou a colocar isto aqui uma vez que é demasiado curto para um comentário,e que não está a fazer uma pergunta/questão de código PowerShell,mas sim a perguntar "Como configuro o meu ambiente/ferramenta escolhida,para fazer X ou Y.

  1. O Terminal Windows não é um processador shell/command.
  2. Não existe um conceito de corrida no GT.
  3. Só é executado com um processador de comandos, PowerShell ou cmd.exe. cmd.exe executa .bat, .cmd, .vbs. O Powershell executa .ps .
  4. WT,no lançamento,inicia o seu processador shell/command padrão.
  • PowerShell.exe
  • Pwsh.exe
  • cmd.exe
  • Bash.exe
  • Python.exe

... quaisquer processadores que você configurou em suas configurações de WT.

Mesmo que reghack isto,ele ainda só irá executar o processador shell/command padrão que configurou nas configurações do JSON.Então,porquê iniciar um host shell,apenas para executar um processador shell/command.

O que NotTheDr01ds está mostrando, já é o padrão ao clicar com o botão direito do mouse em um arquivo .ps1 e tentar alterá-lo para WT.exe não funcionará como você imagina.

Pode primeiro provar isto a si próprio utilizando WinKey+R e digitando o que se segue.Um não funcionará,o outro não.

wt d:\scripts\hello.ps1
# Results - error and locks WT
<#
[error 0x800700c1 when launching `d:\scripts\hello.ps1']
#>
wt powershell -noprofile -noexit d:\scripts\hello.ps1
# Results - runs the script as expected
<#
Hello World

Tuesday, 23 March, 2021 20:15:28
#>

Assim,qualquer reg hack exigiria que especificasse o processador de comando e o nome do ficheiro e quaisquer argumentos necessários para uma execução bem sucedida.Tal como referido nos meus comentários.Pode evitar reghacks e apenas criar um atalho e adicionar este atalho ao seu menu SendTo.No Explorador do Windows,basta digitar...

shell:SendTo

Ou em PowerShell apenas para isto:

explorer shell:SendTo

... e cole seu atalho lá (tenho muitos lá), então você tem que fazer as alterações nas configurações.

# Example:
"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.6.10571.0_x64__8wekyb3d8bbwe\wt.exe" powershell -noprofile -noexit

Estou informando com antecedência, que isso teve alguns problemas.

Por vezes funcionava,outras vezes não.

Agora,claro,se quiser fazer isto para qualquer um dos processadores de comandos,então precisa de criar vários atalhos,alterá-los conforme necessário,e colá-los na pasta SendTo,depois clique com o botão direito do rato no seu ficheiro,e seleccione o atalho SendTo adequado.




O comportamento padrão hoje em dia,como sabe,é:

  1. Clique duas vezes em um arquivo .bat : Executa o script no shell CMD no terminal "antigo" do "Windows Console" ( conhost.exe )
  2. Clique duas vezes em um arquivo .ps1 : Abre o script no Bloco de Notas
  3. Clique com o botão direito do mouse em um arquivo .ps1 e "Executar com o PowerShell": executa o script no shell do PowerShell no terminal "antigo" do Windows Console

Se bem entendi,pretende alterar o comportamento de (1)e (3)para executar os scripts nas suas respectivas shells,mas dentro do Terminal Windows.

faz bons comentários que:

  • Os hacks de registro devem ser o último recurso.
  • shell:SendTo pode funcionar para vários casos sem precisar modificar o Registro.

Portanto,a técnica SendTo que sugere vale a pena tentar ver se funciona para si.No início,pensei que poderia falhar se houvesse um espaço no caminho para o guião.Mas nos meus testes,o Windows parece utilizar o caminho curto 8.3.

O método SendTo tem dois aspectos negativos:

  • SendTo se aplica a todos os tipos de arquivo , então você verá o Send To -> Windows Terminal ao clicar em um arquivo que não o suporta.
  • As entradas SendTo estão aninhadas sob um submenu,pelo que requerem um pouco de movimento extra do rato para chegar até elas.Por outro lado,os comandos do estilo "Abrir com" estão mesmo no topo do menu do clique do botão direito.

Se se verificar que precisa de algo mais,então continue a ler para as instruções de modificação do Registo.Sinto que estas são modificações seguras,mas aplicam-se os avisos normais do Registo --A sua quilometragem pode variar/Fazer cópias de segurança/Aqui estão os dragões/etc.

Em seguida, embora você provavelmente possa modificar o comando padrão "Abrir" de clique duplo .bat , não recomendo fazê-lo. Pode haver outros aplicativos (ou até mesmo funcionalidades do Windows) que dependem desse comportamento padrão. Minha recomendação é adicionar uma opção de clique com o botão direito do mouse em "Executar no Windows Terminal" para arquivos CMD .bat , assim como faremos para arquivos PowerShell .ps1 .

Para o fazer:

  • Execute regedit.exe (ou seu método preferido de iniciar o editor do registro)
  • Navegue até HKEY_LOCAL_MACHINE\SOFTWARE\Classes\batfile\shell
  • Clique com o botão direito do mouse no shell -> Novo -> Chave
  • Nomear a chave "run_in_wt".
  • Clique com o botão direito do mouse em run_in_wt -> New -> String Value
  • Nomear o imóvel "MUIVerb".
  • Clique duas vezes em MUIVerb e defina os dados do valor para "Executar no Windows Terminal" (ou como quiser que apareça no menu do botão direito)
  • Clique com o botão direito do mouse em run_in_wt novamente -> Novo -> Chave
  • Nomear a chave "comando".
  • Clique duas vezes na propriedade (Default) e defina os Dados do valor como wt new-tab --title "CMD Shell" cmd.exe /k "%1"
    • A opção /k impede que o shell seja encerrado após a conclusão do script. Isso difere do comportamento "normal" de clique duplo em um morcego. Se você quiser o comportamento antigo, basta alterar o /k para /c e o shell será encerrado quando o script estiver concluído.
    • Citar o "%1" aqui é o que nos permite executar scripts com espaços no caminho. O Windows substitui o caminho completo do script que está sendo clicado com o botão direito do mouse pelo %1 .
  • Teste-o

Para arquivos Powershell/ .ps1 , repita o processo, mas:

  • Navegue até HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Microsoft.PowerShellScript.1\Shell

  • Repita tudo até alterar a propriedade (Default) do command . Os dados do valor aqui serão wt new-tab --title "Windows PowerShell" powershell.exe -NoExit -Command "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass } \; & '%1'"

    • Como antes, o -NoExit é adicionado para evitar que o shell saia (e, assim, feche a guia/janela) quando o script for concluído.
    • Se desejar, você pode adicionar um -NoProfile para impedir que a inicialização do PowerShell seja executada ao executar scripts dessa maneira. Eu não coloquei lá caso seus scripts tenham alguma dependência que esteja carregada no seu perfil.
  • O Set-ExecutionPolicy é copiado do menu do botão direito "Executar com o PowerShell 7" que é opcional instalado com o PowerShell Core no Windows. Ele permite que o script seja executado (ignora restrições) desde que a política não esteja em seu nível mais estrito.

  • Example Screenshot:

Other notes:

  • A prática recomendada é usar caminhos totalmente qualificados para powershell.exe e cmd.exe , e você provavelmente deve modificar os comandos acima para fazer isso. No entanto, para wt.exe , acredito que seja mais seguro usá-lo sem o caminho, pois é um "App Execution Alias" definido para o aplicativo da Microsoft Store. Por outro lado, se você não instalou através da Loja, talvez você deva usar o caminho completo para onde você instalou o wt.exe também.

  • Se houver outras extensões que você iniciar (por exemplo , .cmd para CMD), você precisará configurá-las também. Por exemplo, em cmdfile na mesma folha de registro.

  • Você também pode modificar o acima para o PowerShell Core usando pwsh.exe em vez de powershell.exe .

  • A parte mais difícil desse processo, IMHO, é garantir que a citação e o escape estejam corretos. O Windows analisa esses comandos usando as regras de citação e escape do shell CMD, mas também estamos executando o código do PowerShell dentro desse comando que precisa ser escapado corretamente.

  • Como se pode ver na discussão nos comentários,muitas pessoas sentem que "terminal" versus "concha" é uma distinção importante,e é.Mas não creio que se deva esperar que todos os que aqui fazem perguntas (ou mesmo que as respondem)tenham o vocabulário "perfeito" para descrever o que estão a perguntar.Nós perguntamos;nós respondemos;aprendemos.Pedimos desculpa se algum dos comentários se deparou com demasiada dureza.