Há uma sequência de escape "padrão" (OSC 7; URI ST) para definir a crença do emulador de terminal sobre o diretório atual. Ele se origina do macOS Terminal.app e foi posteriormente adotado por alguns outros, incluindo o Terminal GNOME e, pelo que eu sei, o Konsole também.

Outra abordagem possível é fazer alguns hacks específicos do sistema operacional para examinar o estado interno do processo filho (ou ainda mais para os descendentes).

Outra possibilidade é misturar os dois, por exemplo, vá para o diretório definido via OSC 7 se ele já foi emitido, caso contrário, explore o processo.

A vantagem da abordagem OSC 7 é que ela é inteligente em relação a quando e quando não seguir um processo filho. Por exemplo, se você iniciar outro subshell aninhado, será o subdiretório desse subshell que será levado em consideração porque aquele também emite essa sequência. No entanto, inicie um aplicativo que muda internamente de diretório (por exemplo, make) e - felizmente - não será o subdiretório interno do make usado.

A desvantagem do OSC 7 é que ele requer a cooperação do shell ou de outros aplicativos importantes.

Tenho rejeitado este pedido de recurso desde que este projeto seja de código aberto e nunca aprendi sobre o OSC 7. Isso é _muito empolgante._

Não estou feliz em rastejar pela árvore de processos para desenterrar o CWD do processo mais folha, mas estou extremamente feliz em oferecer suporte ao OSC 7.

Para sua informação, perguntei sobre o manuseio do OSC 7 para Alacritty, o que acabou levando a esse problema sendo criado no "Terminal WG" no gitlab: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/20

Não houve muito movimento nesse tíquete, mas você pode estar interessado em segui-lo. Especialmente se vocês têm alguma opinião sobre como pode ser uma especificação "formal" para o OSC 7.

Então, para registro, o tópico em https://github.com/jwilm/alacritty/pull/2937 tem uma ótima discussão.

Honestamente, estou bem usando o padrão de fato que já existe, o mecanismo OSC 7 ; <URI> ST . Não tenho certeza se precisa haver algo mais formal do que isso.

Espere, não, eu tive um pensamento terrível. Digamos que bash esteja configurado para emitir isso e alguém execute bash no WSL. O que devemos fazer quando alguém tenta definir o diretório de trabalho para /home/zadjii ? Como nós:

1. diga que este é um caminho WSL, não um caminho do Windows
2. sabe de qual distribuição WSL isso veio?

Precisamos adicionar alguma propriedade do nosso lado que indique "esta é uma distribuição WSL, não um exe do Windows"? O que acontece aos usuários que não definem isso, a funcionalidade da guia duplicada simplesmente não funciona (efetivamente silenciosamente)?

Então, a próxima parte fica mais difícil. O que acontece quando esse comando é enviado por SSH? O terminal não pode saber que o caminho não está mais nesta máquina, certo? Como Terminal.app lida com isso?

Talvez isso precise de mais especificações 😨

(Desligado: Quanto tempo vai demorar até que eu misture vocês dois, D Howett e D Hewitt? :))

Este é um recurso crucial que falta.

Esta deve ser uma opção de configuração para os diferentes comandos. Por exemplo, eu gostaria disso para duplicateTab e splitPane , mas não para newTab .

a sequência de escape está documentada nas preferências do mac os terminal.app, conforme mostrado por este comentário alacritty / alacritty # 2937 (comentário)

No macOS, as sequências de escape são realmente especificadas em Terminal.app> Preferências ...> Perfis> Guia

Para registro, há um debate acalorado em https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7 sobre a especificação exata desse recurso. Duvido que iremos oferecer suporte a qualquer subconjunto deste recurso até que haja uma proposta realmente aceita lá - preferimos não introduzir outra implementação díspar até que haja um padrão real.

Eu recomendo que você faça o oposto :)

Muitos terminais implementaram com sucesso o OSC 7, copiando uns dos outros, resultando em usuários felizes.

E há alguém por aí que acha que não é bom o suficiente, ele acha que uma especificação formal é necessária; surge com um rascunho cheio de problemas, e o que eu não consigo entender de jeito nenhum, só está disposto a documentar um de dois irmãos. (Observação: parei de acompanhar esse tópico há alguns dias.)

