Die aktuelle Alternative zwingt Benutzer, Pfade zu normalisieren

PowerShell erledigt die Arbeit bereits für Sie, und Sie müssen keine Pfade normalisieren.
PowerShell ist hier sehr benutzerfreundlich – Benutzer können Schrägstriche verwenden, die sie unabhängig von der Plattform verwenden.
Es hat sich bewährt, die Verwendung wörtlicher Pfade zu vermeiden und Pfad-Cmdlets zu verwenden.

Es hat sich bewährt, die Verwendung wörtlicher Pfade zu vermeiden und Pfad-Cmdlets zu verwenden.

@iSazonov Ja und nein.

Sicher, wenn Sie Pfadsegmente kombinieren, können Sie Pfad-Cmdlets verwenden. Aber wenn Sie ein Skript schreiben, das auf einen relativen Pfad mit mehreren Segmenten verweist, und wenn Sie beabsichtigen, dass Ihr Skript plattformübergreifend funktioniert, werden Sie das nicht tun.

In PowerShell 7 Preview 3 unter Windows vervollständigt die Tabulatorvervollständigung Pfade mit einem umgekehrten Schrägstrich. Das ist der einzige Punkt, an dem wir meiner Meinung nach etwas falsch machen, jetzt, wo PowerShell plattformübergreifend ist. Es sollte zumindest eine Option geben, um das Verzeichnistrennzeichen auszuwählen, das Sie unter Windows als Teil der Tab-Vervollständigung verwenden möchten: entweder [System.IO.Path]::DirectorySeparatorChar oder [System.IO.Path]::AltDirectorySeparatorChar . In Anbetracht dessen, wo wir heute stehen, vermute ich, dass die meisten Leute, die plattformübergreifend arbeiten, möchten, dass die Tab-Vervollständigung von Pfaden unter Windows standardmäßig AltDirectorySeparatorChar verwendet, aber soweit ich weiß, gibt es keine Möglichkeit, dies zu tun .

@chriskuech : Abgesehen von der Tab-Vervollständigung von Pfaden, gibt es andere Stellen, an denen Sie das Gefühl haben, dass AltDirectorySeparatorChar nicht verwendet wird, wo Sie gerne eine Option hätten, damit es anstelle von DirectorySeparatorChar verwendet werden kann? Ich kann mir keine vorstellen.

@KirkMunro , sagen Sie, dass es heute eine (zumindest teilweise implementierte) Möglichkeit gibt, Pfade in PowerShell zu normalisieren? Wenn ja, funktioniert es auf der neuesten Version 6.x? Die Anwendungsfälle, mit denen ich ein Problem hatte, waren automatische Variablen und *-Path -Befehle.

@iSazonov , die vorgeschlagene Lösung hätte für mein Szenario nicht funktioniert, da ich eine Liste von Pfaden unter Windows generiert habe, eine Liste von Pfaden unter Linux generiert und dann versucht habe, sie zu vergleichen, was aufgrund der Trennzeichen fehlgeschlagen ist.

Den automatischen Variablen fehlt durchgehend ein abschließendes Verzeichnistrennzeichen, sodass PowerShell das Erstellen von Pfaden mit Literalen wunderbar ermöglicht. Ex:

$RepoRoot = "$PSScriptRoot/../.."
$SourceRoot = "$RepoRoot/src"
$BuildRoot = "$RepoRoot/.build"

Ich denke, das ist viel klarer als

$RepoRoot = Join-Path $PSScriptRoot "../.."
$SourceRoot = Join-Path $RepoRoot "src"
$BuildRoot = Join-Path $RepoRoot ".build"

Ich hoffe also, dass es in Zukunft funktionieren kann, auch wenn dies nicht standardmäßig der Fall ist.

@chriskuech meine persönliche Angewohnheit ist ungefähr so ​​geworden:

$SourceRoot = $RepoRoot | Join-Path -ChildPath 'src'

Es ist ein wenig klarer, aber ja, es ist nicht perfekt.

