현재 디렉토리에 대한 터미널 에뮬레이터의 믿음을 설정하는 "표준" 이스케이프 시퀀스(OSC 7 ; URI ST)가 있습니다. 그것은 macOS Terminal.app에서 시작되었으며 나중에 GNOME Terminal과 내가 아는 한 Konsole을 포함한 다른 것들에 의해 채택되었습니다.

또 다른 가능한 접근 방식은 일부 OS별 해킹을 수행하여 하위 프로세스의 내부 상태(또는 더 나아가 하위 프로세스까지)를 검사하는 것입니다.

또 다른 가능성은 두 가지를 혼합하는 것입니다. 예를 들어 OSC 7을 통해 설정된 디렉토리로 이동하고, 그렇지 않은 경우 프로세스를 파헤칩니다.

OSC 7 접근 방식의 장점은 자식 프로세스를 따라야 하는 시점과 하지 말아야 하는 시점에 관해 영리하다는 것입니다. 예를 들어 다른 중첩 서브쉘을 시작하면 해당 서브쉘도 이 시퀀스를 방출하기 때문에 해당 서브쉘의 서브디렉토리가 고려됩니다. 그러나 내부적으로 디렉토리(예: make)를 변경하는 앱을 실행하면 운 좋게도 사용되는 make의 내부 하위 디렉토리가 아닙니다.

OSC 7의 단점은 셸이나 중요한 다른 앱의 협력이 필요하다는 것입니다.

저는 이 프로젝트가 오픈 소스인 동안 이 기능 요청을 거부해 왔으며 OSC 7에 대해 배운 적이 없습니다. 이것은 _매우 흥미진진합니다._

최하위 프로세스의 CWD를 파헤치기 위해 프로세스 트리를 크롤링하는 것은 좋지 않지만 OSC 7을 지원하게 되어 매우 기쁩니다.

참고로 저는 Alacritty에 대한 OSC 7 처리에 대해 물었습니다. 결국 이 문제는 gitlab의 "터미널 WG"에서 생성되었습니다: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/20

해당 티켓에는 많은 움직임이 없지만 관심을 가질 수 있습니다. 특히 OSC 7의 "공식" 사양이 어떻게 생겼는지에 대한 의견이 있는 경우.

따라서 기록을 위해 https://github.com/jwilm/alacritty/pull/2937 의 스레드에 꽤 훌륭한 토론이 있습니다.

솔직히 말하면 이미 존재하는 사실상의 표준인 OSC 7 ; <URI> ST 메커니즘을 사용해도 괜찮습니다. 이보다 더 형식적인 것이 필요한지 잘 모르겠습니다.

아니 무서운 생각이 들었어. bash 가 이를 내보내도록 구성되어 있고 누군가가 WSL에서 bash 를 실행한다고 가정해 보겠습니다. 누군가 작업 디렉토리를 /home/zadjii 로 설정하려고 하면 어떻게 해야 합니까? 우리는 어떻게:

1. 이것이 Windows 경로가 아닌 WSL 경로임을 알려줍니다.
2. 이것이 어떤 WSL 배포판에서 왔는지 아십니까?

"이것은 Windows exe가 아니라 WSL 배포판입니다"라는 속성을 추가해야 합니까? 이를 설정하지 않은 사용자는 어떻게 됩니까? 복제 탭 기능이 작동하지 않는 것뿐입니까(효과적으로 자동으로)?

그러면 다음 부분이 어려워집니다. 이 명령이 SSH를 통해 출력되면 어떻게 됩니까? 터미널은 더 이상 이 머신에 경로가 없다는 것을 알 수 없겠죠? Terminal.app은 이것을 어떻게 처리합니까?

아마도 이것은 더 많은 사양이 필요할 것입니다 😨

(끄기: D Howett과 D Hewitt 두 사람을 섞을 때까지 얼마나 걸립니까? :))

이것은 중요한 누락 기능입니다.

