Isso é por design.

Temos planos de dar suporte à configuração de outro aplicativo como o "terminal padrão" no Windows, mas esses planos ainda são muito difíceis e em andamento.

Isso exigirá um recurso do sistema operacional. Estou atualizando o título para representar a alteração padrão do sistema operacional do terminal.

Estou renomeando isso para adicionar a palavra-chave [defterm] ao final para que possamos encontrá-la facilmente nas pesquisas. As palavras "padrão" e, bem, "terminal" aparecem com frequência alarmante neste repositório. :sorrir:

Estou curioso como ConEmu faz isso. Uma vez instalado, cada nova janela cmd/ps/bash é aberta no ConEmu como uma nova guia

Estou curioso como ConEmu faz isso. Uma vez instalado, cada nova janela cmd/ps/bash é aberta no ConEmu como uma nova guia

O mesmo aqui, não sei como, mas espero que o Windows seja atualizado para oferecer suporte total ao terminal.

Estou curioso como ConEmu faz isso. Uma vez instalado, cada nova janela cmd/ps/bash é aberta no ConEmu como uma nova guia

O ConEmu pode estar (ab)usando a capacidade de definir um depurador personalizado para um processo. Acredito que o Process Explorer faça o mesmo para "substituir" o Gerenciador de Tarefas

Process Hacker também suporta “substituir” o Gerenciador de Tarefas .

Estou curioso como ConEmu faz isso. Uma vez instalado, cada nova janela cmd/ps/bash é aberta no ConEmu como uma nova guia

O ConEmu pode estar (ab)usando a capacidade de definir um depurador personalizado para um processo. Acredito que o Process Explorer faça o mesmo para "substituir" o Gerenciador de Tarefas

AFAIR, apenas altera uma chave de registro.

Seja como for, o ConEmu consegue fazer isso, então o MST também deveria.

O ConEmu injeta ganchos (DLLs) em processos específicos (como explorer.exe ou devenv.exe) para interceptar a criação de novas janelas de console nesses processos. Você pode ler mais sobre isso nos documentos oficiais: https://conemu.github.io/en/DefaultTerminal.html

Conforme mencionado nesse link, esse método é puramente um _hack_. Definitivamente, não é uma solução viável para o Windows Terminal.

Mas… funciona. Ter um acesso a todo o subsistema simplifica uma coisa.

A diferença é que o Windows Terminal é um produto oficial da Microsoft , então a expectativa aqui é que o terminal padrão não seja alterado usando um hack feio usável, mas seja suportado nativamente pelo Windows .

Não sei se este é o lugar apropriado para mencionar isso, mas acho que pode ser relevante.

Por algum motivo, agora, cmd e powershell, aparentemente têm tamanhos de fonte e janelas enormes, dependendo de como e de onde são lançados. A partir do menu iniciar, via explorer, via Win + R, etc.

Quando o novo terminal se tornar o padrão, ele:

1. Tem um tamanho de fonte e tamanho de janela consistentes?
2. Também ser o terminal padrão de fazer "Abrir janela Poweshell aqui" etc?

Aqui estão alguns exemplos para demonstrar o que quero dizer.

Em ordem, iniciado a partir de um atalho da barra de tarefas, iniciado em "Abrir janela do Powershell aqui", iniciado digitando "powershell" na entrada de endereço do Explorador de Arquivos (observe como o prompt padrão também parece ser diferente).

Seria bom se o Terminal unificasse tudo isso. É bastante frustrante.

@lloydjatkinson obrigado! É apenas um pouco apropriado aqui, mas basta dizer que:

• o Console tem três (!) (e meio) locais diferentes de leitura das configurações
• Terminal tem apenas um (e meio)

Para responder aos seus pontos numerados específicos:

1. Sim, totalmente, porque há apenas uma fonte de verdade para configurações.
2. Sim, é isso que esse recurso está rastreando. Redirecionar para o Terminal sempre que uma janela do console for iniciada para uso interativo.

O prompt padrão parece estar representando que você está em um diretório diferente. Iniciar powershell na barra de endereços no explorer faz isso em qualquer diretório que você esteja visualizando no momento.

Querida equipe, isso ainda está muito no backlog? Agora, com o lançamento do Powershell7, aumenta a demanda por ter acesso mais fácil a um terminal moderno capaz de lidar com o Powershell correto.

1421 só abre PS5.1 no momento e não há opção oficial para mudar isso

Falei com Steve Lee no twitter e é claro que seria benéfico promover o uso de ambos os produtos Terminal e Powershell em lançamentos recentes / lançamentos internos clientes Windows 10.

@Karl-WE, estamos lançando a v1 antes de começarmos a analisar as alterações necessárias no Windows para oferecer suporte ao registro, enumeração e execução de hosts de console alternativos (ou os terminais que os usariam)

