Es gibt eine "Standard"-Escape-Sequenz (OSC 7 ; URI ST), um die Überzeugung des Terminalemulators bezüglich des aktuellen Verzeichnisses festzulegen. Es stammt von macOS Terminal.app und wurde später von einigen anderen übernommen, darunter GNOME Terminal und meines Wissens auch Konsole.

Ein anderer möglicher Ansatz besteht darin, einige betriebssystemspezifische Hacks durchzuführen, um den inneren Zustand des untergeordneten Prozesses (oder sogar noch weiter bis zu den Nachkommen) zu untersuchen.

Eine andere Möglichkeit besteht darin, beides zu mischen, zB in das Verzeichnis zu gehen, das über OSC 7 eingestellt wurde, falls es jemals ausgegeben wurde, ansonsten in den Prozess einsteigen.

Der Vorteil des OSC 7-Ansatzes besteht darin, dass er clever ist, wann einem Kindprozess zu folgen und wann nicht. Wenn Sie zB eine andere verschachtelte Subshell starten, wird das Unterverzeichnis dieser Subshell berücksichtigt, da diese auch diese Sequenz ausgibt. Starten Sie jedoch eine App, die intern das Verzeichnis ändert (zB make), und es wird – zum Glück – nicht das interne Unterverzeichnis von make verwendet.

Der Nachteil von OSC 7 besteht darin, dass es die Zusammenarbeit der Shell oder anderer wichtiger Apps erfordert.

Ich lehne diese Funktionsanfrage ab, solange dieses Projekt Open Source ist, und habe nie etwas über OSC 7 erfahren. Das ist _sehr aufregend._

Ich bin nicht glücklich, durch den Prozessbaum zu kriechen, um die CWD des am weitesten entfernten Prozesses auszugraben, aber ich freue mich sehr, OSC 7 zu unterstützen.

Zu Ihrer Information Ich habe nach der Handhabung von OSC 7 für Alacritty gefragt, was schließlich dazu führte, dass dieses Problem in der "Terminal WG" auf gitlab erstellt wurde: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/20

Auf diesem Ticket hat sich nicht viel bewegt, aber es könnte Sie interessieren, es zu verfolgen. Vor allem, wenn Sie eine Meinung dazu haben, wie eine "formale" Spezifikation für OSC 7 aussehen könnte.

Also fürs Protokoll, der Thread unter https://github.com/jwilm/alacrity/pull/2937 enthält eine ziemlich gute Diskussion.

Ehrlich gesagt kann ich den bereits vorhandenen De-facto-Standard, den OSC 7 ; <URI> ST Mechanismus, ziemlich gut verwenden. Ich bin mir nicht sicher, ob es etwas Formelleres geben muss.

Warte, nein, ich hatte einen schrecklichen Gedanken. Sagen wir, bash ist so konfiguriert, dass dies ausgegeben wird, und jemand führt bash in WSL aus. Was sollen wir tun, wenn jemand versucht, das Arbeitsverzeichnis auf /home/zadjii ? Wie wir:

1. sagen, dass dies ein WSL-Pfad ist, kein Windows-Pfad
2. Weißt du, von welcher WSL-Distribution das kam?

Müssen wir auf unserer Seite eine Eigenschaft hinzufügen, die anzeigt, dass "Dies ist eine WSL-Distribution, keine Windows-Exe"? Was passiert mit Benutzern, die das nicht einstellen, funktioniert die Funktion zum Duplizieren von Registerkarten einfach nicht (effektiv im Hintergrund)?

Dann wird der nächste Teil schwieriger. Was passiert, wenn dieser Befehl über SSH ausgegeben wird? Das Terminal kann nicht wissen, dass sich der Pfad nicht mehr auf diesem Computer befindet, oder? Wie geht Terminal.app damit um?

Vielleicht braucht das mehr Spezifikation 😨

(Aus: Wie lange wird es dauern, bis ich euch beide verwechsele, D Howett und D Hewitt? :))

Dies ist eine entscheidende fehlende Funktion.

Dies sollte eine Konfigurationsoption für die verschiedenen Befehle sein. Ich möchte das zum Beispiel für duplicateTab und splitPane , aber nicht für newTab .

