L'alternative actuelle oblige les utilisateurs à normaliser les chemins

PowerShell fait déjà le travail pour vous et vous n'avez pas besoin de normaliser les chemins.
PowerShell est très convivial ici - les utilisateurs peuvent utiliser des barres obliques avec lesquelles ils sont à l'aise quelle que soit la plate-forme.
La meilleure pratique consiste à éviter d'utiliser des chemins littéraux et à utiliser des applets de commande de chemin.

La meilleure pratique consiste à éviter d'utiliser des chemins littéraux et à utiliser des applets de commande de chemin.

@iSazonov Oui et non.

Bien sûr, si vous combinez des segments de chemin, vous pouvez utiliser des cmdlets de chemin. Mais si vous écrivez un script qui fait référence à un chemin relatif avec plusieurs segments, et si vous avez l'intention que votre script fonctionne sur plusieurs plates-formes, vous n'allez pas le faire.

Dans PowerShell 7 Preview 3 sous Windows, la complétion de tabulation complète les chemins à l'aide d'une barre oblique inverse. C'est le seul endroit où je pense que nous nous trompons maintenant que PowerShell est multiplateforme. Il devrait au moins y avoir une option pour sélectionner le caractère séparateur de répertoire que vous souhaitez utiliser sous Windows dans le cadre de la complétion des tabulations : [System.IO.Path]::DirectorySeparatorChar ou [System.IO.Path]::AltDirectorySeparatorChar . Étant donné où nous en sommes aujourd'hui, je soupçonne que la plupart des gens qui effectuent un travail multiplateforme voudraient que la complétion par tabulation des chemins utilise AltDirectorySeparatorChar sous Windows par défaut, mais pour autant que je sache, il n'y a aucun moyen de le faire .

@chriskuech : Mis à part l'achèvement des tabulations des chemins, y a-t-il d'autres endroits où vous pensez que AltDirectorySeparatorChar n'est pas utilisé où vous aimeriez avoir une option pour qu'il soit utilisé au lieu de DirectorySeparatorChar ? Je ne peux penser à aucun.

@KirkMunro , dites-vous qu'il existe un moyen (au moins partiellement implémenté) de normaliser les chemins dans PowerShell aujourd'hui ? Si oui, cela fonctionnera-t-il sur la dernière version 6.x ? Les cas d'utilisation avec lesquels j'avais un problème étaient les variables automatiques et les commandes *-Path .

@iSazonov , la solution proposée n'aurait pas fonctionné pour mon scénario car j'ai généré une liste de chemins sous Windows, généré une liste de chemins sous Linux, puis tenté de les comparer, ce qui a échoué à cause des séparateurs.

Les variables automatiques manquent systématiquement d'un séparateur de répertoire de fin, donc PowerShell permet magnifiquement de créer des chemins avec des littéraux. Ex:

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

Je pense que c'est beaucoup plus clair que

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

donc j'espère que cela pourra fonctionner à l'avenir, même si ce n'est pas par défaut.

@chriskuech mon habitude personnelle est devenue quelque chose comme :

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

C'est un peu plus clair mais oui ce n'est pas parfait.

Join-Path a AdditionalChildPath qui accepte un tableau de chaînes.

@chriskuech Merci pour les informations supplémentaires.

Je ne suggérais pas que PowerShell prend partiellement en charge la normalisation des chemins. J'appelais simplement que je n'aime pas personnellement que l'achèvement des onglets utilise une barre oblique inverse par défaut sur Windows et une barre oblique vers l'avant par défaut sur Linux ou macOS.