O Terminal-WG não é uma autoridade formal, seus documentos não são "oficiais", não são "padrões" de qualquer forma. Não tem nem procedimentos adequados, pessoas com responsabilidades, direitos de voto, o que quer que seja; ninguém sabe o que é necessário para que um documento seja "aceito" ali, seja o que for que esse status signifique. É apenas uma coleção de pessoas aleatórias e desorganizadas tentando inventar algo útil. Não deixe que os debates pendentes não oficiais o impeçam de implementar um recurso comprovado há muito tempo.

Para registro, há um debate acalorado em https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7

Eu comentei sobre o problema mencionado naquele artigo também 😉

Para qualquer pessoa usando Bash (do Git para Windows), uma solução temporária que está me salvando é armazenar o novo caminho toda vez que você mudar de dir (alias do comando cd ) e, em seguida, cd lá quando um novo shell começou; isto está no meu _.bashrc: _

if [ "${PWD,,}" = "/c/windows/system32" ]; then
    if [ -f /tmp/pwd ]; then
        cd "$(< /tmp/pwd)"
    else
        cd ~
    fi
fi

cd() {
    command cd "$@"
    pwd > /tmp/pwd
}

Na verdade, estou testando se começo no System32 (meu local de início padrão do terminal), para que ainda possa digitar wt na barra de endereço do Explorer e começar em outro lugar, mas este bit é opcional e deve ser personalizado se seu shell começa em uma pasta diferente.

Não sou fluente o suficiente com o PowerShell ou outros shells, mas acho que você pode fazer algo parecido.

Ctrl + T deve abrir uma nova guia com o mesmo shell e o mesmo diretório.

Nem todo mundo concorda com essa afirmação.

Nem todo mundo concorda com essa afirmação.

Talvez muitos concordem. É assim que o aplicativo de terminal funciona na maioria dos desktops Linux.

Pelo menos pode ser feito como opção.

Olá, acredito que já esteja claro neste tópico que muitos concordam que esse é um recurso útil, e a equipe do Windows Terminal também está ciente disso. E também está claro que o problema aqui não é que eles não querem tornar isso configurável, mas eles precisam primeiro descobrir algumas coisas técnicas que impedem o recurso de ser possível .

Eu sigo este tópico para me manter atualizado sobre esse recurso e as discussões relacionadas, mas as mensagens como essa apenas bagunçam a interface e não ajudam. Quero pedir às pessoas que evitem postar mensagens que façam pouco mais do que reiterar pontos que já são conhecidos.

Pelo menos pode ser feito como uma opção

Isso é o que eu não entendo sobre a teimosia. Se você quiser ir contra o comportamento da maioria dos terminais, legal. Nem mesmo dando uma opção? Onde está a lógica disso? Mesmo Ctrl + Shit + D, que representa a duplicação de uma guia, não a duplica, pois o mantém no diretório padrão. Como se você tivesse um recurso duplicado que nem mesmo é duplicado.

Qual é o "material técnico" que impede esse recurso de ser possível? O código já existe. Já existe uma guia duplicada em Ctrl + Shift + D. Ele só precisa ser alimentado com o diretório de trabalho atual e você terá o comportamento com o qual a maioria das pessoas está acostumada e que as pessoas estão solicitando. Portanto, estou confuso sobre como isso tem "coisas técnicas" bloqueando-o.

Agradeço esse tipo de discussão porque é bastante claro que há teimosia envolvida, o que significa que esse tipo de discussão é necessário.