die Escape-Sequenz ist in den Einstellungen von mac os terminal.app dokumentiert, wie in diesem Kommentar gezeigt

Unter macOS werden die Escape-Sequenzen tatsächlich in Terminal.app > Preferences... > Profiles > Tab . angegeben

Um es festzuhalten, gibt es in https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7 eine hitzige Debatte über die Spezifikation genau dieser Funktion. Ich bezweifle, dass wir eine Teilmenge dieser Funktion unterstützen werden, bis es einen tatsächlich akzeptierten Vorschlag gibt - wir würden lieber keine weitere unterschiedliche Implementierung einführen, bis es einen tatsächlichen Standard gibt.

Ich würde dir das Gegenteil empfehlen :)

Nicht wenige Terminals haben OSC 7 erfolgreich implementiert, indem sie voneinander kopieren, was zu zufriedenen Benutzern führt.

Und es gibt derzeit jemanden, der denkt, dass es nicht gut genug ist, er denkt, dass eine formale Spezifikation erforderlich ist; einen Entwurf vorlegt, der voller Probleme ist, und was ich überhaupt nicht verstehen kann, ist nur bereit, eines von zwei Geschwistern zu dokumentieren. (Hinweis: Ich habe vor ein paar Tagen aufgehört, diesem Thread zu folgen.)

Die Terminal-WG ist keine formelle Behörde, ihre Dokumente sind nicht "offiziell", sind keine "Standards" in irgendeiner Form. Es gibt nicht einmal die richtigen Verfahren, Leute mit Verantwortungen, Stimmrechten, was auch immer; Niemand weiß, was es braucht, um dort ein Dokument "angenommen" zu bekommen, was auch immer dieser Status überhaupt bedeutet. Es ist nur eine Ansammlung zufälliger unorganisierter Leute, die versuchen, etwas Nützliches zu finden. Lassen Sie sich nicht von diesen inoffiziellen anhängigen Debatten davon abhalten, eine lang bewährte Funktion zu implementieren.

Um es festzuhalten, es gibt eine hitzige Debatte in https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7

Ich habe es auch zu dem Problem kommentiert, auf das in diesem PR verwiesen wird 😉

Für jeden, der Bash (von Git für Windows) verwendet, besteht eine vorübergehende Problemumgehung, die mich gerettet hat, darin, den neuen Pfad jedes Mal zu speichern, wenn Sie das Verzeichnis ändern (Aliasing des Befehls cd ), und dann dort cd, wenn eine neue Shell ist gestartet; das ist in meinem _.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
}

Ich teste tatsächlich, ob ich in System32 starte (meinem Terminal-Standardstartort), damit ich immer noch wt in die Explorer-Adressleiste eingeben und woanders anfangen kann, aber dieses Bit ist optional und sollte angepasst werden, wenn Ihre Shell startet in einem anderen Ordner.

Ich bin nicht fließend genug mit der PowerShell oder anderen Shells, aber ich denke, Sie können etwas Ähnliches tun.

Strg+T sollte einen neuen Tab mit derselben Shell und demselben Verzeichnis öffnen.

Nicht jeder stimmt dieser Behauptung zu.

Nicht jeder stimmt dieser Behauptung zu.

Vielleicht sind sich viele einig. So funktioniert die Terminal-App auf den meisten Linux-Desktops.

Zumindest kann es optional gemacht werden.

Hallo, ich glaube, in diesem Thread ist bereits klar, dass viele sich einig sind, dass dies eine nützliche Funktion ist, und das Windows Terminal-Team ist sich dessen ebenfalls bewusst. Und es ist auch klar, dass das Problem hier nicht darin besteht, dass sie dies nicht konfigurierbar machen möchten, sondern zuerst einige technische Dinge herausfinden müssen, die die Möglichkeit der Funktion verhindern.

Ich folge diesem Thread, um über dieses Feature und die damit verbundenen Diskussionen auf dem Laufenden zu bleiben, aber solche Nachrichten überladen nur die Benutzeroberfläche und helfen nicht weiter. Ich möchte die Leute bitten, keine Nachrichten zu posten, die nichts anderes tun, als bereits bekannte Punkte zu wiederholen.