Si je pouvais modifier certains paramètres pour modifier cela afin que la barre oblique soit utilisée même sur les chemins Windows par défaut, je ferais ce changement, et c'est un endroit où je pense qu'il pourrait y avoir une opportunité de faciliter le travail multiplateforme de PowerShell. Join-Path utilise également [System.IO.Path]::DirectorySeparatorChar comme séparateur de chemin. Idéalement, s'il existait un paramètre permettant de définir le séparateur de chemin souhaité lors de l'écriture de scripts (car nous devrions pouvoir écrire facilement des scripts comme nous le souhaitons, quelle que soit la plate-forme sur laquelle nous choisissons de les écrire), cela se refléterait à la fois dans l'achèvement des tabulations de chemins et Join-Path également.

Mis à part ces besoins personnels, je me demande si une applet de commande Compare-Path serait utile. Il pourrait normaliser les séparateurs de chemin et même comparer les chemins absolus avec les chemins relatifs en résolvant les chemins relatifs avant que la comparaison ne soit effectuée si l'un des chemins est absolu.

Eh bien, nous obtenons une normalisation _spécifique à la plate-forme_ dans Convert-Path et Resolve-Path :

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

Donc, peut-être comme alternative à l'introduction d'une applet de commande Compare-Path , Convert-Path et Resolve-Path pourraient être étendus pour prendre en charge un commutateur -UseSlash (nom négociable).