이것은 다른 명령에 대한 구성 옵션이어야 합니다. 예를 들어 duplicateTab 및 splitPane 에 대해서는 이것을 원하지만 newTab 에는 원하지 않습니다.

이스케이프 시퀀스는 이 주석 alacritty/alacritty#2937(comment)에 표시된 대로 mac os terminal.app 기본 설정에 문서화되어 있습니다.

macOS에서 이스케이프 시퀀스는 실제로 Terminal.app > Preferences... > Profiles > Tab에서 지정됩니다.

기록을 위해 https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7 에서 정확히 이 기능의 사양에 대한 열띤 토론이 있습니다. 실제로 승인된 제안이 있을 때까지 이 기능의 하위 집합을 지원할 것인지 의심스럽습니다. 실제 표준이 있을 때까지 다른 별도의 구현을 도입하지 않는 것이 좋습니다.

반대로 하시는걸 추천드려요:)

꽤 많은 터미널이 OSC 7을 성공적으로 구현하여 서로 복사하여 행복한 사용자를 얻었습니다.

그리고 현재 충분하지 않다고 생각하는 누군가가 있습니다. 그는 공식적인 사양이 필요하다고 생각합니다. 문제로 가득 찬 초안을 작성하고 전혀 이해할 수없는 것은 두 형제 중 한 명만 문서화하려는 것입니다. (참고: 저는 며칠 전에 해당 스레드를 팔로우하지 않았습니다.)

Terminal-WG는 공식 기관이 아니며 해당 문서는 "공식"이 아니며 법적으로 "표준"이 아닙니다. 적절한 절차, 책임 있는 사람, 투표권 등도 없습니다. 이 상태가 의미하는 바가 무엇이든 간에 문서를 "승인"하는 데 무엇이 필요한지 아무도 모릅니다. 유용한 무언가를 생각해 내기 위해 노력하는 무작위로 조직되지 않은 사람들의 모음입니다. 이러한 비공식적인 보류 중인 토론으로 인해 오랫동안 입증된 기능을 구현하지 못하게 하지 마십시오.

기록을 위해 https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7 에서 열띤 토론이

나는 그 홍보에서도 언급된 문제에 대해 그것을 논평했다 😉

Bash(Windows용 Git에서)를 사용하는 사람은 임시 해결 방법으로 dir( cd 명령에 별칭 지정)을 변경할 때마다 새 경로를 저장한 다음 새 셸이 시작된다; 이것은 내 _.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
}

실제로 System32(내 터미널 기본 시작 위치)에서 시작하는지 테스트하고 있으므로 Explorer 주소 표시줄에 wt 를 입력하고 다른 곳에서 시작할 수 있지만 이 비트는 선택 사항이며 다음과 같은 경우 사용자 지정해야 합니다. 쉘은 다른 폴더에서 시작됩니다.

저는 PowerShell이나 다른 셸에 대해 충분히 유창하지는 않지만 비슷한 작업을 할 수 있을 것 같습니다.

Ctrl+T는 동일한 쉘과 동일한 디렉토리로 새 탭을 열어야 합니다.

모든 사람이 그 주장에 동의하는 것은 아닙니다.

모든 사람이 그 주장에 동의하는 것은 아닙니다.

아마도 많은 사람들이 동의합니다. 이것이 터미널 앱이 대부분의 Linux 데스크탑에서 작동하는 방식입니다.

적어도 옵션으로 만들 수 있습니다.

안녕하세요, 이 스레드에서 많은 사람들이 이것이 유용한 기능이라는 데 동의하고 Windows 터미널 팀도 이 사실을 알고 있다는 것이 이미 분명하다고 생각합니다. 그리고 여기서 문제는 그들이 이것을 구성 가능하게 만들고 싶지 않다는 것이 아니라 먼저 기능이 가능 하지 못하게 하는 몇 가지 기술적인 요소를 파악해야 한다는 것입니다.