Ah, você está certo, a discussão original foi perdida, porque ela nunca foi vinculada a este tópico. Estou copiando o conteúdo de outra postagem (https://github.com/microsoft/terminal/issues/2427#issuecomment-521307534) aqui para referência:

https://github.com/microsoft/terminal/issues/1756#issuecomment -520048598

Apenas concordando;

_ (perfil, diretório de trabalho, ambiente var, etc) ._

Qualquer coisa sobre o _processo real_ na outra extremidade é, no caso geral, impossível de replicar. O processo conectado pode ser ssh.exe , cujas variáveis ​​de ambiente e diretório de trabalho não têm relação com o ambiente detectável e diretório de trabalho do lado do terminal. O mesmo, na verdade, estranhamente, se aplica ao WSL. Ele não usa "diretório de trabalho" e não expõe suas variáveis ​​de ambiente aos processos interessados ​​do Windows de forma alguma.

O PowerShell nem mesmo _set_ o diretório de trabalho atual, portanto, seu diretório também não pode ser detectado (!).

https://github.com/microsoft/terminal/issues/2315#issuecomment -519317472

Esta é uma daquelas coisas que são impossíveis no caso geral, mas _técnicamente possíveis_. Há muitos meandros aqui, como:

powershell
cd d:\users

bem, o PowerShell não é o primeiro processo que lançamos. ignoraríamos o caminho d:\users

(in powershell)
cd d:\users

ignoraríamos d:\users porque o powershell _não define realmente o diretório de trabalho atual_ (!!)

Se o seu "shell" for ssh [email protected] (onde definimos estritamente shell como "o primeiro processo que o Terminal gera em seu nome"), seu diretório de trabalho sempre será C:\windows\system32 independentemente do diretório de trabalho remoto é.

Eu prefiro não fornecer o recurso do que fornecer o recurso com tantas ressalvas que eles ocupariam uma página de documentação. ☹️ desculpe.

https://github.com/microsoft/terminal/issues/1536#issuecomment -519107586

Não, porque isso provavelmente seria impossível de fazer em um sentido geral. Como duplicaríamos uma instância do vim, por exemplo? E se o processo de primeiro plano abriu algum tipo de arquivo para acesso exclusivo - como poderíamos duplicar esse processo?

Se há uma maneira de fazer isso com segurança e geralmente sou todo ouvidos para propostas de soluções técnicas, mas não acho que seja algo possível, então não vou investigar isso.

Mesmo se o Powershell _did_ definir o diretório de trabalho, ainda não temos certeza de que é _tecnicamente_ possível no Windows obter o CWD de outro processo. Então esse é o material "técnico" que está impedindo que isso funcione. Eu adoraria adicionar isso como uma configuração. Mas, definitivamente, ainda há questões técnicas que precisam ser respondidas.

A solução que está sendo discutida neste tópico envolve a adição de suporte para outra sequência VT ao Terminal, que o _shell_ seria capaz de emitir para indicar ao Terminal em que caminho está. Esta sequência VT não é muito bem definida e tem casos extremos que ainda precisam ser resolvidos. Nomeadamente:

• O que acontece quando um shell WSL diz "meu CWD é /home/foo ? Não há como o Terminal saber que o caminho é um caminho WSL, ou mesmo a qual distro ele pertence, portanto, duplicar essa guia provavelmente acabaria em C:\home\foo (se existir)
• O que acontece quando você está conectado a outra máquina por SSH? O Terminal não será capaz de diferenciar esses caminhos dos caminhos em sua própria máquina local, então, novamente, duplicar esse caminho seria o comportamento errado
• Cada usuário precisará personalizar seu prompt para vários shells _manualmente_ para cooperar com esse comportamento. Este não é um bloqueador, mas significa que será uma configuração que não funcionará imediatamente.

Você está tentando duplicar os processos em execução? Vejamos o Linux, por exemplo. Se você estiver executando SSH em seu terminal e abrir uma nova guia, a nova guia não abre uma conexão SSH e navegue até onde você está na conexão SSH. Ele abre uma nova guia onde você está em sua máquina. Mesmo que o processo seja local e não SSH, ele não o executa. Tudo o que está sendo duplicado é a guia, não os processos em execução.

Parece que isso está sendo muito complicado. Você não está duplicando o VIM ou SSH ou qualquer outro aplicativo em execução. Você está duplicando o terminal e isso responde aos casos extremos:

• Para WSL, você não está navegando em seu local. Se o retorno for / home / foo, esse é o local. Se o local fosse C: \ home \ foo, ele retornaria / mnt / c / home / foo.
• SSH é um processo. Ele é executado no shell. Você não está duplicando processos. Outros terminais não. Você está duplicando a guia.
• Não tenho certeza do que o usuário teria que personalizar, mas desde quando a personalização é um problema?

Não há nada de errado em duplicar os processos. Tenho certeza de que alguns adorariam. Só que essa seria outra opção em cima da opção de duplicar as guias. Não deve ser um bloqueio de estrada. Isso é extra e opcional.

@PandaClone pode surpreendê-lo saber que _algumas pessoas definem ssh.exe como a primeira coisa que um perfil é iniciado, sem executá-lo a partir de um shell_.

Da mesma forma, não há realmente uma maneira de o Terminal interrogar wsl.exe , o aplicativo wrapper que se comunica com os processos do Linux, para fazê-lo dizer qual é o diretório de trabalho atual do primeiro processo em seu processo árvore.
Porque ele não usa a infraestrutura de diretório de trabalho do Windows, que armazena o WD no bloco de ambiente de processo, apenas usar as velhas APIs do Windows _ não é suficiente para dizer qual é o seu diretório de trabalho._

São problemas técnicos que temos que resolver. Caso contrário, escrevemos um recurso que só funciona para, tipo, 25% das pessoas.

Se for fácil: estamos sempre dispostos a aceitar contribuições da comunidade.

• Para WSL, você não está navegando em seu local. Se o retorno for / home / foo, esse é o local. Se o local fosse C: \ home \ foo, ele retornaria / mnt / c / home / foo.

Ah, mas veja, da maneira como esse recurso funciona conforme as especificações, o Terminal não sabe quem ou o que disse "O diretório de trabalho atual é /home/foo ". Isso poderia ser cmd.exe - então sim, o usuário quer C:\home\foo . Pode ser a distribuição do Ubuntu, ou do Fedora, ou pode ser ssh conectado ao centos ou qualquer outra possibilidade. Tudo o que o terminal obtém é uma string dizendo "este é o diretório de trabalho agora".

• Não tenho certeza do que o usuário teria que personalizar, mas desde quando a personalização é um problema?

Quase todo shell que o usuário executa precisará ser configurado manualmente para permitir o envio desta sequência. Para cmd usuários, eles precisarão configurar manualmente seu% PROMPT% para incluir a sequência $e]7;$P$e . bash usuários precisarão configurá-lo em seus PS1 . O PowerShell certamente terá outra maneira de fazer isso. A questão fundamental aqui é que os shells _não_ emitem essa sequência por padrão.