Séparément et de manière complémentaire, le mécanisme de préférence opt-in pour l'utilisation / sous Windows suggéré par Kirk pourrait alors s'appliquer également à Convert-Path et Resolve-Path (en plus de l'achèvement des tabulations et Join-Path ).

Le hic pour le moment est que Convert-Path et Resolve-Path ne fonctionnent qu'avec des chemins _existants_, mais c'est quelque chose qui vaut la peine d'être changé, comme @jaykul l' a suggéré il y a longtemps - voir # 2993

Je pense que ce serait bien si l'achèvement du chemin utilisait le séparateur de chemin qui apparaît explicitement dans le texte d'achèvement, et s'il n'y en a pas, alors par défaut le séparateur natif de la plate-forme.

Ainsi, sous Windows, c:\w se termine en c:\Windows\ et c:/w se termine en 'c:/Windows/'.

Je pense que cela couvrirait la majorité des désagréments sans nécessiter d'option de configuration, et est en fait préférable car vous pourriez parfois avoir besoin de l'autre formulaire pour une raison quelconque.

@lzybkr , j'aime l'idée, également à la lumière d'une préoccupation concernant une solution basée sur la configuration / la variable de préférence que j'ai omis de mentionner : le problème de la portée ; avec la portée _dynamique_ habituelle, le code qui fait des hypothèses fixes sur les séparateurs de chemin peut se casser (ce qui fait écho à https://github.com/PowerShell/PowerShell-RFC/issues/7).

@lzybkr et quand les deux barres obliques sont utilisées ? C:\Program Files/A -> ?

Tant d'options - aléatoire, alterner chacune, toujours barre oblique b/c c'est le seul vrai séparateur de chemin, etc.

Plus sérieusement, choisissez peut-être simplement le dernier utilisé, qui est probablement tapé par l'utilisateur alors que d'autres ne le sont peut-être pas.

@lzybkr : Il y a cependant un hic :

Si vous démarrez _sans_ séparateur de chemin, afin de référencer un fichier/dossier dans le _répertoire actuel_, PowerShell devra faire le choix pour vous, au moins en fonction de l'algorithme de complétion actuel qui se développe en .\<filename> ou ./<filename> / .\<folder>\ ou ./<folder>/ , en fonction de la plate-forme.

Pour les _files_ comme _arguments_, nous pourrions contourner ce problème en développant fil à seulement file , par exemple (pas de préfixe .\ / ./ ).

Pourtant:

• pour _executables_ , le préfixe .\ / ./ ajouté automatiquement est une commodité précieuse si l'intention est bien d'exécuter un script situé dans le répertoire courant.

• pour les _répertoires_, de même, l'expansion vers quelque chose avec un _séparateur de chemin de fin_ ( <folder>\ ou <folder>/ ) est également utile.

Dans les deux cas, aucune action de l'utilisateur n'implique le séparateur préféré.

Cela dit, la solution est peut-être la suivante : si vous souhaitez contrôler le séparateur, _commencez manuellement par_ ./ ou .\ et faites en sorte que la complétion des tabulations respecte cela.

Ce problème a été marqué comme résolu et n'a eu aucune activité depuis 1 jour . Il a été fermé pour des raisons de ménage.

@iSazonov : Cela n'a pas vraiment de réponse et devrait être rouvert pour permettre à la discussion en cours de continuer à résoudre ce problème. Le PO n'a même pas eu l'occasion de répondre aux questions qui lui ont été posées.

Je pense que j'ai posé toutes les questions à moi, mais faites-moi savoir si ce n'est pas le cas. Moi aussi je ne sais pas pourquoi ce sujet est clos. Il ne s'agissait pas d'un fil de discussion, mais plutôt d'une demande de fonctionnalité.

Le problème fondamental à portée de main :

• Un outil multiplateforme doit-il avoir un comportement non multiplateforme par défaut ?
• Si tel est le cas, devrait-il y avoir un moyen d'exécuter globalement PowerShell en mode "multiplateforme" ?

Je pense que forcer les développeurs à normaliser manuellement les chaînes avec des applets de commande est définitivement une mauvaise décision. Je ne vois aucun scénario dans lequel l'utilisation / par défaut causerait des problèmes sous Windows car PowerShell, comme mentionné précédemment, est très efficace pour gérer les deux types de barres obliques. À moins que quelqu'un ne puisse fournir des situations convaincantes où cela entraînerait une erreur, pourquoi ne pas simplement utiliser / par défaut ? Peut-être que ce problème doit être déplacé vers un RFC.

Alors que de plus en plus de personnes migrent vers le cloud, de plus en plus de personnes développent du code PowerShell sous Windows et l'exécutent sous Linux. Il y aura certainement un moment dans le futur (s'il n'est pas déjà passé) où le nombre d'utilisateurs préférant un véritable comportement multiplateforme dépassera tous ceux qui souhaitent conserver \ sous Windows.

@chriskuech : Mon mauvais, je ne vous ai pas spécifiquement posé la question. Je me demandais si vous pensiez qu'une applet de commande Conpare-Path vous aiderait. Cette question mise à part, j'aimerais également voir des options de normalisation.

@KirkMunro Je ne suis pas sûr que Compare-Path aiderait, car dans le cas d'utilisation d'origine (comparaison des chemins sur Linux et Windows), le système de fichiers racine est différent, je dois donc appeler Resolve-Path -Relative . À ce stade, le cas d'utilisation de la comparaison n'est qu'une ligne : | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

Cependant, j'hésite beaucoup à approuver une solution basée sur une applet de commande, car elle ne résout pas le problème racine et interdira l'interpolation de chaîne pour les chemins ou nécessitera des modifications de code pour chaque définition de chaîne de chemin. Plus précisément, Compare-Path ne résoudra pas tous mes chemins enregistrés avec des barres obliques mixtes.

@KirkMunro @mklement0 Le problème n'est pas verrouillé et tout le monde peut tirer des commentaires.
Nous avons beaucoup de problèmes sans nouveaux commentaires ni progrès. Le statut ouvert a perdu son sens.
En tant que mainteneur, j'ai l'intention d'être plus exigeant afin d'encourager les discussions à devenir des spécifications plus rigoureuses qui peuvent facilement se transformer en PR.
Quant au problème, il devient infini - la demande initiale était "utiliser une barre oblique sur Windows", puis "comparer les chemins". Quelle est la prochaine? À distance ? Il est ouvert pour continuer mais sera fermé.
Alors qu'une seule vraie proposition de Jason était ci-dessus (pour améliorer l'achèvement) et nous pouvions ouvrir un problème de suivi et le fermer par de vrais relations publiques.

Pour être clair, le problème est toujours "utiliser une barre oblique sous Windows". "Comparer les chemins" n'a été évoqué que comme un (parmi plusieurs) exemples motivants.

Proposition
Implémentez un véritable comportement multiplateforme, où le délimiteur de chemin par défaut est / sur toutes les plates-formes, sauf si l'utilisateur complète par tabulation un chemin contenant déjà \ . Je m'attendrais à ce que cela soit masqué en tant que fonctionnalité expérimentale pour le moment, mais je devrais au moins pouvoir activer une fonctionnalité "maximiser le comportement multiplateforme" dans mon code pour optimiser l'expérience de développement des développeurs Windows ciblant Linux.

Si cela n'est pas raisonnable, j'aimerais savoir pourquoi et s'il existe une documentation guidant lorsque la conception de PowerShell diverge d'une plate-forme à l'autre.

@iSazonov : Les mainteneurs du référentiel PS ne devraient pas négliger les problèmes des utilisateurs sans discussion. Vous avez initialement répondu sans prendre le temps de comprendre les besoins de l'OP, en marquant le problème comme résolu, mais le problème n'a pas été publié en tant que question, il a été publié en tant que demande de fonctionnalité et, comme le montre la discussion, il est clairement non répondu".

Le statut ouvert a perdu son sens.

Qui dit? Ce n'est absolument pas vrai. Un problème ouvert est ouvert et un problème fermé est fermé. Ces deux distinctions ont un sens très clair. Je ne regarde les problèmes fermés que s'ils sont les miens et je veux revenir en arrière pour vérifier quelque chose. En de rares occasions, je peux aller chercher des questions fermées pour des discussions sur un certain sujet. Mais 90% ou plus de mon temps sur les problèmes est consacré aux problèmes ouverts, comme il se doit. La seule chose qui brouille la frontière entre les deux et fait perdre leur sens aux problèmes ouverts est de les fermer sommairement avant qu'ils ne soient résolus, comme vous l'avez fait avec ce problème.

(La discussion) est ouverte pour continuer mais sera fermée.

Sur la base de cette approche de la gestion des problèmes, vous obligez les gens à perdre la distinction entre les problèmes ouverts et fermés, de sorte qu'ils doivent rechercher tous les problèmes plutôt que de se concentrer sur les problèmes ouverts, ce qui signifie vérifier les problèmes ouverts 2K plus les problèmes fermés 4K. pour des discussions qui les concernent au lieu de se concentrer uniquement sur les questions ouvertes. C'est une stratégie de gestion des problèmes cassée et imparfaite.

Quant au problème, il devient infini - la demande initiale était "utiliser une barre oblique sur Windows", puis "comparer les chemins". Quelle est la prochaine? À distance ?

C'est ridicule. La discussion est axée sur le traitement de Windows ayant une barre oblique inverse par défaut lorsque vous écrivez des scripts pour plusieurs plates-formes. Il est resté concentré sur ce sujet. Vous essayez de donner l'impression qu'il n'est pas concentré du tout.

@iSazonov , je suis d'accord qu'il y a trop de problèmes ouverts ; cependant, le fait qu'il y ait trop de questions ouvertes ne signifie pas que nous devrions être dédaigneux et interrompre prématurément la conversation sur de nouvelles questions. Nous devons continuer à encourager les commentaires et être ouverts aux discussions sur PowerShell dans les problèmes ouverts, et ne les fermer qu'une fois qu'ils sont vraiment résolus. Le volume des questions ouvertes doit être traité différemment.

Utilisateurs fidèles de Linux ? Conseils incompréhensibles.
Vous pouvez convaincre Microsoft. Demandez-leur d'utiliser des barres obliques inverses comme chemins d'accès aux fichiers système.

J'aimerais souligner ici qu'il existe des cas d'utilisation où des chemins littéraux avec des barres obliques sont nécessaires, même sous Windows.

J'étais en train d'écrire un script dans lequel j'utilisais des API .net pour manipuler et créer des archives zip. Ajout d'entrées au fichier zip avec cette API :

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

Dans ce cas particulier, $entry est un chemin dans l'archive zip. Si je passe simplement le chemin Windows tel qu'il est renvoyé par diverses applets de commande de chemin, chaque utilitaire zip de la planète émettra des avertissements indiquant que mon fichier zip contient les mauvaises barres obliques.

Également en tant qu'utilisateur et développeur Linux de longue date, j'adore Powershell et je me suis beaucoup amusé à l'apprendre. Je me suis également amusé à jouer avec mon nouveau noyau de serveur Windows sur ssh dans powershell 7, et j'ai publié des scripts qui fonctionnent parfaitement avec powershell sous linux. J'ai été surpris de voir à quel point cela fonctionne. En fait, powershell va être mon premier choix pour certains programmes/scripts que je veux être multiplateformes.

Mais cela me rend toujours triste de voir tous mes achèvements d'onglets être réécrits avec des barres obliques inverses.

J'utilise tout le temps des chemins comme /users/foo/somefile sur Windows et c'est ce que je veux utiliser.

La plupart des API Windows prennent très bien en charge les barres obliques. Je me rends compte qu'il y a quelques exceptions, avec des utilitaires et peut-être des API, à savoir certaines invocations cmd.exe, mais je veux juste définir quelque chose dans mon profil $ afin que, par défaut, tous mes chemins aient des barres obliques, sauf si j'utilise explicitement des barres obliques inverses.

Ce serait inoffensif pour les utilisateurs de Windows et les développeurs habitués aux barres obliques inverses, car ils n'utiliseraient tout simplement pas ce paramètre et il serait désactivé par défaut. Bien sûr, ils peuvent également décider de l'utiliser si, par exemple, ils décident d'écrire davantage de scripts et de modules multiplateformes.

Je veux aussi ce paramètre pour mes scripts et mes modules, afin de ne pas avoir de problèmes inattendus comme celui que j'ai montré ci-dessus.

Les utilisateurs de @iSazonov peuvent utiliser des barres obliques avec lesquelles ils sont à l'aise quelle que soit la plate-forme.

Cela signifie-t-il que je peux configurer PowerShell pour utiliser des barres obliques puisque c'est plus confortable pour moi en tant qu'utilisateur ? Je souhaite modifier le chemin affiché dans l'invite ainsi que la saisie semi-automatique de l'onglet qui transforme actuellement les barres obliques en barres obliques inverses.

@aaronfranke , non, il n'y a actuellement aucun moyen de configurer PowerShell de cette façon ; Je pense que ce que @iSazonov essayait de dire, c'est que lorsque vous tapez manuellement un chemin, vous êtes libre de choisir entre \ et / (et vous pouvez même les mélanger dans un seul chemin) .

Compte tenu de la polyvalence, un nouveau symbole de chemin doit être activé à la place de / et ， Les symboles traditionnels augmentent la difficulté de conversion entre les plates-formes

Je pense que ce que @iSazonov essayait de dire, c'est que lorsque vous tapez manuellement un chemin, vous êtes libre de choisir entre et / (et vous pouvez même les mélanger dans un seul chemin).

Oui, c'est la conception PowerShell.

Il ne s'agit pas d'une résolution des problèmes qui ont été soulevés ici, tels que le remplacement forcé de vos séparateurs de chemin lors de l'achèvement, ou la possibilité de configurer des applets de commande de chemin pour utiliser le séparateur de chemin de votre choix, devrions-nous ouvrir des problèmes distincts et spécifiques pour eux ?

@rkitover J'ai posé des questions sur de tels scénarios il y a des années (vous pouvez trouver le problème) sans aucune résolution. Cela me convainc qu'il s'agit d'un changement cosmétique, bien qu'il nécessite beaucoup d'efforts. Si vous êtes prêt à investir dans ce domaine et à faire un PR, alors seulement il est logique d'ouvrir une nouvelle discussion.

CP/M et les clones utilisent / pour les options, exemples : DIR/P , CMD/CECHO . Ce sont des commandes valides. Si nous remplaçons \ par / partout, je crains que de mauvais malentendus ne se produisent.

1. Plus personne n'utilise CP/M.

2. L'utilisation / pour les options et les chemins en même temps fonctionne très bien sous Windows lors de mes tests.

3. Les outils modernes utilisent plutôt - pour les options, y compris les outils PowerShell et d'autres outils Microsoft tels que .NET. L'utilisation / pour les options doit être conservée pour la rétrocompatibilité, mais les utilisateurs n'auront aucune confusion avec les outils modernes.

De plus, je voudrais noter que la barre oblique / est un nom de caractère invalide dans les noms de fichiers Win32 :

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

Essentiel

Caractères non valides pour les noms de fichiers Windows

Caractères non valides pour les noms de fichiers Windows. GitHub Gist : partagez instantanément du code, des notes et des extraits.

Je veux juste souligner que j'ai commencé à utiliser des barres obliques uniquement dans les scripts multiplateformes, etc., et que j'ai rencontré un problème avec les liens symboliques.

Par exemple, exécutez

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

sous Windows et vous ne pourrez pas ouvrir TestScript8.ps1 dans VS Code sous Windows.

@markm77 , vous avez découvert un _bug_ - pouvez-vous s'il vous plait créer un nouveau problème pour lui ? [_mise à jour_ : voir #13064]

Non pas que ce soit un argument contre un mécanisme opt-in pour la valeur par défaut de / , @aaronfranke , mais notez qu'il y a peu de cas extrêmes où / au lieu de \ se casse encore choses sur Windows ; par exemple:

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

La double citation du chemin n'aide qu'avec les chemins _directory_, curieusement - voir https://stackoverflow.com/a/43297482/45375 , qui montre également que la bibliothèque Excel COM Automation ne prend pas en charge / .

Débordement de pile

Pourquoi PowerShell ne veut-il pas enregistrer mon fichier au format CSV

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Ouvrez le document Excel et insérez la feuille de calcul 'Sheet1' $Excel = New-Object -Com Excel.Application $Cahier d'exercices...

@markm77 , vous avez découvert un bogue - pouvez-vous s'il vous plaît créer un nouveau problème pour cela ?

Mais est-ce un bug PowerShell ? PowerShell crée le lien symbolique correct avec la barre oblique spécifiée, comme vérifié en examinant le lien symbolique à l'aide dir . Il semble cependant qu'un lien symbolique créé avec le mauvais type de barre oblique puisse alors être inutilisable dans des applications telles que VS Code. Ce qui est aussi compréhensible peut-être.

NB, il est assez facile de contourner ce problème en exécutant convert-item sur des cibles de liens symboliques, ce qui a l'avantage supplémentaire de garantir que les liens symboliques pointent vers des chemins absolus (probablement appropriés).

NB, il est assez facile de contourner ce problème en exécutant convert-item sur des cibles de liens symboliques, ce qui a l'avantage supplémentaire de garantir que les liens symboliques pointent vers des chemins absolus (probablement appropriés).

Inapproprié, se cassera au remontage 😞

Inapproprié, se cassera au remontage 😞

Commentaire juste, je ne remonte pas (c'est pour le travail de développement local) et j'ai un script pour la régénération de lien que je peux exécuter à tout moment. join-path est évidemment l'autre solution ou encore mieux serait une option new-item pour s'assurer que les liens sont adaptés à la plate-forme.

Voir #12797

Mais est-ce un bug PowerShell ?

Bien que vous puissiez affirmer que sur _Windows_, il s'agit d'un bogue WinAPI, étant donné que \ et / sont généralement pris en charge de manière interchangeable, c'est définitivement un bogue sur les plates-formes de type Unix si vous faites l'inverse et passez un chemin basé \ comme chemin -Target - sur ces plates-formes, seul / est pris en charge de manière native (c'est uniquement PowerShell qui vous permet d'utiliser \ comme une alternative, qui vient avec ses propres problèmes - voir #9244), et il est de la responsabilité de PowerShell de traduire quelque chose comme .\TestScript.ps1 en ./TestScript.ps1 lors de la création du lien symbolique.

Corriger cela - en faisant en sorte que PowerShell normalise le chemin pour utiliser le séparateur (primaire) _platform-native_ - résoudra également le problème sous Windows.

@iSazonov , # 12797 a fondamentalement activé la prise en charge des chemins _relative_ en tant que cibles de liens symboliques, mais le problème actuel est le manque de normalisation des séparateurs natifs de la plate-forme, ce qui rend les liens symboliques résultants rompus.

@iSazonov Veuillez consulter # 13064 pour ce qui est toujours cassé à partir de PowerShell Core 7.1.0-preview.4 (qui devrait inclure # 12797, n'est-ce pas)?

Merci @ mklement0 pour ce qui semble être une enquête approfondie sur le comportement relatif des liens symboliques et la levée du problème https://github.com/PowerShell/PowerShell/issues/13064. J'avais pris note du suivi du problème particulier que j'avais et de cette discussion, mais en fait, il semble que vous ayez tout couvert dans https://github.com/PowerShell/PowerShell/issues/13064 et m'avez en fait appris comment pour écrire des tests PowerShell (je suis nouveau sur PowerShell).... Santé !

Je n'ai pas suivi cette question dans les moindres détails donc excusez-moi si je rate quelque chose. Le problème initial était un séparateur de chemin standardisé multiplateforme (potentiellement une barre oblique). @iSazonov a maintenant fermé ce problème. Pouvez-vous s'il vous plaît donner un aperçu de la raison pour laquelle vous pensez que cela n'est plus valable afin que les personnes qui se sont abonnées aux événements de clôture des problèmes puissent suivre ?

Il n'a jamais été valide, selon https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 .

Quelque chose comme ce que @lzybkr a proposé ci-dessus est toujours une chose parfaitement raisonnable - et vraisemblablement facile - à mettre en œuvre ; récapituler:

Je pense que ce serait bien si l'achèvement du chemin utilisait le séparateur de chemin qui apparaît explicitement dans le texte d'achèvement, et s'il n'y en a pas, alors par défaut le séparateur natif de la plate-forme.

Il est alors de la responsabilité de l'utilisateur d'éviter les - rares - cas où / se brise encore sous Windows (voir ci- dessus ).

Cela provoque un véritable casse-tête lors de l'exécution de scripts wsl bash via powershell. Comme:

bash .\updateTemplate.sh

Cela devrait être complété automatiquement pour

bash ./updateTemplate.sh

Existe-t-il une autre solution à ce problème ? en particulier, je serais tout à fait d'accord si PS complète automatiquement le chemin avec des barres obliques dans le contexte bash/WSL uniquement.

Existe-t-il une autre solution à ce problème ?

Créer un compléteur personnalisé pour bash.

Existe-t-il une autre solution à ce problème ?

Créer un compléteur personnalisé pour bash.

Comment est-ce que tu fais ça?

N'avons-nous plus de discussions sur la fermeture sans fondement de cette question ? C'est un inconvénient majeur pour le travail multiplateforme. Chaque fois que je complète automatiquement des chemins qui sont alimentés vers des outils multiplateformes ou indirectement via wsl vers des outils Linux, je dois faire reculer mon curseur sur tout le chemin et remplacer individuellement chaque barre oblique inverse par une barre oblique. Personne ne devrait jamais avoir à travailler de cette façon, et cela rend véritablement Powershell en tant que ligne de commande presque intenable.