나는 이 기능과 관련 토론에 대한 최신 정보를 유지하기 위해 이 스레드를 따르지만 이와 같은 메시지는 인터페이스를 어지럽힐 뿐 도움이 되지 않습니다. 이미 알려진 요점을 되풀이하는 것 외에는 별 의미가 없는 글은 자제해주셨으면 합니다.

적어도 옵션으로 만들 수 있습니다.

이것은 내가 고집에 대해 이해하지 못하는 것입니다. 대부분의 터미널이 작동하는 방식에 반대하고 싶다면 멋지다. 그래도 선택권을 주지 않습니까? 거기에 논리가 어디 있습니까? 탭 복제를 나타내는 Ctrl+Shit+D도 기본 디렉토리에 고정되기 때문에 실제로 탭을 복제하지 않습니다. 중복되지 않는 중복 기능이 있는 것처럼.

이 기능을 사용할 수 없도록 하는 "기술적 요소"는 무엇입니까? 코드가 이미 존재합니다. Ctrl+Shift+D에 이미 중복 탭이 ​​있습니다. 현재 작업 디렉토리를 제공하기만 하면 되며 대부분의 사람들에게 익숙하고 사람들이 요청하는 동작을 갖게 됩니다. 그래서 나는 이것이 "기술적인 것들"이 그것을 차단하는 방법에 혼란 스럽습니다.

나는 이러한 유형의 토론이 필요하다는 것을 의미하는 완고함이 관련되어 있다는 것이 매우 분명하기 때문에 이러한 유형의 토론에 감사드립니다.