Join-Path hat AdditionalChildPath , die String-Arrays akzeptieren.

@chriskuech Danke für die zusätzlichen Informationen.

Ich habe nicht vorgeschlagen, dass PowerShell die Normalisierung von Pfaden teilweise unterstützt. Ich habe nur darauf hingewiesen, dass ich persönlich nicht mag, dass die Tab-Vervollständigung unter Windows standardmäßig einen umgekehrten Schrägstrich und unter Linux oder macOS standardmäßig einen Schrägstrich verwendet.

Wenn ich eine Einstellung anpassen könnte, um dies so zu ändern, dass der Schrägstrich standardmäßig auch für Windows-Pfade verwendet wird, würde ich diese Änderung vornehmen, und dies ist eine Stelle, an der ich denke, dass es eine Möglichkeit geben könnte, die plattformübergreifende PowerShell-Arbeit einfacher zu machen. Join-Path verwendet auch [System.IO.Path]::DirectorySeparatorChar als Pfadtrennzeichen. Wenn es im Idealfall eine Einstellung zum Festlegen des gewünschten Pfadtrennzeichens beim Schreiben von Skripts gäbe (da wir in der Lage sein sollten, Skripts einfach so zu schreiben, wie wir es möchten, unabhängig von der Plattform, auf der wir sie schreiben), würde sich dies in beiden Tabs widerspiegeln Vervollständigung von Pfade und auch Join-Path .

Abgesehen von diesen persönlichen Bedürfnissen frage ich mich, ob ein Compare-Path -Cmdlet nützlich wäre. Es könnte die Pfadtrennzeichen normalisieren und sogar absolute Pfade mit relativen Pfaden vergleichen, indem relative Pfade aufgelöst werden, bevor der Vergleich durchgeführt wird, wenn einer der Pfade absolut ist.

Nun, wir erhalten eine _plattformspezifische_ Normalisierung in Convert-Path und Resolve-Path :

PS> Convert-Path C:/Windows
C:\Windows # normalized to Windows-native "\"

Als Alternative zur Einführung eines Compare-Path -Cmdlets könnten also Convert-Path und Resolve-Path so erweitert werden, dass sie einen -UseSlash -Schalter unterstützen (Name verhandelbar).

Separat und ergänzend könnte der Opt-in-Einstellungsmechanismus für die Verwendung / unter Windows, den Kirk vorschlägt, dann auch für Convert-Path und Resolve-Path gelten (zusätzlich zur Tab-Vervollständigung und Join-Path ).

Der Haken im Moment ist, dass Convert-Path und Resolve-Path nur mit _bestehenden_ Pfaden funktionieren, aber das ist etwas, das es wert ist, geändert zu werden, wie @jaykul vor langer Zeit vorgeschlagen hat - siehe #2993

Ich denke, es wäre schön, wenn die Pfadvervollständigung das Pfadtrennzeichen verwenden würde, das explizit im Vervollständigungstext erscheint, und wenn es keins gibt, dann standardmäßig das native Trennzeichen der Plattform.

Unter Windows wird also c:\w zu c:\Windows\ und c:/w zu 'c:/Windows/' vervollständigt.

Ich denke, dies würde einen Großteil der Ärgernisse abdecken, ohne dass eine Konfigurationsoption erforderlich ist, und ist eigentlich vorzuziehen, da Sie gelegentlich aus irgendeinem Grund die andere Form benötigen.