Como isso provavelmente exigiria algum suporte de API, provavelmente só pode ser feito como parte de uma grande versão do Windows.

Obrigado Dustin por seu excelente trabalho aqui. Espero que esse esforço entre as equipes possa ser comunicado às equipes Insider e Powershell. Boa sorte com os cronogramas de lançamento da versão 1.0. talvez possamos conseguir isso para 20H2, o que deixa todos os envolvidos no mínimo 9 meses.

Espero que isso seja adicionado mais cedo ou mais tarde, existem soluções alternativas não oficiais?

Tenha certeza de que esse problema teria centenas de comentários da comunidade criando todos os tipos de soluções malucas, se houvesse alguma ;)

Eu tenho uma ideia para algum arquivo bat básico:
execute seu arquivo bat em segundo plano e feche a janela cmd padrão

START /B  wt cmd /c yourfile.bat
exit

Tenha certeza de que esse problema teria centenas de comentários da comunidade criando todos os tipos de soluções malucas, se houvesse alguma ;)

Estou iniciando cmd (e agora powershell ) do Win+R há décadas, mas estou me reeducando dolorosamente para digitar wt . Acho que você pode ensinar novos truques a um cachorro velho. Devagar. 😁

Isso funciona graças ao alias de execução do aplicativo wt.exe em %userprofile%\AppDataLocalMicrosoftWindowsApps