아 맞습니다. 원래 토론은 이 스레드에 연결되지 않았기 때문에 손실되었습니다. 참고로 여기에 다른 게시물(https://github.com/microsoft/terminal/issues/2427#issuecomment-521307534)의 내용을 복사하고 있습니다.

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

그냥 차임;

_ (프로필, 작업 디렉토리, 환경 변수 등)._

다른 쪽 끝에 있는 _실제 프로세스_에 대한 모든 것은 일반적으로 복제가 불가능합니다. 연결된 프로세스는 ssh.exe 일 수 있으며, 환경 변수와 작업 디렉토리는 터미널 측에서 감지 가능한 환경 및 작업 디렉토리와 관련이 없습니다. 실제로 이상하게도 동일한 것이 WSL에도 적용됩니다. "작업 디렉토리"를 사용하지 않으며 어떤 방식으로든 관심 있는 Windows 프로세스에 환경 변수를 노출하지 않습니다.

Powershell은 현재 작업 디렉토리를 _set_하지도 않으므로 해당 디렉토리도 감지할 수 없습니다(!).

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

이것은 일반적인 경우에는 불가능하지만 _기술적으로는 가능한_ 것 중 하나입니다. 여기에는 다음과 같이 많은 복잡성이 있습니다.

powershell
cd d:\users

글쎄, powershell은 우리가 시작한 첫 번째 프로세스가 아닙니다. d:\users 경로를 무시합니다.

(in powershell)
cd d:\users

powershell _실제로 현재 작업 디렉토리를 설정하지 않기 때문에 우리는 d:\users 무시합니다_ (!!)

"쉘"이 ssh [email protected] (여기서 쉘은 "사용자를 대신하여 터미널이 생성되는 첫 번째 프로세스"로 엄격하게 정의됨) 작업 디렉토리는 무엇이든 상관없이 항상 C:\windows\system32 가 됩니다. 원격 작업 디렉토리입니다.

설명서 페이지를 채울 만큼 많은 주의 사항이 있는 기능을 제공하는 것보다 기능을 제공하지 않는 것이 좋습니다. ☹️ 죄송합니다.

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

아니요, 일반적인 의미에서 그렇게 하는 것은 거의 불가능하기 때문입니다. 예를 들어 vim 인스턴스를 어떻게 복제할까요? 포그라운드 프로세스가 배타적 액세스를 위해 일종의 파일을 열면 어떻게 될까요? 어떻게 그 프로세스를 복제할 수 있을까요?

이 작업을 안전하게 수행할 수 있는 방법이 있다면 일반적으로 제안된 기술 솔루션에 대해 귀를 기울이고 있지만 가능한 일이라고 생각하지 않으므로 조사하지 않을 것입니다.

Powershell이 ​​작업 디렉토리를 _did_ 설정했더라도 Windows에서 다른 프로세스의 CWD를 가져오는 것이 _기술적으로_ 가능하다는 점은 아직 확신하지 못합니다. 이것이 작동을 방해하는 "기술적"인 것입니다. 이것을 설정으로 추가하고 싶습니다. 그러나 여전히 답변이 필요한 기술적인 질문이 있습니다.

이 스레드에서 논의되고 있는 솔루션은 터미널에 다른 VT 시퀀스에 대한 지원을 추가하는 것입니다. _shell_은 터미널이 어떤 경로에 있는지 알려주기 위해 내보낼 수 있습니다. 이 VT 시퀀스는 매우 잘 정의되어 있지 않으며 여전히 해결해야 하는 극단적인 경우. 즉:

• WSL 셸이 "내 CWD는 /home/foo 입니까? 터미널이 경로가 WSL 경로인지 또는 그것이 속한 배포판인지 알 수 있는 방법이 없으므로 이 탭을 복제하면 C:\home\foo (있는 경우)
• SSH를 통해 다른 컴퓨터에 연결하면 어떻게 됩니까? 터미널은 해당 경로를 로컬 시스템의 경로와 구별할 수 없으므로 다시 해당 경로를 복제하는 것은 잘못된 동작입니다.
• 모든 사용자는 이 동작에 협력하기 위해 다양한 쉘에 대한 프롬프트를 _수동으로_ 사용자 정의해야 합니다. 이것은 차단기가 아니지만 즉시 사용할 수 있는 설정이 아님을 의미합니다.

실행 중인 프로세스를 복제하려고 합니까? 예를 들어 리눅스를 보자. 터미널에서 SSH를 실행하고 새 탭을 여는 경우 새 탭은 SSH 연결을 열지 않고 SSH 연결에 있는 위치를 찾습니다. 그것은 당신이 당신의 컴퓨터에있는 새 탭을 엽니 다. 프로세스가 로컬이고 SSH가 아닌 경우에도 프로세스를 실행하지 않습니다. 복제되는 것은 실행 중인 프로세스가 아니라 탭뿐입니다.

이것은 너무 복잡하게 들리는 것 같습니다. VIM, SSH 또는 실행 중인 다른 애플리케이션을 복제하지 않습니다. 터미널을 복제하고 있으며 이것이 극단적인 경우에 답합니다.

• WSL의 경우 로컬을 탐색하지 않습니다. 반환이 /home/foo이면 위치입니다. 위치가 C:\home\foo이면 /mnt/c/home/foo를 반환합니다.
• SSH는 프로세스입니다. 쉘에서 실행됩니다. 프로세스를 복제하지 않습니다. 다른 터미널은 그렇지 않습니다. 탭을 복제하고 있습니다.
• 사용자가 무엇을 사용자 지정해야 하는지 잘 모르겠지만 언제부터 사용자 지정 문제가 발생했습니까?

프로세스를 복제하는 데 아무런 문제가 없습니다. 나는 몇몇 사람들이 그것을 좋아할 것이라고 확신합니다. 탭을 복제하는 옵션 외에 다른 옵션일 뿐입니다. 장애물이 되어서는 안 됩니다. 그것은 추가 및 선택 사항입니다.

@PandaClone _ 어떤 사람들은 ssh.exe를 셸에서 실행하지 않고 프로필이 실행되는 첫 번째 항목으로 설정한다는 사실을 알고 놀라게 될 것입니다.

그렇지 않은 것처럼 터미널이 wsl.exe , Linux 프로세스와 통신하는 래퍼 응용 프로그램을 조사하여 현재 작업 디렉토리가 해당 프로세스의 첫 번째 프로세스에 대해 말하도록 하는 방법은 없습니다. 나무.
프로세스 환경 블록에 WD를 저장하는 Windows 작업 디렉터리 인프라를 사용하지 않기 때문에 지루한 이전 Windows API를 사용하는 것만으로는 작업 디렉터리가 무엇인지 알 수 없습니다._

이것들은 우리가 해결해야 하는 기술적인 문제입니다. 그렇지 않으면 25%의 사람들에게만 작동하는 기능을 작성합니다.

그것이 쉬운 것으로 판명되면: 우리는 항상 커뮤니티 기부를 기꺼이 받아들입니다.

• WSL의 경우 로컬을 탐색하지 않습니다. 반환이 /home/foo이면 위치입니다. 위치가 C:\home\foo이면 /mnt/c/home/foo를 반환합니다.

아, 하지만 이 기능이 사양대로 작동하는 방식을 보면 터미널은 "현재 작업 디렉토리는 /home/foo 입니다."라고 말한 사람이나 내용을 알지 못합니다. 이것은 cmd.exe 수 있습니다. 그렇다면 사용자는 C:\home\foo 원합니다. 이것은 Ubuntu 배포판 또는 Fedora 배포판이거나 centos 또는 다른 가능성에 연결된 ssh일 수 있습니다. 터미널이 받는 모든 것은 "이것은 현재 작업 디렉토리입니다"라는 문자열입니다.

• 사용자가 무엇을 사용자 지정해야 하는지 잘 모르겠지만 언제부터 사용자 지정 문제가 발생했습니까?

사용자가 실행하는 거의 모든 셸은 이 시퀀스를 보낼 수 있도록 수동으로 구성해야 합니다. cmd 사용자의 경우 $e]7;$P$e 시퀀스를 포함하도록 %PROMPT%를 수동으로 구성해야 합니다. bash 사용자는 PS1 에서 설정해야 합니다. PowerShell에는 확실히 다른 방법이 있습니다. 하지만 여기서 근본적인 문제는 쉘이 기본적으로 이 시퀀스를 _내지 않는다는 것입니다.