SSH não é um shell. Você pode definir seu perfil para executá-lo primeiro, mas ele ainda está sendo executado a partir do shell. É só que seu perfil está sendo instruído a executar um aplicativo imediatamente. Esse aplicativo pode ser qualquer coisa. Não é necessário SSH. Você pode instruir seu perfil a executar outro shell, se desejar.

E mesmo no caso de não haver terminal, como isso é um problema? Sempre há exceções. Padronizar para o diretório inicial quando não há diretório para ir está bom. Isso não é um problema onde você apenas "oh, isso não pode ser feito".

Além disso, esse é um recurso padrão na maioria dos terminais com guias. Execute qualquer distribuição Linux que tenha seus próprios tipos de terminal e todas exibem o comportamento de abrir uma nova guia. Este não é um recurso que será uma mágica revolucionária para o Terminal Windows. É um recurso padrão.

O Terminal não gera apenas conchas. Ele literalmente chama CreateProcess no que você fornece na configuração do perfil. O SSH não está sendo executado ou gerado por um shell.

Olha, estamos discutindo sobre o quão possível esse recurso é. Podemos apenas concordar que _nós queremos isso, todo mundo quer, e se tivéssemos uma maneira razoável de avançar que funcionasse na grande maioria dos casos de uso com os quais os usuários se preocupam_, já o teríamos feito? Estou tentando reduzir o número de vezes que temos que dizer “isso não pode ser feito” com algum planejamento inicial e trabalho de design.

Não é uma mágica inovadora, é apenas complicado pelo modelo de processo do Windows e WSL e achamos que pode falhar em algumas circunstâncias. Ninguém está dizendo nada mais do que isso.

• Para WSL, você não está navegando em seu local. Se o retorno for / home / foo, esse é o local. Se o local fosse C: \ home \ foo, ele retornaria / mnt / c / home / foo.

Ah, mas veja, da maneira como esse recurso funciona conforme as especificações, o Terminal não sabe quem ou o que disse "O diretório de trabalho atual é /home/foo ". Isso poderia ser cmd.exe - então sim, o usuário quer C:\home\foo . Pode ser a distribuição do Ubuntu, ou do Fedora, ou pode ser ssh conectado ao centos ou qualquer outra possibilidade. Tudo o que o terminal obtém é uma string dizendo "este é o diretório de trabalho agora".

Como ele não sabe quem ou o que disse que é o diretório de trabalho atual? Você é quem está pedindo por isso. Você sabe se é um prompt de comando ou um WSL ou um PowerShell. Você sabe de onde vem, então sabe como formatar o local.

• Não tenho certeza do que o usuário teria que personalizar, mas desde quando a personalização é um problema?

Quase todo shell que o usuário executa precisará ser configurado manualmente para permitir o envio desta sequência. Para cmd usuários, eles precisarão configurar manualmente seu% PROMPT% para incluir a sequência $e]7;$P$e . bash usuários precisarão configurá-lo em seus PS1 . O PowerShell certamente terá outra maneira de fazer isso. A questão fundamental aqui é que os shells _não_ emitem essa sequência por padrão.