Zumindest als Option machbar

Das ist es, was ich an der Sturheit nicht verstehe. Wenn Sie gegen das Verhalten der meisten Terminals vorgehen möchten, cool. Aber nicht einmal eine Option geben? Wo ist da die Logik? Selbst Strg+Shit+D, das das Duplizieren eines Tabs darstellt, dupliziert es nicht wirklich, da es Sie im Standardverzeichnis festhält. Als hätten Sie ein Duplikat-Feature, das nicht einmal dupliziert.

Was ist der "technische Kram", der verhindert, dass diese Funktion möglich ist? Der Code existiert bereits. Es gibt bereits eine doppelte Registerkarte in Strg+Umschalt+D. Es muss nur mit dem aktuellen Arbeitsverzeichnis gefüttert werden und Sie haben das Verhalten, an das die meisten Leute gewöhnt sind und das die Leute anfordern. Ich bin also verwirrt, wie "technische Dinge" es blockieren.

Ich schätze diese Art der Diskussion, weil es ganz klar ist, dass es Sturheit gibt und diese Art von Diskussion notwendig ist.

Ah, du hast recht, die ursprüngliche Diskussion ist verloren, weil sie nie mit diesem Thread verlinkt wurde. Ich kopiere den Inhalt eines anderen Beitrags (https://github.com/microsoft/terminal/issues/2427#issuecomment-521307534) hier als Referenz:

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

Einfach einstimmen;

_ (Profil, Arbeitsverzeichnis, Umgebungsvariable usw.)._

Alles über den _tatsächlichen Prozess_ am anderen Ende ist im Allgemeinen unmöglich zu replizieren. Der verbundene Prozess könnte ssh.exe , dessen Umgebungsvariablen und Arbeitsverzeichnis keinen Einfluss auf die erkennbare Umgebung und das Arbeitsverzeichnis von der Terminalseite haben. Seltsamerweise gilt das gleiche auch für die WSL. Es verwendet kein "Arbeitsverzeichnis" und stellt seine Umgebungsvariablen in keiner Weise interessierten Windows-Prozessen zur Verfügung.

Powershell _set_ nicht einmal das aktuelle Arbeitsverzeichnis, daher kann sein Verzeichnis auch nicht erkannt (!) werden.

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

Dies ist eines der Dinge, die im allgemeinen Fall unmöglich, aber _technisch möglich_ sind. Hier gibt es viele Feinheiten, wie zum Beispiel:

powershell
cd d:\users

Nun, Powershell ist nicht der erste Prozess, den wir gestartet haben. wir ignorieren den Pfad d:\users

(in powershell)
cd d:\users

wir würden d:\users ignorieren, weil Powershell _das aktuelle Arbeitsverzeichnis nicht wirklich festlegt_ (!!)

Wenn Ihre "Shell" ssh [email protected] (wobei wir die Shell streng als "der erste Prozess definieren, der in Ihrem Namen spawnt"), wird sein Arbeitsverzeichnis immer C:\windows\system32 unabhängig davon, was die Remote-Arbeitsverzeichnis ist.

Ich würde die Funktion lieber nicht bereitstellen, als die Funktion mit so vielen Einschränkungen zu versehen, dass sie eine Dokumentationsseite füllen würden. ☹️ Entschuldigung.

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

Nein, denn das wäre im Allgemeinen wahrscheinlich so gut wie unmöglich. Wie würden wir beispielsweise eine Instanz von vim duplizieren? Was ist, wenn der Vordergrundprozess eine Art Datei für den exklusiven Zugriff geöffnet hat - wie könnten wir diesen Prozess duplizieren?

Wenn es eine Möglichkeit gibt, dies sicher zu tun, und im Allgemeinen bin ich ganz Ohr für vorgeschlagene technische Lösungen, aber ich glaube nicht, dass dies möglich ist, also werde ich es nicht untersuchen.

Auch wenn Powershell das Arbeitsverzeichnis _did_ gesetzt hat, sind wir uns immer noch nicht sicher, dass es _technisch_ unter Windows möglich ist, den CWD eines anderen Prozesses abzurufen. Das ist also das "technische" Zeug, das verhindert, dass dies funktioniert. Ich würde dies gerne als Einstellung hinzufügen. Aber es gibt definitiv noch technische Fragen, die beantwortet werden müssen.

Die Lösung, die in diesem Thread diskutiert wird, beinhaltet das Hinzufügen von Unterstützung für eine andere VT-Sequenz zum Terminal, die die _shell_ ausgeben könnte, um dem Terminal mitzuteilen, in welchem ​​​​Pfad es sich befindet. Diese VT-Sequenz ist nicht sehr gut definiert und hat Randfälle, die noch gelöst werden müssen. Nämlich:

• Was passiert, wenn eine WSL-Shell sagt "mein CWD ist /home/foo ? Das Terminal kann nicht wissen, dass der Pfad ein WSL-Pfad ist oder zu welcher Distribution er gehört, also würde das Duplizieren dieser Registerkarte wahrscheinlich in enden C:\home\foo (falls vorhanden)
• Was passiert, wenn Sie über SSH mit einem anderen Computer verbunden sind? Das Terminal kann diese Pfade nicht von Pfaden auf Ihrem eigenen lokalen Computer unterscheiden, daher wäre das Duplizieren dieses Pfads das falsche Verhalten
• Jeder Benutzer muss seine Eingabeaufforderung für verschiedene Shells _manuell_ anpassen, um mit diesem Verhalten zu kooperieren. Dies ist kein Blocker, aber das bedeutet, dass es sich um eine Einstellung handelt, die nicht sofort funktioniert.

Sie versuchen, die laufenden Prozesse zu duplizieren? Schauen wir uns zum Beispiel Linux an. Wenn Sie SSH in Ihrem Terminal ausführen und eine neue Registerkarte öffnen, öffnet die neue Registerkarte keine SSH-Verbindung und navigieren Sie zu Ihrer Position in der SSH-Verbindung. Es öffnet eine neue Registerkarte, wo Sie sich auf Ihrem Computer befinden. Selbst wenn der Prozess lokal und nicht SSH war, wird der Prozess nicht ausgeführt. Dupliziert wird nur die Registerkarte, nicht die laufenden Prozesse.

Das hört sich so an, als wäre das zu kompliziert. Sie duplizieren weder VIM noch SSH oder andere laufende Anwendungen. Sie duplizieren das Terminal und das beantwortet die Randfälle:

• Für WSL surfen Sie nicht in Ihrem lokalen Netzwerk. Wenn die Rückgabe /home/foo ist, ist dies der Ort. Wenn der Speicherort C:\home\foo wäre, würde /mnt/c/home/foo zurückgegeben.
• SSH ist ein Prozess. Es läuft in der Shell. Sie duplizieren keine Prozesse. Andere Terminals nicht. Sie duplizieren die Registerkarte.
• Ich bin mir nicht sicher, was der Benutzer anpassen müsste, aber seit wann ist die Anpassung ein Problem?

Es ist nichts falsch daran, die Prozesse zu duplizieren. Ich bin sicher, das würde einigen gefallen. Es wäre nur eine weitere Option zusätzlich zu der Option zum Duplizieren der Registerkarten. Es sollte keine Straßensperre sein. Das ist extra und optional.

@PandaClone es könnte Sie überraschen zu erfahren, dass _einige Leute ssh.exe als erstes festlegen, was ein Profil startet, ohne es von einer Shell aus auszuführen_.

Wie auch immer, es gibt wirklich keine Möglichkeit für das Terminal, wsl.exe , die Wrapper-Anwendung, die mit Linux-Prozessen kommuniziert, abzufragen, um es zu sagen, was das aktuelle Arbeitsverzeichnis des ersten Prozesses in seinem Prozess ist Baum.
Da es nicht die Windows-Arbeitsverzeichnisinfrastruktur verwendet, die das WD im Prozessumgebungsblock speichert, reicht es nicht aus, nur die langweiligen alten Windows-APIs zu verwenden, um zu sagen, was sein Arbeitsverzeichnis ist._

Das sind technische Probleme, die wir lösen müssen. Ansonsten schreiben wir ein Feature, das nur für etwa 25 % der Leute funktioniert.

Wenn es sich als einfach erweist: Wir sind immer bereit, Community-Beiträge anzunehmen.

• Für WSL surfen Sie nicht in Ihrem lokalen Netzwerk. Wenn die Rückgabe /home/foo ist, ist dies der Ort. Wenn der Speicherort C:\home\foo wäre, würde /mnt/c/home/foo zurückgegeben.

Ah, aber sehen Sie, so wie diese Funktion wie angegeben funktioniert, weiß das Terminal nicht, wer oder was gesagt hat "Das aktuelle Arbeitsverzeichnis ist /home/foo ". Dies könnte cmd.exe - dann ja, der Benutzer möchte C:\home\foo . Dies könnte ihre Ubuntu-Distribution oder ihre Fedora-Distribution sein, oder dies könnte eine SSH-Verbindung mit Centos oder einer anderen Möglichkeit sein. Alles, was das Terminal erhält, ist eine Zeichenfolge mit der Aufschrift "Dies ist jetzt das Arbeitsverzeichnis".

• Ich bin mir nicht sicher, was der Benutzer anpassen müsste, aber seit wann ist die Anpassung ein Problem?

So ziemlich jede Shell, die der Benutzer ausführt, muss manuell konfiguriert werden, um das Senden dieser Sequenz zu ermöglichen. Benutzer von cmd müssen ihre %PROMPT% manuell konfigurieren, um die Sequenz $e]7;$P$e einzuschließen. bash Benutzer müssen es in ihrem PS1 einrichten. PowerShell wird sicherlich eine andere Möglichkeit haben, dies zu tun. Das grundlegende Problem hierbei ist jedoch, dass die Shells diese Sequenz standardmäßig _nicht_ ausgeben.