SSH는 쉘이 아닙니다. 프로필을 먼저 실행하도록 설정할 수 있지만 여전히 셸에서 실행되고 있습니다. 귀하의 프로필에 즉시 응용 프로그램을 실행하라는 지시가 있을 뿐입니다. 그 응용 프로그램은 무엇이든 될 수 있습니다. SSH일 필요는 없습니다. 원하는 경우 프로필에 다른 셸을 실행하도록 지시할 수 있습니다.

그리고 단말기가 없는데도 그게 무슨 문제야? 항상 예외가 있습니다. 이동할 디렉토리가 없을 때 홈 디렉토리로 기본 설정하는 것은 괜찮습니다. 그것은 당신이 "아, 이것은 할 수 없다"는 문제가 아닙니다.

또한 이것은 탭이 있는 대부분의 터미널에서 표준으로 사용되는 기능입니다. 고유한 터미널 풍미가 있는 Linux 배포판을 실행하면 모두 새 탭을 여는 이러한 동작을 나타냅니다. 이것은 Windows 터미널의 획기적인 마법이 될 기능이 아닙니다. 표준 기능입니다.

터미널은 쉘만 생성하지 않습니다. 프로필 구성에서 제공한 항목에 대해 말 그대로 CreateProcess 를 호출합니다. SSH는 셸에서 실행되지 않거나 셸에서 생성되지 않습니다.

보세요, 우리는 이 기능이 얼마나 가능한지에 대해 논쟁하고 있습니다. 우리는 _우리가 이것을 원하고, 모두가 원하며, 사용자가 관심을 갖는 대부분의 사용 사례에서 작동하는 합리적인 방법이 있었다면 이미 했을 것이라는 데 동의할 수 있습니까? 미리 계획하고 디자인하는 작업을 통해 "그것은 할 수 없는 일"이라고 말해야 하는 횟수를 줄이려고 노력하고 있습니다.