Como isso é um problema? Este não seria o primeiro aplicativo a exigir configuração e não será o último. Nem tudo é plug and play e isso é compreensível. Se a única maneira de fazer isso funcionar é o usuário exigir uma configuração, como é esse ponto de parada?

O que acontece quando um shell WSL diz "meu CWD é / home / foo? Não há como o Terminal saber que o caminho é um caminho WSL, ou mesmo a qual distro ele pertence, portanto, duplicar esta guia provavelmente terminaria em C: \ home \ foo (se existir)

Eu só posso realmente falar por mim, mas se eu tivesse uma guia aberta usando um perfil, navegado em algum lugar específico e, em seguida, abrisse uma nova guia em um perfil diferente, não me surpreenderia ou desapontaria minimamente se o diretório de trabalho não o fizesse transitar, e o padrão foi usado em seu lugar.

Acho que você entende que a maioria das pessoas que solicitam esse recurso não apresenta o comportamento em terminais como os incluídos no GNOME e no macOS. Esses terminais não precisam lidar com as mesmas complexidades que este, mas, ao mesmo tempo, não acho que ninguém esteja esperando que você tente lidar com casos extremos que simplesmente não existem no software que eles estão usando como um ponto de referência.

Parece uma tarefa bastante complicada, embora você reduza um pouco o escopo. Espero que seja encontrada uma maneira de incluir alguma versão desse recurso, pois é uma boa economia de tempo.

Este caso de uso poderia ser tratado por # 4472 em curto prazo? Eu pessoalmente ficaria satisfeito com alguma variante de cmd.exe /c "wt.exe" new-tab -p "Ubuntu-20.04" -d $(pwd) (provavelmente ligada a uma macro Bash) que abriria uma nova guia na janela focada mais recentemente (que é quase certamente a janela em que digitei o comando )

Vou arriscar e dizer que implementar detecção para o diretório atual do processo raiz é mais fácil do que implementar remoting por linha de comando e IPC para fazer o WT abrir abas na mesma janela: smile:

uau, acabei de chegar aqui e percebi que parece precisar de uma longa jornada :)

Descobrimos que no terminal do Windows poderíamos dividir as janelas do shell pressionando o atalho alt + shift + D, mas não é definido para o mesmo diretório

https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7#note_552774

Eu vim com uma solução alternativa: mude o diretório inicial.

Coloque esta função em $PROFILE (certifique-se de ajustar $path )