SSH ist keine Shell. Sie können Ihr Profil so einstellen, dass es zuerst ausgeführt wird, aber es wird immer noch von der Shell ausgeführt. Es ist nur Ihr Profil angewiesen, eine Anwendung sofort auszuführen. Diese Anwendung kann alles sein. Es muss nicht SSH. Sie können Ihr Profil anweisen, eine andere Shell auszuführen, wenn Sie möchten.

Und selbst wenn kein Terminal vorhanden ist, wie ist das ein Problem? Ausnahmen gibt es immer. Die Standardeinstellung auf das Home-Verzeichnis, wenn kein Verzeichnis vorhanden ist, ist in Ordnung. Das ist kein Problem, wenn Sie einfach "oh, das geht nicht" machen.

Dies ist auch eine Funktion, die in den meisten Terminals mit Registerkarten standardmäßig vorhanden ist. Führen Sie eine beliebige Linux-Distribution aus, die ihre eigenen Terminal-Varianten hat, und alle zeigen dieses Verhalten beim Öffnen einer neuen Registerkarte. Dies ist keine Funktion, die für Windows Terminal bahnbrechende Magie sein wird. Es ist eine Standardfunktion.

Terminal spawnt nicht nur Muscheln. Es ruft buchstäblich CreateProcess für das Ding auf, das Sie in der Profilkonfiguration angeben. SSH wird nicht in einer Shell ausgeführt oder von dieser erzeugt.