이것은 획기적인 마법이 아니라 Windows 및 WSL 프로세스 모델에 의해 복잡할 뿐이며 일부 상황에서는 실패할 것이라고 생각합니다. 아무도 그 이상을 말하지 않습니다.

• WSL의 경우 로컬을 탐색하지 않습니다. 반환이 /home/foo이면 위치입니다. 위치가 C:\home\foo이면 /mnt/c/home/foo를 반환합니다.

아, 하지만 이 기능이 사양대로 작동하는 방식을 보면 터미널은 "현재 작업 디렉토리는 /home/foo 입니다."라고 말한 사람이나 내용을 알지 못합니다. 이것은 cmd.exe 수 있습니다. 그렇다면 사용자는 C:\home\foo 원합니다. 이것은 Ubuntu 배포판 또는 Fedora 배포판이거나 centos 또는 다른 가능성에 연결된 ssh일 수 있습니다. 터미널이 받는 모든 것은 "이것은 현재 작업 디렉토리입니다"라는 문자열입니다.

현재 작업 디렉토리가 누구인지 또는 무엇인지 어떻게 알 수 없습니까? 당신이 그것을 요구하는 사람입니다. 명령 프롬프트인지 WSL인지 PowerShell인지 알 수 있습니다. 출처를 알고 있으므로 위치 형식을 지정하는 방법을 알 수 있습니다.

• 사용자가 무엇을 사용자 지정해야 하는지 잘 모르겠지만 언제부터 사용자 지정 문제가 발생했습니까?

사용자가 실행하는 거의 모든 셸은 이 시퀀스를 보낼 수 있도록 수동으로 구성해야 합니다. cmd 사용자의 경우 $e]7;$P$e 시퀀스를 포함하도록 %PROMPT%를 수동으로 구성해야 합니다. bash 사용자는 PS1 에서 설정해야 합니다. PowerShell에는 확실히 다른 방법이 있습니다. 하지만 여기서 근본적인 문제는 쉘이 기본적으로 이 시퀀스를 _내지 않는다는 것입니다.

그게 어떻게 문제야? 이것은 구성이 필요한 첫 번째 응용 프로그램이 아니며 마지막 응용 프로그램도 아닙니다. 모든 것이 플러그 앤 플레이 방식은 아니며 이해할 수 있습니다. 이 작업을 수행하는 유일한 방법이 사용자가 구성을 요구하는 것이라면 그 중지 지점은 어떻습니까?

WSL 셸에서 "내 CWD는 /home/foo입니까? 터미널이 경로가 WSL 경로인지, 심지어 어떤 배포판에 속하는지 알 수 있는 방법이 없으므로 이 탭을 복제하면 C: \home\foo (존재하는 경우)

나는 정말로 나 자신에 대해서만 말할 수 있지만 한 프로필을 사용하여 탭을 열고 특정 위치로 이동한 다음 다른 프로필에서 새 탭을 연 경우 작업 디렉토리가 이월되고 기본값이 대신 사용되었습니다.

이 기능을 요청하는 대부분의 사람들은 GNOME 및 macOS에 포함된 터미널과 같은 터미널에서 동작이 누락되었음을 이해하고 있습니다. 그 터미널은 이것이 하는 것과 같은 복잡성을 처리할 필요가 없지만 동시에 소프트웨어에 존재하지 않는 엣지 케이스를 스마트하게 처리하려고 시도하고 현명하게 처리하기를 기대하는 사람은 아무도 없다고 생각합니다. 기준점으로 사용합니다.

범위를 다소 줄여도 꽤 털이 많은 작업처럼 들립니다. 시간을 절약할 수 있기 때문에 이 기능의 일부 버전을 포함할 수 있는 방법을 찾을 수 있기를 바랍니다.

이 사용 사례를 단기간에 #4472로 처리할 수 있습니까? 나는 개인적으로 몇 가지 변종에 만족 것 cmd.exe /c "wt.exe" new-tab -p "Ubuntu-20.04" -d $(pwd) 나는에 명령을 입력하는 창이 거의 확실하다 (가장 최근에 초점을 맞추고 창에서 새 탭을 열 것 (아마 배쉬 매크로에 바인딩) ).