@lzybkr , ich mag die Idee, auch angesichts einer Besorgnis bezüglich einer auf Konfigurations- / Präferenzvariablen basierenden Lösung, die ich versäumt habe zu erwähnen: das Scoping-Problem; Mit dem üblichen _dynamischen_ Scoping kann Code, der feste Annahmen über Pfadtrennzeichen macht, brechen (was Anklänge an https://github.com/PowerShell/PowerShell-RFC/issues/7 hat).

@lzybkr und wann werden beide Schrägstriche verwendet? C:\Program Files/A -> ?

So viele Optionen - zufällig, jede abwechselnd, immer Schrägstrich b / c, es ist das einzig wahre Pfadtrennzeichen usw.

Im Ernst, vielleicht wählen Sie einfach den zuletzt verwendeten aus, der wahrscheinlich vom Benutzer eingegeben wird, während andere dies möglicherweise nicht tun.

@lzybkr : Es gibt jedoch einen Haken:

Wenn Sie _ohne_ ein Pfadtrennzeichen starten, um auf eine Datei/einen Ordner im _aktuellen Verzeichnis_ zu verweisen, muss PowerShell die Wahl für Sie treffen, zumindest basierend auf dem aktuellen Vervollständigungsalgorithmus, der zu .\<filename> oder ./<filename> erweitert wird .\<folder>\ oder ./<folder>/ , je nach Plattform.

Für _files_ als _arguments_ könnten wir dieses Problem umgehen, indem wir zum Beispiel fil auf nur file erweitern (kein .\ / ./ Präfix).

Jedoch:

• für _executables_ ist das automatisch hinzugefügte Präfix .\ / ./ eine wertvolle Annehmlichkeit, wenn die Absicht besteht, tatsächlich ein Skript auszuführen, das sich im aktuellen Verzeichnis befindet.

• Für _Verzeichnisse_ ist die Erweiterung auf etwas mit einem _Trailing Path Separator_ ( <folder>\ oder <folder>/ ) ebenfalls wertvoll.

In beiden Fällen gibt es keine Benutzeraktion, um das bevorzugte Trennzeichen zu implizieren.

Das heißt, vielleicht ist die Lösung: Wenn Sie das Trennzeichen steuern möchten, _starten Sie manuell mit_ ./ oder .\ und sorgen Sie dafür, dass die Tab-Vervollständigung dies berücksichtigt.

Dieses Problem wurde als beantwortet markiert und es gab seit 1 Tag keine Aktivität . Es wurde aus haushaltstechnischen Gründen geschlossen.

@iSazonov : Dies wird nicht wirklich beantwortet und sollte erneut geöffnet werden, damit die laufende Diskussion dies weiter ausarbeiten kann. Das OP hatte noch nicht einmal die Möglichkeit, auf Fragen zu antworten, die ihm gestellt wurden.

Ich glaube, ich habe alle Fragen an mich gerichtet, aber lassen Sie es mich wissen, wenn ich es nicht getan habe. Ich bin mir auch nicht sicher, warum dieses Thema geschlossen ist. Es war nicht als Diskussionsthread gedacht, sondern als Funktionsanfrage.

Das Grundproblem zur Hand:

• Sollte ein plattformübergreifendes Tool standardmäßig ein nicht plattformübergreifendes Verhalten aufweisen?
• Wenn ja, sollte es eine Möglichkeit geben, PowerShell global in einem "plattformübergreifenden" Modus auszuführen?

Ich denke, Entwickler zu zwingen, Zeichenfolgen mit Cmdlets manuell zu normalisieren, ist definitiv ein falscher Schritt. Ich sehe keine Szenarien, in denen die standardmäßige Verwendung / unter Windows zu Problemen führen würde, da PowerShell, wie bereits erwähnt, beide Arten von Schrägstrichen sehr gut handhaben kann. Wenn niemand überzeugende Situationen liefern kann, in denen dies zu Fehlern führen würde, warum nicht einfach standardmäßig / verwenden? Vielleicht muss dieses Problem in einen RFC verschoben werden.

Da immer mehr Menschen in die Cloud migrieren, entwickeln immer mehr Menschen PowerShell-Code unter Windows und führen ihn unter Linux aus. Es wird in der Zukunft sicherlich einen Punkt geben (falls noch nicht überschritten), an dem die Zahl der Benutzer, die ein echtes plattformübergreifendes Verhalten bevorzugen, alle übertrifft, die stark daran interessiert sind, \ auf Windows zu behalten.

@chriskuech : Mein Fehler, ich habe dir die Frage nicht speziell gestellt. Ich habe mich gefragt, ob Sie der Meinung sind, dass ein Conpare-Path -Cmdlet Ihnen helfen würde. Abgesehen von dieser Frage würde ich auch gerne Normalisierungsoptionen sehen.

@KirkMunro Ich bin mir nicht sicher, ob Compare-Path helfen würde, da im ursprünglichen Anwendungsfall (Vergleich der Pfade unter Linux und Windows) das Root-Dateisystem anders ist, also muss ich Resolve-Path -Relative aufrufen. An diesem Punkt ist der Vergleichsanwendungsfall nur ein Einzeiler: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

Ich zögere jedoch sehr, eine Cmdlet-basierte Lösung zu unterstützen, da sie das Grundproblem nicht löst und entweder die String-Interpolation für Pfade verbietet oder Codeänderungen an jeder Pfad-String-Definition erfordert. Insbesondere Compare-Path repariert nicht alle meine protokollierten Pfade mit gemischten Schrägstrichen.

@KirkMunro @mklement0 Das Issue ist nicht gesperrt und jeder kann Kommentare ziehen.
Wir haben viele Probleme ohne neue Kommentare und Fortschritte. Offener Status hat seine Bedeutung verloren.
Als Betreuer beabsichtige ich, anspruchsvoller zu sein, um Diskussionen zu ermutigen, strengere Spezifikationen zu werden, die sich leicht in PRs verwandeln können.
Was das Problem betrifft, wird es unendlich - die anfängliche Anfrage war "Schrägstrich unter Windows verwenden", dann "Pfade vergleichen". Was kommt als nächstes? Remoting? Es ist offen, um fortzufahren, wird aber geschlossen.
Während oben nur ein echter Vorschlag von Jason war (um die Vervollständigung zu verbessern), konnten wir ein Tracking-Problem eröffnen und es durch echte PR schließen.

Um es klar zu sagen, das Problem ist immer noch "Schrägstrich unter Windows verwenden". "Wege vergleichen" wurde nur als eines (von mehreren) motivierenden Beispielen genannt.

Vorschlag
Implementieren Sie ein echtes plattformübergreifendes Verhalten, bei dem das Pfadtrennzeichen auf allen Plattformen standardmäßig / ist, es sei denn, der Benutzer vervollständigt mit der Tabulatortaste einen Pfad, der bereits \ enthält. Ich würde erwarten, dass dies vorerst als experimentelle Funktion ausgeblendet wird, aber ich sollte zumindest in der Lage sein, in meinem Code eine Funktion zum Maximieren des plattformübergreifenden Verhaltens zu aktivieren, um die Entwicklungserfahrung von Windows-Entwicklern zu optimieren, die auf Linux abzielen.

Wenn dies unvernünftig ist, würde ich gerne wissen, warum und ob es eine Dokumentation gibt, die anleitet, wenn das PowerShell-Design plattformübergreifend abweicht.

@iSazonov : Betreuer des PS-Repos sollten Benutzerproblemen nicht ohne Diskussion gegenüber abweisend sein. Sie haben ursprünglich geantwortet, ohne sich die Zeit zu nehmen, die Bedürfnisse des OP zu verstehen, und das Problem als beantwortet markiert, aber das Problem wurde nicht als Frage gepostet, sondern als Funktionsanfrage, und wie aus der Diskussion hervorgeht, ist es eindeutig nicht beantwortet".

Offener Status hat seine Bedeutung verloren.

Wer sagt? Das stimmt absolut nicht. Ein offenes Problem ist offen, und ein geschlossenes Problem ist geschlossen. Diese beiden Unterscheidungen haben eine sehr klare Bedeutung. Geschlossene Probleme schaue ich mir nur an, wenn es meine eigenen sind und ich zurückgehen möchte, um etwas zu überprüfen. In seltenen Fällen suche ich geschlossene Themen nach Diskussionen zu einem bestimmten Thema. Aber 90 % oder mehr meiner Zeit in Issues verbringe ich mit offenen Issues, wie es sein sollte. Das einzige, was die Grenze zwischen den beiden verwischt und dazu führt, dass offene Probleme ihre Bedeutung verlieren, ist, sie kurzerhand zu schließen, bevor sie gelöst sind, wie Sie es bei diesem Problem getan haben.

(Die Diskussion) kann fortgesetzt werden, wird aber geschlossen.

Basierend auf diesem Ansatz zum Verwalten von Problemen zwingen Sie die Leute dazu, die Unterscheidung zwischen offen und geschlossen aufzuheben, sodass sie alle Probleme durchsuchen müssen, anstatt sich auf die offenen Probleme zu konzentrieren, was bedeutet, dass sie die offenen 2K-Probleme plus die geschlossenen 4K-Probleme überprüfen müssen für sie relevante Diskussionen statt sich nur auf die offenen Punkte zu konzentrieren. Das ist eine kaputte, fehlerhafte Issue-Management-Strategie.

Was das Problem betrifft, wird es unendlich - die anfängliche Anfrage war "Schrägstrich unter Windows verwenden", dann "Pfade vergleichen". Was kommt als nächstes? Remoting?

Das ist lächerlich. Die Diskussion konzentriert sich auf den Umgang mit Windows, das standardmäßig einen umgekehrten Schrägstrich hat, wenn Sie plattformübergreifende Skripts schreiben. Es blieb bei diesem Thema. Sie versuchen, es so klingen zu lassen, als wäre es überhaupt nicht fokussiert.

@iSazonov , ich stimme zu, dass es zu viele offene Fragen gibt; Die Tatsache, dass es zu viele offene Fragen gibt, bedeutet jedoch nicht, dass wir abweisend sein und das Gespräch über neue Fragen vorzeitig beenden sollten. Wir müssen weiterhin Feedback fördern und offen für Diskussionen über PowerShell in offenen Problemen sein und sie erst schließen, wenn sie wirklich gelöst sind. Mit der Menge an offenen Fragen muss anders umgegangen werden.

Loyale Linux-Benutzer?Unverständliche Ratschläge.
Sie können Microsoft überzeugen. Bitten Sie sie, Backslashes als Systemdateipfade zu verwenden.

Ich möchte hier darauf hinweisen, dass es Anwendungsfälle gibt, in denen wörtliche Pfade mit Schrägstrichen benötigt werden, sogar unter Windows.

Ich habe gerade ein Skript geschrieben, in dem ich .net-APIs verwendet habe, um Zip-Archive zu manipulieren und zu erstellen. Hinzufügen von Einträgen zur ZIP-Datei mit dieser API:

    [System.IO.Compression.ZipFileExtensions]::CreateEntryFromFile(
        $zip, $file, $entry,
        [System.IO.Compression.CompressionLevel]::Optimal
    ) > $null

In diesem speziellen Fall ist $entry ein Pfad innerhalb des ZIP-Archivs. Wenn ich einfach den Windows-Pfad übergebe, wie er von verschiedenen Pfad-Cmdlets zurückgegeben wird, gibt jedes Zip-Dienstprogramm auf dem Planeten Warnungen aus, dass meine Zip-Datei die falschen Schrägstriche enthält.

Auch als langjähriger Linux-Benutzer und -Entwickler liebe ich Powershell und hatte viel Spaß beim Lernen. Ich hatte auch Spaß daran, mit meinem neuen Windows-Serverkern über ssh in Powershell 7 zu spielen, und ich habe Skripte veröffentlicht, die perfekt mit Powershell unter Linux funktionieren. Ich war überrascht, wie gut das funktioniert. Tatsächlich wird Powershell meine erste Wahl für einige Programme/Skripte sein, die ich plattformübergreifend verwenden möchte.

Aber es macht mich immer noch traurig zu sehen, dass alle meine Tab-Vervollständigungen mit Backslashes umgeschrieben werden.

Ich verwende die ganze Zeit Pfade wie /users/foo/somefile unter Windows und das möchte ich verwenden.

Die meisten Windows-APIs unterstützen Schrägstriche problemlos. Mir ist klar, dass es einige Ausnahmen mit Dienstprogrammen und möglicherweise APIs gibt, nämlich einige cmd.exe-Aufrufe, aber ich möchte nur etwas in meinem $profile festlegen, sodass standardmäßig alle meine Pfade Schrägstriche haben, es sei denn, ich verwende explizit Backslashes.

Dies wäre für Windows-Benutzer und -Entwickler, die an Backslashes gewöhnt sind, harmlos, da sie diese Einstellung einfach nicht verwenden würden und sie standardmäßig deaktiviert wäre. Natürlich können sie sich auch dafür entscheiden, es zu verwenden, wenn sie sich beispielsweise entscheiden, mehr plattformübergreifende Skripte und Module zu schreiben.

Ich möchte diese Einstellung auch für meine Skripte und Module, damit ich keine unerwarteten Probleme wie das oben gezeigte habe.

Benutzer von @iSazonov können Schrägstriche verwenden, die sie unabhängig von der Plattform verwenden.

Bedeutet dies, dass ich PowerShell so konfigurieren kann, dass Schrägstriche verwendet werden, da dies für mich als Benutzer bequemer ist? Ich möchte den in der Eingabeaufforderung angezeigten Pfad sowie die automatische Vervollständigung der Registerkarte ändern, die derzeit Schrägstriche in umgekehrte Schrägstriche umwandelt.

@aaronfranke , nein, es gibt derzeit keine Möglichkeit, PowerShell auf diese Weise zu konfigurieren; Ich denke, was @iSazonov sagen wollte, ist, dass Sie bei der manuellen Eingabe eines Pfads frei zwischen \ und / wählen können (und Sie können sie sogar in einem einzigen Pfad mischen). .

In Anbetracht der Vielseitigkeit sollte ein neues Pfadsymbol anstelle von / aktiviert werden, und ，Traditionelle Symbole erhöhen die Schwierigkeit der plattformübergreifenden Konvertierung

Ich denke, was @iSazonov sagen wollte, ist, dass Sie bei der manuellen Eingabe eines Pfads frei zwischen und / wählen können (und Sie können sie sogar in einem einzigen Pfad mischen).

Ja, es ist PowerShell-Design.

Dies ist keine Lösung der hier angesprochenen Probleme, wie z. B. das erzwungene Ersetzen Ihrer Pfadtrennzeichen während der Fertigstellung oder die Möglichkeit, Pfad-Cmdlets so zu konfigurieren, dass sie das Pfadtrennzeichen Ihrer Wahl verwenden, sollten wir separate, spezifische Probleme für sie öffnen ?

@rkitover Ich habe vor Jahren ohne Lösung nach solchen Szenarien gefragt (Sie können das Problem finden). Das überzeugt mich davon, dass es sich um eine kosmetische Änderung handelt, obwohl sie viel Aufwand erfordert. Wenn Sie bereit sind, in diesen Bereich zu investieren und eine PR zu ziehen, dann ist es nur sinnvoll, eine neue Diskussion zu eröffnen.

CP/M und Klone verwenden / für Optionen, Beispiele: DIR/P , CMD/CECHO . Dies sind gültige Befehle. Wenn wir \ / ersetzen, fürchte ich, dass es zu schlimmen Missverständnissen kommen kann.

1. Niemand verwendet mehr CP/M.

2. Die gleichzeitige Verwendung / für Optionen und Pfade funktioniert in meinen Tests unter Windows einwandfrei.

3. Moderne Tools verwenden stattdessen - für Optionen, darunter PowerShell-Tools und andere Microsoft-Tools wie .NET. Die Verwendung / für Optionen sollte aus Gründen der Abwärtskompatibilität beibehalten werden, aber Benutzer werden keine Verwirrung mit modernen Tools haben.

Außerdem möchte ich darauf hinweisen, dass der Schrägstrich / ein ungültiger Zeichenname in Win32-Dateinamen ist:

https://gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3

Kern

Ungültige Zeichen für Windows-Dateinamen

Ungültige Zeichen für Windows-Dateinamen. GitHub Gist: Code, Notizen und Snippets sofort teilen.

Ich möchte nur darauf hinweisen, dass ich anfing, Schrägstriche nur in plattformübergreifenden Skripten usw. zu verwenden, und auf ein Problem mit symbolischen Links gestoßen bin.

Als Beispiel laufen

new-item -itemtype SymbolicLink -path TestScript8.ps1 -target ./TestScript.ps1

unter Windows und Sie können TestScript8.ps1 nicht in VS Code unter Windows öffnen.

@markm77 , du hast einen _bug_ entdeckt - kannst du bitte ein neues Problem dafür erstellen ? [_update_: siehe #13064]

Nicht, dass dies ein Argument gegen einen Opt-in-Mechanismus für die Standardeinstellung von / wäre, @aaronfranke , aber beachten Sie, dass es einige Grenzfälle gibt, in denen / anstelle von \ immer noch kaputt geht Dinge unter Windows; z.B:

PS> cmd /c dir C:/
Invalid switch - ""

Den Pfad in doppelte Anführungszeichen zu setzen, hilft seltsamerweise nur bei _directory_ -Pfads - siehe https://stackoverflow.com/a/43297482/45375 , was auch zeigt, dass die Excel-COM-Automatisierungsbibliothek / nicht unterstützt.

Paketüberfluss

Warum möchte PowerShell meine Datei nicht als CSV speichern

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Öffne das Excel-Dokument und ziehe das Arbeitsblatt 'Sheet1' hinein $Excel = New-Object -Com Excel.Application $Arbeitsmappe...

@markm77 , du hast einen Fehler entdeckt - kannst du bitte ein neues Problem dafür erstellen?

Aber ist das ein PowerShell-Bug? PowerShell erstellt den korrekten symbolischen Link mit dem angegebenen Schrägstrich, wie verifiziert, indem der symbolische Link mit dir untersucht wird. Es scheint jedoch, dass ein Sym-Link, der mit dem falschen Slash-Typ erstellt wurde, dann in Apps wie VS Code unbrauchbar sein kann. Was vielleicht auch verständlich ist.

Hinweis: Es ist ziemlich einfach, dieses Problem zu umgehen, indem man convert-item auf Sym-Link-Zielen ausführt, was den zusätzlichen Vorteil hat, dass Sym-Links auf absolute Pfade zeigen (wahrscheinlich angemessen).

Hinweis: Es ist ziemlich einfach, dieses Problem zu umgehen, indem man convert-item auf Sym-Link-Zielen ausführt, was den zusätzlichen Vorteil hat, dass Sym-Links auf absolute Pfade zeigen (wahrscheinlich angemessen).

Unangemessen, wird beim erneuten Montieren brechen 😞

Unangemessen, wird beim erneuten Montieren brechen 😞

Fairer Kommentar, ich remounte nicht (dies ist für lokale Entwicklerarbeit) und ich habe ein Skript für die Link-Neugenerierung, das ich jederzeit ausführen kann. join-path ist offensichtlich die andere Lösung oder noch besser wäre eine new-item Option, um sicherzustellen, dass Links plattformgerecht sind.

Siehe #12797

Aber ist das ein PowerShell-Bug?

Während Sie argumentieren könnten, dass es sich unter _Windows_ um einen WinAPI-Fehler handelt, da \ und / normalerweise austauschbar unterstützt werden, ist es definitiv ein Fehler auf Unix-ähnlichen Plattformen, wenn Sie das Gegenteil tun und weitergeben ein \ -basierter Pfad als -Target -Pfad - auf solchen Plattformen wird nur / nativ unterstützt (es ist nur PowerShell, mit dem Sie \ als verwenden können eine Alternative, die mit eigenen Problemen einhergeht - siehe #9244), und es liegt in der Verantwortung von PowerShell, etwas wie .\TestScript.ps1 in ./TestScript.ps1 zu übersetzen, wenn der Symlink erstellt wird.

Wenn Sie dies beheben – indem Sie PowerShell dazu bringen, den Pfad zu normalisieren, um das (primäre) _platform-native_-Trennzeichen zu verwenden – wird das Problem auch unter Windows behoben.

@iSazonov , #12797 aktivierte grundsätzlich die Unterstützung für _relative_ Pfade als Symlink-Ziele, aber das vorliegende Problem ist das Fehlen einer plattformnativen Normalisierung von Trennzeichen, wodurch die resultierenden Symlinks beschädigt werden.

@iSazonov Bitte sehen Sie sich #13064 an, was ab PowerShell Core 7.1.0-preview.4 noch kaputt ist (was #12797 enthalten sollte, richtig)?

Vielen Dank an @mklement0 für eine scheinbar gründliche Untersuchung des relativen Symlink-Verhaltens und das Aufwerfen von Problemen https://github.com/PowerShell/PowerShell/issues/13064. Ich hatte mir eine Notiz gemacht, um das spezielle Problem, das ich hatte, und diese Diskussion weiter zu verfolgen, aber tatsächlich scheint es, dass Sie alles in https://github.com/PowerShell/PowerShell/issues/13064 behandelt und mir tatsächlich beigebracht haben, wie um PowerShell-Tests zu schreiben (ich bin neu bei PowerShell).... Cheers!

Ich habe dieses Thema nicht in allen Einzelheiten verfolgt, also entschuldigen Sie, wenn ich etwas übersehe. Das anfängliche Problem war ein plattformübergreifender standardisierter Pfadtrenner (möglicherweise ein Schrägstrich). @iSazonov hat dieses Problem jetzt geschlossen. Können Sie bitte einen Überblick geben, warum dies Ihrer Meinung nach nicht mehr gültig ist, damit die Personen, die Veranstaltungen zum Thema Abschluss abonniert haben, mitverfolgen können?

Es war nie gültig, gemäß https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 .

So etwas wie das, was @lzybkr oben vorgeschlagen hat, ist immer noch eine absolut vernünftige - und vermutlich einfache - Sache zu implementieren; um es noch einmal zusammenzufassen:

Ich denke, es wäre schön, wenn die Pfadvervollständigung das Pfadtrennzeichen verwenden würde, das explizit im Vervollständigungstext erscheint, und wenn es keins gibt, dann standardmäßig das native Trennzeichen der Plattform.

Es liegt dann in der Verantwortung des Benutzers, die - seltenen - Grenzfälle zu vermeiden, in denen / immer noch unter Windows abbricht (siehe oben ).

Dies verursacht echte Kopfschmerzen beim Ausführen von wsl-Bash-Skripten über Powershell. Mögen:

bash .\updateTemplate.sh

Dies sollte automatisch vervollständigt werden

bash ./updateTemplate.sh

Gibt es eine andere Problemumgehung für dieses Problem? Insbesondere wäre ich völlig in Ordnung, wenn PS den Pfad nur mit Schrägstrichen im Bash/WSL-Kontext automatisch vervollständigt.

Gibt es eine andere Problemumgehung für dieses Problem?

Erstellen Sie einen benutzerdefinierten Completor für Bash.

Gibt es eine andere Problemumgehung für dieses Problem?

Erstellen Sie einen benutzerdefinierten Completor für Bash.

Wie machst Du das?

Erhalten wir keine weitere Diskussion über die grundlose Schließung dieses Problems? Dies ist ein großes Ärgernis für die plattformübergreifende Arbeit. Jedes Mal, wenn ich Pfade automatisch vervollständige, die plattformübergreifenden Tools oder indirekt über wsl zu Linux-Tools zugeführt werden, muss ich meinen Cursor rückwärts durch den gesamten Pfad bewegen und jeden einzelnen umgekehrten Schrägstrich einzeln durch einen Schrägstrich ersetzen. Niemand sollte jemals auf diese Weise arbeiten müssen, und es macht Powershell als Befehlszeile wirklich fast unhaltbar.