Sehen Sie, wir streiten darüber, wie möglich diese Funktion ist. Können wir uns einfach darauf einigen, dass _wir das wollen, jeder will es, und wenn wir einen vernünftigen Weg nach vorne hätten, der in den meisten Anwendungsfällen funktioniert, die den Benutzern wichtig sind_, dass wir es bereits getan hätten? Ich versuche, die Häufigkeit, mit der wir sagen müssen, „das geht nicht“, mit ein wenig Planungs- und Designarbeit im Voraus zu reduzieren.

Es ist keine bahnbrechende Magie, es wird nur durch das Windows- und WSL-Prozessmodell kompliziert und wir glauben, dass es unter bestimmten Umständen umfallen wird. Niemand sagt mehr als das.

• Für WSL surfen Sie nicht in Ihrem lokalen Netzwerk. Wenn die Rückgabe /home/foo ist, ist dies der Ort. Wenn der Speicherort C:\home\foo wäre, würde /mnt/c/home/foo zurückgegeben.

Ah, aber sehen Sie, so wie diese Funktion wie angegeben funktioniert, weiß das Terminal nicht, wer oder was gesagt hat "Das aktuelle Arbeitsverzeichnis ist /home/foo ". Dies könnte cmd.exe - dann ja, der Benutzer möchte C:\home\foo . Dies könnte ihre Ubuntu-Distribution oder ihre Fedora-Distribution sein, oder dies könnte eine SSH-Verbindung mit Centos oder einer anderen Möglichkeit sein. Alles, was das Terminal erhält, ist eine Zeichenfolge mit der Aufschrift "Dies ist jetzt das Arbeitsverzeichnis".