사지에 나가서 루트 프로세스의 현재 디렉토리에 대한 감지를 구현하는 것이 WT가 동일한 창에서 탭을 열도록 하기 위해 명령줄 원격 및 IPC를 구현하는 것보다 더 쉽다고 말합니다.

와우, 방금 여기에 와서 긴 여행이 필요하다는 것을 깨달았습니다. :)

우리는 Windows 터미널에서 단축키 alt+shift+D를 눌러 쉘 창을 분할할 수 있음을 발견했지만 동일한 디렉토리로 설정되지 않았습니다.

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

해결 방법이 있습니다: 시작 디렉토리를 변경하십시오.

이 함수를 $PROFILE 넣습니다( $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
}

.. 거의 번거로움 없이 동일한 디렉토리에서 새 탭을 열 수 있습니다. 새 탭을 열기 전에 sd 를 입력하십시오.

물론 단점은 startingDirectory 함수가 호출될 때마다 변경된다는 것입니다.

이 접근 방식을 키 재매퍼와 함께 사용하여 Ctrl+T 를 누르면 함수가 자동으로 호출되고 Ctrl+F4 를 누르면 startingDirectory 로 되돌아갑니다. 원래의 가치로 돌아갑니다.

대체 솔루션

예를 들어 profile.sh 또는 .zshrc를 사용하는 프로필 내에서 $HOME 디렉터리에 있는 ~/paths.sh 파일을 만듭니다. setCWD 를 호출할 때마다 경로가 업데이트됩니다.

이 솔루션은 startingDirectory를 완전히 재정의합니다. 새 터미널을 생성할 때마다 터미널을 생성하기 전에 setCWD를 호출하고 항상 마지막으로 setCWD 를 호출한 직접에서 시작합니다.

.zshrc

암호:

source ~/paths.sh

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

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

초기 파일을 생성해야 할 수도 있으므로 그냥 setCWD 를 호출

BTW 자동 핫키를 사용하는 경우 작동하도록 하는 훌륭하고 빠른 스크립트가 있습니다.