function sd {
    $path = 'C:\Users\Admin\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'
     ((Get-Content -path $path) -replace '"startingDirectory":.*', ("`"startingDirectory`": `"$pwd`"") -replace "\\", "\\") | Set-Content -Path $path
}

.. e você poderá abrir uma nova aba no mesmo diretório quase sem problemas, apenas certifique-se de digitar sd antes de abrir uma nova aba.

Obviamente, a desvantagem é que startingDirectory é alterado toda vez que a função é chamada.

Seria melhor usar esta abordagem com um re-mapeador de teclas, de modo que quando Ctrl+T for pressionada a função seja chamada automaticamente, e quando Ctrl+F4 for pressionada startingDirectory seja revertida de volta ao seu valor original.

Solução alternativa

Dentro de tudo o perfil que você está usando exemplo profile.sh ou .zshrc criar um arquivo ~ / paths.sh localizado dentro de seu diretório $ HOME. Os caminhos serão atualizados sempre que você chamar setCWD

Esta solução substitui o StartingDirectory completamente. Sempre que você gerar um novo terminal, chame setCWD antes de gerar o terminal e ele sempre iniciará na última vez em que você chamou

Observe que fiz isso dentro de .zshrc

Código:

source ~/paths.sh

if [[ $SAVED_PWD != $PWD  ]]
then
  cd $SAVED_PWD
fi

function setCWD(){
  echo export SAVED_PWD=$(pwd) > ~/paths.sh
}

Pode ser necessário criar um arquivo inicial, então apenas chame setCWD .

BTW, se você estiver usando o autohotkey, aqui está um script bom e rápido para fazer as coisas funcionarem

Faça um arquivo chamado windows-terminal.ahk e cole este código abaixo. Execute o arquivo e está tudo pronto. (Eu recomendo mover este arquivo para a seção de inicialização para que, ao reiniciar, essa funcionalidade seja reaplicada.

#IfWinActive, ahk_exe WindowsTerminal.exe
  ^t::
    Send, setCWD {enter}
    Send, ^t

Pessoal, isso é muito importante para a produtividade, quase como se estivesse acima de tudo. Por favor, corrija isso, eu e meus amigos ficaremos felizes em abandonar todos os outros emuladores de terminal inferiores.

Parece que a tentativa de 'padronizar' o OSC 7 no terminal-wg foi interrompida .

Ainda há interesse em implementar o OSC 7 basicamente como está em Terminal.app ?

Dado isso, teríamos "host e CWD atuais" para um determinado terminal, o que apenas denuncia a discussão de 'hacking de processo'; e então pode decidir / implementar os comportamentos do usuário para fazer uso dessas informações, por exemplo:

• um comando "nova aba no diretório atual";
• fazendo com que "dividir" faça isso por padrão;
• algo mágico para distinguir uma sessão WSL de uma sessão do Windows (se eles ainda relatam o mesmo nome de host? Eu não olhei ...);
• uma opção de configuração para "suprimir OSC 7" em perfis nos quais você _sabe_ enviará um OSC 7 de aparência válida que você não deseja usar, como sshing para uma máquina remota que reivindica o mesmo nome de host de seu host Windows;
• expor o valor em algo que você pode inserir na linha de comando, de forma que sua sessão ssh ou wsl _pode_ aparecer no mesmo diretório de trabalho que você acabou de duplicar.

Essa discussão foi muito focada na primeira parte (obter o CWD atual), mas suspeito que a segunda parte é a que precisará de mais consideração, com base nos comentários existentes até agora acima. Mesmo para essa lista de idéias, tenho certeza que existe uma objeção razoável para _todos_ deles.

Para aqueles que ainda estão interessados ​​neste tópico, fiz um primeiro PR no # 7668. Este é um ping amigável. Eu realmente adoraria ouvir de todos sobre isso.

Qual é o objetivo de várias guias, especialmente a duplicação rápida, se elas não herdam o diretório atual? Este é um recurso tão importante. Por que não adicionar uma solução alternativa "hacky" por enquanto? Eu realmente não vejo problema em extrair CWD de um processo no Windows se isso aumentar a produtividade para todos os usuários, considerando que o próprio Windows contém várias soluções desse tipo por mais de 20 anos.

Não consigo entender por que esse recurso não é o padrão. Estou realmente perplexo quanto ao motivo pelo não usar o Terminal e, em vez disso, usar o explorer e clicar com o botão direito do mouse no diretório que desejo abrir o shell e selecionar "Abrir janela do PowerShell aqui" porque é mais rápido do que acertar alt+shift+d então ter que cd para o lugar certo.

Terminal adiciona muita qualidade de vida para desenvolvedores de Windows. Esse recurso seria um grande avanço para mim (e eu suspeito que outros). Vou acrescentar minha voz em defender que esse recurso seja uma prioridade.

Não consigo entender por que esse recurso não é o padrão.

Não consigo entender por que as pessoas não se dão ao trabalho de ler toda a investigação que foi feita neste tópico, em # 7668, # 8214, # 8166, e nos outros tópicos vinculados, para entender por que este é realmente um problema difícil de resolver. Acontece que você não pode simplesmente fazer com que um aplicativo cliente emita seu caminho - porque o Terminal não sabe _necessariamente_ se é um caminho do Windows, WSL ou cygwin.

É uma coisa boa termos um monte de colaboradores talentosos que estão trabalhando duro para descobrir a maneira certa de implementar o suporte para esse recurso, sem quebrar a compatibilidade com versões anteriores para outros aplicativos. _Já esta semana_ propusemos uma solução com a qual estamos satisfeitos, não deve demorar muito para que ela seja implementada.

Obrigado @ zadjii-msft!

Ao reler meu comentário, estou percebendo que parece superacusatório e essa não era minha intenção. Eu vim aqui para dizer o seguinte:

Terminal adiciona muita qualidade de vida para desenvolvedores de Windows. Esse recurso seria um grande avanço para mim (e eu suspeito que outros). Vou acrescentar minha voz em defender que esse recurso seja uma prioridade.

E que minha experiência de usuário até agora tem sido esta:

Não consigo entender por que esse recurso não é o padrão. Eu realmente estou perplexo quanto ao motivo pelo qual não há nem mesmo uma maneira de habilitar esse recurso. Esta é a maior experiência do usuário ... etc

Eu provavelmente deveria ter colocado "como um usuário" no início do meu primeiro parágrafo.

Peço desculpas por qualquer ofensa que cometi.