Woher weiß es nicht, wer oder was das aktuelle Arbeitsverzeichnis ist? Du bist derjenige, der danach fragt. Sie wissen, ob es sich um eine Eingabeaufforderung oder eine WSL oder eine PowerShell handelt. Sie wissen, woher es kommt, damit Sie wissen, wie Sie den Speicherort formatieren.

• Ich bin mir nicht sicher, was der Benutzer anpassen müsste, aber seit wann ist die Anpassung ein Problem?

So ziemlich jede Shell, die der Benutzer ausführt, muss manuell konfiguriert werden, um das Senden dieser Sequenz zu ermöglichen. Benutzer von cmd müssen ihre %PROMPT% manuell konfigurieren, um die Sequenz $e]7;$P$e einzuschließen. bash Benutzer müssen es in ihrem PS1 einrichten. PowerShell wird sicherlich eine andere Möglichkeit haben, dies zu tun. Das grundlegende Problem hierbei ist jedoch, dass die Shells diese Sequenz standardmäßig _nicht_ ausgeben.

Wie ist das ein Problem? Dies wäre nicht die erste Anwendung, die eine Konfiguration erfordert, und es wird nicht die letzte sein. Nicht alles ist Plug and Play und das ist verständlich. Wenn dies nur dann funktioniert, wenn der Benutzer eine Konfiguration benötigt, wie sieht dieser Endpunkt aus?

Was passiert, wenn eine WSL-Shell sagt "mein CWD ist /home/foo? Es gibt keine Möglichkeit für das Terminal, zu wissen, dass der Pfad ein WSL-Pfad ist oder zu welcher Distribution er gehört, also würde das Duplizieren dieser Registerkarte wahrscheinlich in C enden: \home\foo (falls vorhanden)

Ich kann nur für mich selbst sprechen, aber wenn ich einen Tab mit einem Profil geöffnet hätte, irgendwohin navigiere und dann einen neuen Tab in einem anderen Profil öffne, würde es mich nicht im Geringsten überraschen oder enttäuschen, wenn das Arbeitsverzeichnis dies nicht täte übertragen, und stattdessen wurde die Standardeinstellung verwendet.

Ich denke, Sie verstehen, dass die meisten Leute, die nach dieser Funktion fragen, das Verhalten in Terminals wie denen, die in GNOME und macOS enthalten sind, vermissen. Diese Terminals müssen nicht mit der gleichen Komplexität zurechtkommen, aber ich glaube nicht, dass von Ihnen erwartet wird, dass Sie versuchen, mit Randfällen intelligent umzugehen, die in der Software, die sie sind, einfach nicht vorhanden sind als Bezugspunkt verwenden.

Es klingt nach einer ziemlich haarigen Aufgabe, auch wenn Sie den Umfang etwas reduzieren. Ich hoffe, es kann eine Möglichkeit gefunden werden, einige Versionen dieser Funktion einzubinden, da dies eine schöne Zeitersparnis ist.

Könnte dieser Anwendungsfall kurzfristig von #4472 gehandhabt werden? Ich persönlich wäre mit einer Variante von cmd.exe /c "wt.exe" new-tab -p "Ubuntu-20.04" -d $(pwd) zufrieden (wahrscheinlich an ein Bash-Makro gebunden), die eine neue Registerkarte im zuletzt fokussierten Fenster öffnen würde (das ist mit ziemlicher Sicherheit das Fenster, in das ich den Befehl eingegeben habe ).