windows-terminal.ahk 라는 파일을 만들고 이 코드를 아래에 붙여넣습니다. 파일을 실행하면 모든 설정이 완료됩니다. (이 파일을 시작 섹션으로 이동하여 다시 시작할 때 이 기능이 다시 적용되도록 하는 것이 좋습니다.

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

여러분, 이것은 생산성에 매우 중요합니다. 거의 모든 것보다 중요합니다. 이 문제를 해결하십시오. 나와 내 친구들은 다른 모든 열등한 터미널 에뮬레이터를 기꺼이 버릴 것입니다.

터미널-wg에서 OSC 7을 '표준화'하려는 시도 가 중단된 것 같습니다 .

기본적으로 Terminal.app에 있는 것처럼 OSC 7을 구현하는 데 여전히 관심이 있습니까?

주어진 터미널에 대해 "현재 호스트 및 CWD"가 있다는 점을 감안할 때 '프로세스 해킹' 토론을 노골적으로 표현합니다. 그런 다음 해당 정보를 사용하기 위해 사용자 행동을 결정/구현할 수 있습니다. 예:

• "현재 디렉토리의 새 탭" 명령;
• 기본적으로 "분할"을 수행합니다.
• WSL 세션을 Windows 세션과 구별하는 마법 같은 것(같은 호스트 이름을 보고하는 경우라도? 저는 보지 않았습니다...);
• Windows 호스트와 동일한 호스트 이름을 요구하는 원격 시스템으로 sshing하는 것과 같이 사용하고 싶지 않은 유효한 OSC 7을 보낼 것임을 _알고_ 있는 프로필의 "OSC 7 억제"에 대한 구성 옵션.
• 값을 명령줄에 고정할 수 있는 항목에 노출하여 ssh 또는 wsl 세션이 방금 복제한 것과 동일한 작업 디렉터리에 _can_ 나타납니다.

이 논의는 첫 번째 부분(현재 CWD 가져오기)에 중점을 두었지만 위의 기존 의견을 기반으로 두 번째 부분이 더 많은 고려가 필요한 부분이라고 생각합니다. 그 아이디어 목록에 대해서도 _모든 사람_에 대해 합리적인 반대가 존재한다고 확신합니다.

여전히 이 주제에 관심이 있는 사람들을 위해 #7668에서 초기 PR을 했습니다. 이것은 친절한 핑입니다. 나는 그것에 대해 모든 사람의 의견을 듣고 싶습니다.

현재 디렉토리를 상속하지 않는 경우 여러 탭, 특히 빠른 복제의 요점은 무엇입니까? 이것은 너무나 중요한 기능입니다. 지금은 "해키" 해결 방법을 추가하지 않으시겠습니까? Windows 자체에 20년 이상 동안 이러한 솔루션이 여러 개 포함되어 있다는 점을 고려할 때 모든 사용자의 생산성을 높이는 경우 Windows의 프로세스에서 CWD를 추출하는 데 문제가 없다고 생각합니다.

왜 이 기능이 기본값이 아닌지 이해할 수 없습니다. 나는 진정에도이 기능을 활성화 할 boggled하고있다. 이것은 내가 터미널에서 가지고 있는 가장 큰 사용자 경험을 비방하는 요소입니다. 편의상 터미널 을 사용하지 않고 대신 탐색기를 사용하고 셸을 열고 싶은 디렉토리를 마우스 오른쪽 버튼으로 클릭하고 "여기서 PowerShell 창 열기"를 선택하는 것이 더 좋습니다. alt+shift+d 누른 다음 올바른 위치로 cd 를 누르는 것보다 빠릅니다.

터미널은 Windows 개발자에게 많은 삶의 질을 추가합니다. 이 기능은 저에게 큰 도약이 될 것입니다(다른 사람들도 의심합니다). 이 기능을 최우선으로 옹호하기 위해 제 목소리를 추가하겠습니다.

왜 이 기능이 기본값이 아닌지 이해할 수 없습니다.

왜 사람들이 이 스레드, #7668, #8214, #8166 및 연결된 다른 스레드에서 수행된 모든 조사를 읽고 이것이 실제로 어려운 문제인지 이해하지 못하는 이유를 이해할 수 없습니다. 해결하다. 터미널은 Windows 또는 WSL 또는 cygwin 경로인지 _필수적으로_ 알지 못하기 때문에 클라이언트 앱에서 경로를 내보내도록 할 수 없습니다.

다른 앱에 대한 이전 버전과의 호환성을 손상시키지 않으면서 이 기능에 대한 지원을 구현하는 올바른 방법을 찾기 위해 열심히 노력하는 재능 있는 기여자가 많이 있다는 것은 좋은 일입니다. 우리는 _이번 주에_ 만족스러운 솔루션을 찾았습니다. 머지 않아 구현될 것입니다.

@zadjii-msft 감사합니다!

내 댓글을 다시 읽으면서 그것이 매우 비난적이며 내 의도가 아니었다는 것을 깨닫고 있습니다. 나는 이 말을 하기 위해 여기에 왔습니다.

터미널은 Windows 개발자에게 많은 삶의 질을 추가합니다. 이 기능은 저에게 큰 도약이 될 것입니다(다른 사람들도 의심합니다). 이 기능을 최우선으로 옹호하기 위해 제 목소리를 추가하겠습니다.

그리고 지금까지 내 사용자 경험은 다음과 같습니다.

왜 이 기능이 기본값이 아닌지 이해할 수 없습니다. 이 기능을 활성화할 수 있는 방법조차 없는 이유가 정말 궁금합니다. 이것은 가장 큰 사용자 경험입니다...etc

첫 번째 단락의 시작 부분에 "사용자로"를 입력해야 합니다.

내가 한 모든 모욕에 대해 사과드립니다.