Oi equipe, usuários, já que o wt agora tem um conjunto muito bom de opções e um json de configurações predefinidas e uma parte definível pelo usuário que também inclui a configuração, qual console é o console padrão a ser aberto ao iniciar o wt - pensei que seria suficiente pegue todos os planos aproximados (https://github.com/microsoft/terminal/issues/492#issuecomment-490092382) para pegar pelo menos a seguinte tentativa:

Integração de Win+X.

Como eu acho que você pode fazer isso:

• conecte-se com Jennifer Gentlemen e equipe para configurações
• adicione um novo item de configurações capaz de substituir ou atualizar a configuração a seguir para iniciar wt em vez de powershell ou cmd
• atualize o arquivo ADMX de acordo para que ele também possa ser definido via GPO

• ressalva: wt precisa ser instalado pelo usuário

• o usuário pode usar a opção de console padrão para especificar qual deve ser aberto por padrão a partir daí

Como
"profiles": [ "defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}" { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell 7", "source": "Windows.Terminal.PowershellCore", "useAcrylic": true }, ],

Configurações > Personalização > Barra de tarefas

"substituir Win + X cmd por powershell"

Talvez seja um ponto de vista ingênuo de um usuário, mas não consigo imaginar que seja possível mudar o cmd para o Powershell neste momento há anos, mas não dando o pequeno passo à frente para substituir esses dois itens novamente por wt. E sim, faria sentido assim ter wt com e sem direitos de administrador, por padrão, também não é elevado como qualquer outro console (com poucas exceções)

Você pode, por favor, explicar por que isso é tanto trabalho para fazer? Seria um começo.

Ter a escolha de um aplicativo de terminal padrão em Configurações> Aplicativos e recursos> Aplicativo padrão - posso entender que isso requer mais trabalho sob o capô. Eu verifiquei duas vezes com o NirSoft ShellExView que isso não pode ser alcançado tão facilmente no momento.

No entanto, alterar a configuração do Win + X mencionada acima já é algo que existe.
Por favor, lembre-se de que existe até uma ferramenta de terceiros que pode alterar o menu Win + X para qualquer pessoa, mas a fonte de download que hoje eu prefiro classificar como não confiável.

Você pode encontrar a ferramenta aqui, mas use por sua conta e risco
Editor de menu Win+X
Criado por Sergey "Happy Bulldozer" Tkachenko
http://winaero.com
Este software usa o código-fonte da ferramenta hashlnk
hashlnk foi criado por Rafael Rivera
http://www.withinwindows.com/

Espero que eu tenha permissão para postar esta referência, caso contrário, remova-a. Se eu puder fazer o upload do aplicativo como um zip ou Onedrive, por favor me avise. Não há nenhuma dica de que não é permitido espelhar em outro lugar.

ps Eu tentei adicionar wt em um novo grupo no menu Win + X, mas por algum motivo pouco claro, ele não o faz. As permissões parecem corretas. Eu posso adicionar qualquer arquivo como um link, exceto coisas de
%localappdata%MicrosoftWindowsApps (mesmo com caminho completo).

Estou curioso para saber o que impede isso por design. Parece porque os aplicativos existem arquivos de tamanho 0 kb e algum tipo de link simbólico? No Gerenciador de Tarefas, você também não pode "abrir o local" de um processo wt. Suspeito que essa seja a natureza da virtualização de aplicativos de MS. Também se aplica a outros como Edge Chromium, notepadS etc.

Dadas essas informações e circunstâncias, agora posso entender por que é tão difícil realizar essa mudança. Você não pode acessá-lo no explorer, mas pode iniciá-lo em Win + R / search. Que estranho.

Você não pode adicionar wt.exe diretamente, pois não é um "arquivo real", mas se você criar um atalho para wt.exe, a ferramenta poderá adicioná-lo e funcionará bem.

Você pode ler mais sobre isso aqui: https://www.hanselman.com/blog/TotallyUnsupportedHacksAddWindowsTerminalToTheWinXShortcutMenu.aspx

Se eu entendi a função do WinX corretamente o Windows não faz links apenas por caminho, provavelmente para evitar spoofing mas também gerando um hash do arquivo. Como todos os "aplicativos" têm tamanho de arquivo zero, o "não pode abrir" pode ser devido a não conseguir gerar o hash, provavelmente não por não poder acessá-lo / lê-lo.

Obrigado pela referência thlac @shanselman isso torna ainda mais difícil entender porque não existe uma forma oficial. Ofc ter um atalho para um arquivo expõe o risco de adulteração, o que parece contradizer a ideia original do projeto de WinX não ser facilmente adulterado.
O risco é que o PUA/malware possa alterar os alvos neste menu.

@Karl-WE Só queria ter certeza de que todos estão na mesma página aqui. O Windows Terminal é um aplicativo de terminal/console - não um shell . Cmd e PowerShell são shells . (Veja também: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx )

Portanto, a configuração Win + X é (IMHO) irrelevante para esse problema (já que apenas determina o shell, não o aplicativo do terminal).

Eu entendo sua definição. No final, dadas as muitas solicitações, o WinX ajuda a tornar o Windows Terminal

• mais proeminente, o que só pode ajudar seu sucesso e disseminação e, finalmente, honrar o trabalho realizado.

• ajudar os usuários a tornar seu shell padrão favorito mais acessível.
  Que pode não ser cmd ou PoSh 5.1 como configurável no momento.

Vendo isso por essa luz, ainda concordo com sua diferença observada, mas no final o objetivo é ajudar a tornar um shell mais fácil de acessar, tendo os melhores recursos do terminal em comparação com o console padrão .

@nu8 você provavelmente concordará que “substituir seu sistema conhost pela versão do conhost construída a partir deste repositório” e “fazer o Windows iniciar uma instância do Terminal automaticamente” são coisas muito diferentes;)

Este repositório hospeda tanto o host do console quanto o Terminal. Um constrói sobre o outro, mas eles certamente não são os mesmos.

@nu8, dada a grande quantidade de coisas que o @DHowett tem que revisar e fazer a triagem, às vezes talvez haja diferenças. Como você citou, é claro que 492 na linha do tempo vieram antes de 1817 e as coisas podem mudar.
seria mais irritante se ele postasse de outra forma. Mas no entanto:

a boa notícia é: está dentro do cronograma, não está mais no backlog

Vejo

1 | Terminal padrão | Se um aplicativo de linha de comando for gerado, ele deve ser aberto no Windows Terminal (se instalado) ou no seu terminal preferido
Edição: #492
Especificação: #2080

fonte: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

@DHowett obrigado pelo seu trabalho por aqui, tenho uma pequena pergunta:
Você acha que podemos esperar que isso seja lançado na atualização do Windows 20h2 ou 21h1? Você está ciente de algum trabalho interno (no nível do SO) indo nessa direção?
Eu entendo que os planos podem mudar, mas ainda estou curioso :)

Nós somos a equipe que teria que fazer o trabalho no nível do sistema operacional para habilitar esse recurso, então eu ficaria muito surpreso se _não estivéssemos_ cientes do trabalho que está sendo feito para habilitar isso.

Ainda estamos passando da versão 1.0 do Terminal, então ainda não começamos com isso. Eu diria que é improvável que chegue em 20H2 ou 21H1, considerando que provavelmente teríamos que ter o recurso pronto (ou pelo menos prototipado) até agora para colocá-lo em qualquer um desses lançamentos.

eu me pergunto o que virá primeiro - configuração defterm ou suporte completo à aceleração de gpu no WSL2, ponto em que poderíamos usar terminais linux nativos, pelo menos para desenvolvimento que pode ser virtualizado

Como essa edição tem tantos assinantes, vou bloqueá-la.
Se você tiver algo para contribuir que afetará a direção da engenharia para esse recurso, envie-me um e-mail para o endereço no meu perfil do GitHub.