Ich werde auf den Punkt gehen und sagen, dass die Implementierung der Erkennung für das aktuelle Verzeichnis des Root-Prozesses einfacher ist als die Implementierung von Kommandozeilen-Remoting und IPC, um WT dazu zu bringen, Registerkarten im selben Fenster zu öffnen :smile:

wow, ich bin gerade hierher gekommen und habe festgestellt, dass es eine lange Reise zu brauchen scheint :)

Wir haben festgestellt, dass wir im Windows-Terminal die Shell-Fenster durch Drücken der Tastenkombination Alt + Umschalt + D teilen können, aber es wird nicht auf dasselbe Verzeichnis eingestellt

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

Ich habe eine Problemumgehung: Ändern Sie das Startverzeichnis.

Setzen Sie diese Funktion in $PROFILE (stellen Sie sicher, dass Sie $path anpassen)

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
}

.. und Sie können fast problemlos einen neuen Tab im selben Verzeichnis öffnen. Geben Sie einfach sd bevor Sie einen neuen Tab öffnen.

Der Nachteil ist natürlich, dass startingDirectory bei jedem Aufruf der Funktion geändert wird.

Es wäre am besten, diesen Ansatz mit einem Key-Re-Mapper zu verwenden, so dass beim Drücken von Ctrl+T die Funktion automatisch aufgerufen wird und wenn Ctrl+F4 gedrückt wird, wird startingDirectory zurückgesetzt wieder auf den ursprünglichen Wert zurück.

Alternative Lösung

Erstellen Sie in jedem Profil, das Sie verwenden, beispielsweise profile.sh oder .zshrc , eine Datei ~/paths.sh, die sich in Ihrem $HOME-Verzeichnis befindet. Pfade werden aktualisiert, wenn Sie setCWD aufrufen

Diese Lösung überschreibt das StartingDirectory vollständig. Wenn Sie ein neues Terminal spawnen, rufen Sie setCWD auf, bevor Sie das Terminal spawnen, und es wird immer in der Stelle gestartet, in der Sie setCWD zuletzt aufgerufen

Beachten Sie, dass ich dies innerhalb von .zshrc getan habe

Code:

source ~/paths.sh

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

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

Möglicherweise müssen Sie eine Anfangsdatei erstellen, rufen Sie also einfach

Übrigens, wenn Sie Autohotkey verwenden, ist hier ein nettes und schnelles Skript, damit die Dinge funktionieren

Erstellen Sie eine Datei namens windows-terminal.ahk und fügen Sie diesen Code unten ein. Führen Sie die Datei aus und Sie sind fertig. (Ich empfehle, diese Datei in den Startbereich zu verschieben, damit diese Funktion beim Neustart erneut angewendet wird.

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

Leute, das ist sehr wichtig für die Produktivität, fast wie über allem anderen. Bitte beheben Sie dies, ich und meine Freunde werden alle anderen minderwertigen Terminalemulatoren gerne aufgeben.

Es sieht so aus, als ob der Versuch, OSC 7 bei terminal-wg zu "standardisieren", ins Stocken geraten ist .

Besteht noch Interesse, OSC 7 grundsätzlich so zu implementieren, wie es in Terminal.app ist ?

Angesichts dessen hätten wir "aktueller Host und CWD" für ein bestimmtes Terminal, was die Diskussion über "Prozess-Hacking" nur übertönt; und kann dann das Benutzerverhalten entscheiden/implementieren, um diese Informationen zu verwenden, z. B.:

• einen Befehl "neuer Tab im aktuellen Verzeichnis";
• machen "split" dies standardmäßig;
• etwas Magisches, um eine WSL-Sitzung von einer Windows-Sitzung zu unterscheiden (wenn sie überhaupt denselben Hostnamen melden? Ich habe nicht nachgesehen ...);
• eine Konfigurationsoption für "OSC 7 unterdrücken" in Profilen, bei denen Sie _wissen_, dass es ein gültig aussehendes OSC 7 senden wird, das Sie nicht verwenden möchten, z.
• indem Sie den Wert in etwas freigeben, das Sie in die Befehlszeile einfügen können, sodass Ihre ssh- oder wsl-Sitzung _kann_ im selben Arbeitsverzeichnis erscheinen kann wie die gerade duplizierte.

Diese Diskussion konzentrierte sich sehr auf den ersten Teil (das aktuelle CWD erhalten), aber ich vermute, dass der zweite Teil aufgrund der bisherigen Kommentare weiter oben berücksichtigt werden muss. Selbst für diese Liste von Ideen gibt es sicher einen vernünftigen Einwand gegen _jeden_ von ihnen.

Für diejenigen, die sich noch für dieses Thema interessieren, habe ich in #7668 eine frühe PR gemacht. Dies ist ein freundlicher Ping. Ich würde wirklich gerne von allen davon hören.

Was nützen mehrere Registerkarten, insbesondere schnelle Duplizierung, wenn sie nicht das aktuelle Verzeichnis erben? Dies ist eine so wichtige Funktion. Warum nicht erst einmal einen "hackigen" Workaround hinzufügen? Ich sehe wirklich kein Problem darin, CWD aus einem Prozess unter Windows zu extrahieren, wenn es die Produktivität für alle Benutzer erhöht, wenn man bedenkt, dass Windows selbst seit mehr als 20 Jahren mehrere solcher Lösungen enthält.

Ich kann nicht verstehen, warum diese Funktion nicht die Standardeinstellung ist. Ich bin wirklich verwirrt , warum es nicht einmal eine Möglichkeit gibt , diese Funktion zu aktivieren. Dies ist der größte Nachteil für die Benutzererfahrung, den ich mit Terminal habe: Aus Zweckmäßigkeitsgesichtspunkten bin ich besser bedient, wenn ich kein Terminal verwende und stattdessen den Explorer verwende und mit der rechten Maustaste in das Verzeichnis klicke, in dem ich die Shell öffnen möchte, und "PowerShell-Fenster hier öffnen" auswählen, weil es schneller als alt+shift+d schlagen und dann cd an die richtige Stelle zu müssen.

Terminal fügt Windows-Entwicklern viel Lebensqualität hinzu. Diese Funktion wäre für mich ein großer Sprung nach vorne (und ich vermute andere). Ich werde mich dafür einsetzen, dass diese Funktion oberste Priorität hat.

Ich kann nicht verstehen, warum diese Funktion nicht die Standardeinstellung ist.

Ich kann nicht verstehen, warum sich die Leute nicht die Mühe machen, alle Untersuchungen in diesem Thread in #7668, #8214, #8166 und den anderen verlinkten Threads zu lesen, um zu verstehen, warum dies tatsächlich ein schwieriges Problem ist lösen. Es stellt sich heraus, dass Sie nicht einfach eine Client-App ihren Pfad ausgeben lassen können - weil das Terminal _unbedingt_ nicht weiß, ob es sich um einen Windows-, einen WSL- oder einen Cygwin-Pfad handelt.

Es ist gut, dass wir eine Menge talentierter Mitwirkender haben, die hart daran arbeiten, den richtigen Weg zu finden, um die Unterstützung für diese Funktion zu implementieren, ohne die Abwärtskompatibilität für andere Apps zu beeinträchtigen. Wir haben _erst diese Woche_ eine Lösung gefunden, mit der wir zufrieden sind, es sollte nicht lange dauern, bis sie implementiert ist.

Danke @zadjii-msft !

Beim erneuten Lesen meines Kommentars stelle ich fest, dass er sehr anklagend rüberkommt und das nicht meine Absicht war. Ich bin hierher gekommen, um dies zu sagen:

Terminal fügt Windows-Entwicklern viel Lebensqualität hinzu. Diese Funktion wäre für mich ein großer Sprung nach vorne (und ich vermute andere). Ich werde mich dafür einsetzen, dass diese Funktion oberste Priorität hat.

Und dass meine bisherige Benutzererfahrung so war:

Ich kann nicht verstehen, warum diese Funktion nicht die Standardeinstellung ist. Ich bin wirklich verwirrt, warum es nicht einmal eine Möglichkeit gibt, diese Funktion zu aktivieren. Dies ist die größte Benutzererfahrung ... etc.

Ich hätte wahrscheinlich "als Benutzer" am Anfang meines ersten Absatzes schreiben sollen.

Ich entschuldige mich für jede Beleidigung, die ich gegeben habe.