Текущая альтернатива заставляет пользователей нормализовать пути

PowerShell уже делает всю работу за вас, и вам не нужно нормализовать пути.
PowerShell здесь очень удобен для пользователя — пользователи могут использовать косые черты, которые им удобны, независимо от платформы.
Лучше всего избегать использования буквальных путей и использовать командлеты пути.

Лучше всего избегать использования буквальных путей и использовать командлеты пути.

@iSazonov Да и нет.

Конечно, если вы объединяете сегменты пути, вы можете использовать командлеты пути. Но если вы пишете сценарий, который ссылается на относительный путь с несколькими сегментами, и если вы хотите, чтобы ваш сценарий работал на разных платформах, вы не собираетесь этого делать.

В предварительной версии PowerShell 7 3 для Windows завершение табуляции завершает пути с использованием обратной косой черты. Это единственное место, где я думаю, что мы делаем это неправильно, поскольку PowerShell является кроссплатформенным. По крайней мере, должна быть возможность выбрать символ разделителя каталогов, который вы хотите использовать в Windows как часть завершения табуляции: [System.IO.Path]::DirectorySeparatorChar или [System.IO.Path]::AltDirectorySeparatorChar . Учитывая, где мы находимся сегодня, я подозреваю, что большинство людей, которые выполняют какую-либо кросс-платформенную работу, хотели бы, чтобы завершение путей с помощью табуляции использовало AltDirectorySeparatorChar в Windows по умолчанию, но, насколько я знаю, нет никакого способа заставить это сделать .

@chriskuech : Помимо завершения путей с помощью табуляции, есть ли другие места, где, по вашему мнению, AltDirectorySeparatorChar не используется, где вы хотели бы иметь возможность использовать его вместо DirectorySeparatorChar ? Я не могу думать ни о каком.

@KirkMunro , вы говорите, что сегодня есть (по крайней мере, частично реализованный) способ нормализовать пути в PowerShell? Если да, то будет ли он работать на последней версии 6.x? Варианты использования, с которыми у меня возникла проблема, — это автоматические переменные и команды *-Path .

@iSazonov , предложенное решение не сработало бы для моего сценария, потому что я сгенерировал список путей в Windows, сгенерировал список путей в Linux, а затем попытался их сравнить, что не удалось из-за разделителей.

В автоматических переменных постоянно отсутствует завершающий разделитель каталогов, поэтому PowerShell прекрасно позволяет создавать пути с литералами. Бывший:

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

Я думаю, что это намного яснее, чем

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

так что я надеюсь, что это может работать в будущем, даже если не по умолчанию.

@chriskuech моя личная привычка стала примерно такой:

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

Это немного яснее, но да, это не идеально.

Join-Path имеет AdditionalChildPath , которые принимают строковый массив.

@chriskuech Спасибо за дополнительную информацию.

Я не предполагал, что PowerShell частично поддерживает нормализацию путей. Я просто говорил, что мне лично не нравится, что завершение с помощью табуляции по умолчанию использует обратную косую черту в Windows и прямую косую черту по умолчанию в Linux или macOS.

Если бы я мог настроить какой-либо параметр, чтобы изменить его так, чтобы косая черта использовалась даже в путях Windows по умолчанию, я бы внес это изменение, и это то место, где, я думаю, может быть возможность упростить кросс-платформенную работу PowerShell. Join-Path также использует [System.IO.Path]::DirectorySeparatorChar в качестве разделителя пути. В идеале, если бы была настройка для установки желаемого разделителя пути при написании скриптов (потому что мы должны иметь возможность легко писать скрипты так, как мы хотим, независимо от платформы, на которой мы их пишем), это отражалось бы в завершении обеих вкладок пути и Join-Path .

Помимо этих личных потребностей, мне интересно, будет ли полезен командлет Compare-Path . Он может нормализовать разделители путей и даже сравнивать абсолютные пути с относительными путями, разрешая относительные пути до выполнения сравнения, если один из путей является абсолютным.

Что ж, мы получаем нормализацию для конкретной платформы в Convert-Path и Resolve-Path :

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

Таким образом, возможно, в качестве альтернативы внедрению командлета Compare-Path , Convert-Path и Resolve-Path можно было бы расширить для поддержки переключателя -UseSlash (имя может быть согласовано).

Отдельно и дополнительно механизм отказа для использования / в Windows, который предлагает Кирк, может также применяться к Convert-Path и Resolve-Path (в дополнение к завершению табуляции и Join-Path ).

Подвох на данный момент заключается в том, что Convert-Path и Resolve-Path работают только с _существующими_ путями, но это то, что стоит изменить само по себе, как @jaykul предложил долгое время назад - см. # 2993

Я думаю, было бы неплохо, если бы в дополнении пути использовался разделитель пути, который явно появляется в тексте завершения, а если его нет, то по умолчанию используется родной разделитель платформы.

Таким образом, в Windows c:\w завершается до c:\Windows\ , а c:/w завершается до 'c:/Windows/'.

Я думаю, что это покроет большинство неприятностей, не требуя опции конфигурации, и на самом деле предпочтительнее, потому что вам иногда может понадобиться другая форма по какой-либо причине.

@lzybkr , мне нравится эта идея, в том числе в свете беспокойства по поводу решения на основе переменной конфигурации / предпочтения, о котором я забыл упомянуть: проблема области действия; с обычным _динамическим_ охватом код, который делает фиксированные предположения о разделителях пути, может сломаться (что имеет отголоски https://github.com/PowerShell/PowerShell-RFC/issues/7).

@lzybkr, а когда используются обе косые черты? C:\Program Files/A -> ?

Так много вариантов - случайный, чередующийся каждый, всегда косая черта, потому что это единственный истинный разделитель пути и т. д.

А если серьезно, может быть, просто выберите последний использованный, который, вероятно, введен пользователем, а другие могут быть нет.

@lzybkr : есть одна загвоздка:

Если вы запускаете _без_ разделителя пути, чтобы сослаться на файл/папку в _текущем каталоге_, PowerShell должен будет сделать выбор за вас, по крайней мере, на основе текущего алгоритма завершения, который расширяется до .\<filename> или ./<filename> / .\<folder>\ или ./<folder>/ , в зависимости от платформы.

Для _files_ as _arguments_ мы могли бы обойти эту проблему, например, расширив fil до file (без префикса .\ / ./ ).

Тем не мение:

• для _executables_ автоматически добавленный префикс .\ / ./ является ценным удобством, если намерение действительно состоит в том, чтобы выполнить скрипт, расположенный в текущем каталоге.

• для _каталогов_ аналогично расширение до чего-то с _конечным разделителем пути_ ( <folder>\ или <folder>/ ) также ценно.

В обоих случаях нет никаких действий пользователя, чтобы указать предпочитаемый разделитель.

Тем не менее, возможно, решение таково: если вы хотите управлять разделителем, _вручную начните с_ ./ или .\ и сделайте так, чтобы завершение табуляции учитывало это.

Этот вопрос был помечен как отвеченный, и в течение 1 дня не было никаких действий. Он был закрыт для хозяйственных нужд.

@iSazonov : На самом деле на это нет ответа, и его следует открыть снова, чтобы позволить продолжающейся дискуссии продолжить работу над этим. У ОП даже не было возможности ответить на заданные ему вопросы.

Я думаю, что адресовал все вопросы мне, но дайте мне знать, если я этого не сделал. Я тоже не уверен, почему этот вопрос закрыт. Это не было задумано как ветка обсуждения, а скорее запрос функции.

Основная проблема под рукой:

• Должен ли кроссплатформенный инструмент по умолчанию иметь не кроссплатформенное поведение?
• Если да, то должен ли быть способ глобального запуска PowerShell в «кросс-платформенном» режиме?

Я думаю, что заставлять разработчиков вручную нормализовать строки с помощью командлетов — определенно неправильный шаг. Я не вижу сценариев, в которых использование / по умолчанию могло бы вызвать проблемы в Windows, потому что PowerShell, как упоминалось ранее, очень хорошо справляется с обоими типами косой черты. Если кто-то не может предоставить убедительные ситуации, в которых это может вызвать ошибку, почему бы просто не использовать / по умолчанию? Возможно, этот вопрос нужно перенести в RFC.

По мере того, как все больше людей переходят в облако, все больше и больше людей разрабатывают код PowerShell для Windows и запускают его в Linux. В будущем обязательно наступит момент (если он уже не пройден), когда количество пользователей, предпочитающих истинное межплатформенное поведение, превзойдет число тех, кто решительно настроен сохранить \ в Windows.

@chriskuech : Плохо, я специально не задавал тебе вопрос. Мне было интересно, не считаете ли вы, что командлет Conpare-Path поможет вам. Однако, помимо этого вопроса, я хотел бы также увидеть варианты нормализации.

@KirkMunro Я не уверен, что Compare-Path поможет, потому что в исходном варианте использования (сравнение путей в Linux и Windows) корневая файловая система отличается, поэтому мне нужно вызвать Resolve-Path -Relative . На этом этапе вариант использования для сравнения — всего лишь однострочный: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

Однако я очень не решаюсь одобрить какое-либо решение на основе командлета, поскольку оно не решает основной проблемы и либо запрещает интерполяцию строк для путей, либо требует внесения изменений в код для каждого определения строки пути. В частности, Compare-Path не исправит все мои зарегистрированные пути со смешанными косыми чертами.

@KirkMunro @mklement0 Проблема не закрыта, и каждый может комментировать.
У нас много вопросов без новых замечаний и подвижек. Статус Open потерял свое значение.
Как специалист по сопровождению, я намереваюсь быть более строгим, чтобы поощрить дискуссии к более строгим спецификациям, которые легко могут превратиться в PR.
Что касается проблемы, то она превращается в бесконечную - первоначальный запрос был «использовать косую черту в Windows», затем «сравнить пути». Что следующее? Удаленное взаимодействие? Он открыт для продолжения, но будет закрыт.
В то время как выше было только одно реальное предложение от Джейсона (для улучшения завершения), и мы могли открыть проблему отслеживания и закрыть ее по реальному PR.

Чтобы было ясно, проблема по-прежнему «использовать косую черту в Windows». «Сравнить пути» было приведено только как один (из нескольких) мотивирующих примеров.

Предложение
Реализуйте истинное межплатформенное поведение, при котором разделитель пути по умолчанию равен / на всех платформах, если только пользователь не завершает путь с помощью табуляции, уже содержащий \ . Я ожидаю, что на данный момент это будет скрыто как экспериментальная функция, но я должен, по крайней мере, иметь возможность включить функцию «максимальное кроссплатформенное поведение» в моем коде для оптимизации опыта разработки разработчиков Windows, ориентированных на Linux.

Если это неразумно, я хотел бы знать, почему и есть ли документация, которая указывает, когда дизайн PowerShell расходится на разных платформах.

@iSazonov : Сопровождающие репозиторий PS не должны пренебрежительно относиться к проблемам пользователей без обсуждения. Первоначально вы ответили, не потратив времени на то, чтобы понять потребности ОП, пометив проблему как отвеченную, но проблема не была опубликована как вопрос, она была опубликована как запрос функции, и, как видно из обсуждения, это ясно не отвечено".

Статус Open потерял свое значение.

Кто говорит? Это абсолютно не так. Открытая проблема остается открытой, а закрытая — закрытой. Эти два различия имеют очень ясное значение. Я просматриваю закрытые вопросы только в том случае, если они мои собственные, и я хочу вернуться, чтобы что-то проверить. В редких случаях я могу искать закрытые вопросы для обсуждения определенной темы. Но 90% или более моего времени в проблемах приходится на открытые проблемы, как и должно быть. Единственное, что стирает грань между ними и заставляет открытые проблемы терять свое значение, — это закрывать их до того, как они будут решены, как вы сделали с этой проблемой.

(Обсуждение) открыто для продолжения, но будет закрыто.

Основываясь на таком подходе к управлению проблемами, вы заставляете людей терять различие между открытыми и закрытыми, так что им приходится искать все проблемы, а не сосредотачиваться на открытых проблемах, что означает проверку 2 тысяч открытых проблем плюс 4 тысячи закрытых проблем. для обсуждений, относящихся к ним, вместо того, чтобы просто сосредоточиться на открытых вопросах. Это сломанная, ошибочная стратегия управления проблемами.

Что касается проблемы, то она превращается в бесконечную - первоначальный запрос был «использовать косую черту в Windows», затем «сравнить пути». Что следующее? Удаленное взаимодействие?

Это смешно. Обсуждение сосредоточено на работе с Windows, имеющей обратную косую черту по умолчанию, когда вы пишете сценарии для кросс-платформы. Он по-прежнему сосредоточен на этой теме. Вы пытаетесь сделать так, чтобы это звучало так, как будто оно вообще не сфокусировано.

@iSazonov , я согласен, что слишком много открытых вопросов; однако тот факт, что существует слишком много открытых вопросов, не означает, что мы должны игнорировать и преждевременно прекращать обсуждение новых вопросов. Мы должны продолжать поощрять отзывы и быть открытыми для обсуждения PowerShell в открытых проблемах и закрывать их только после того, как они будут действительно решены. Объем открытых вопросов должен решаться по-другому.

Верные пользователи Linux? Непонятный совет.
Вы можете убедить Microsoft. Попросите их использовать обратную косую черту в качестве путей к системным файлам.

Я хотел бы отметить здесь, что есть случаи использования, когда нужны буквальные пути с косой чертой, даже в Windows.

Я просто писал сценарий, в котором использовал API .net для управления и создания zip-архивов. Добавление записей в zip-файл с помощью этого API:

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

В данном конкретном случае $entry — это путь внутри zip-архива. Если я просто передам путь Windows, возвращенный различными командлетами пути, каждая утилита zip на планете будет выдавать предупреждения о том, что мой zip-файл имеет неправильные косые черты.

Кроме того, как давний пользователь и разработчик Linux, я люблю powershell, и мне было очень весело его изучать. Мне также было весело играть с моим новым ядром сервера Windows через ssh в powershell 7, и я опубликовал сценарии, которые отлично работают с powershell в Linux. Я был удивлен, насколько хорошо это работает. Фактически, powershell будет моим первым выбором для некоторых программ/скриптов, которые я хочу сделать кроссплатформенными.

Но мне все еще грустно видеть, что все мои завершения вкладок переписываются с обратной косой чертой.

Я постоянно использую такие пути, как /users/foo/somefile в Windows, и это то, что я хочу использовать.

Большинство API-интерфейсов Windows прекрасно поддерживают косую черту. Я понимаю, что есть несколько исключений, с утилитами и, возможно, API, а именно с некоторыми вызовами cmd.exe, но я просто хочу установить что-то в своем профиле $, чтобы по умолчанию все мои пути имели прямую косую черту, если только я не использую обратную косую черту явно.

Это было бы безобидно для пользователей и разработчиков Windows, привыкших к обратной косой черте, потому что они просто не использовали бы этот параметр, и по умолчанию он был бы отключен. Конечно, они могут решить использовать и его, если, например, решат больше писать кроссплатформенные скрипты и модули.

Я хочу, чтобы этот параметр был установлен и для моих скриптов и модулей, чтобы у меня не было неожиданных проблем, подобных той, что я показал выше.

Пользователи @iSazonov могут использовать косые черты, которые им удобны, независимо от платформы.

Означает ли это, что я могу настроить PowerShell для использования косой черты, поскольку мне как пользователю это удобнее? Я хотел бы изменить путь, отображаемый в подсказке, а также автозаполнение вкладки, которое в настоящее время изменяет косую черту на обратную косую черту.

@aaronfranke , нет, в настоящее время нет возможности настроить PowerShell таким образом; Я думаю, что @iSazonov пытался сказать, что когда вы вводите путь вручную, вы можете выбирать между \ и / (и вы даже можете смешивать их в одном пути) .

Учитывая универсальность, следует включить новый символ пути вместо / и ，Традиционные символы усложняют преобразование на разных платформах.

Я думаю, что @iSazonov пытался сказать, что когда вы вводите путь вручную, вы можете свободно выбирать между и / (и вы даже можете смешивать их в одном пути).

Да, это дизайн PowerShell.

Это не решение поднятых здесь проблем, таких как принудительная замена ваших разделителей пути во время завершения или возможность настройки командлетов пути для использования выбранного вами разделителя пути, если мы создадим для них отдельные конкретные проблемы. ?

@rkitover Я спрашивал о таких сценариях много лет назад (вы можете найти проблему) без какого-либо решения. Это убеждает меня, что это косметическое изменение, хотя оно и требует больших усилий. Если вы готовы вкладываться в это направление и тянуть пиар, то только имеет смысл открывать новую дискуссию.

CP/M и клоны используют / для опций, например: DIR/P , CMD/CECHO . Это допустимые команды. Если мы везде заменим \ на / , я боюсь, что могут возникнуть плохие недоразумения.

1. Никто больше не использует CP/M.

2. Использование / одновременно для опций и путей отлично работает в Windows в моем тестировании.

3. Вместо этого современные инструменты используют - для параметров, включая инструменты PowerShell и другие инструменты Microsoft, такие как .NET. Использование / для параметров должно быть сохранено для обратной совместимости, но у пользователей не возникнет путаницы с современными инструментами.

Также я хотел бы отметить, что косая черта / является недопустимым именем символа в именах файлов Win32:

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

Суть

Недопустимые символы для имен файлов Windows

Недопустимые символы для имен файлов Windows. GitHub Gist: мгновенно делитесь кодом, заметками и фрагментами.

Я просто хочу отметить, что я начал использовать косую черту только в кроссплатформенных сценариях и т. Д. И столкнулся с проблемой с символическими ссылками.

Например, запустить

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

в Windows, и вы не сможете открыть TestScript8.ps1 в VS Code в Windows.

@ markm77 , вы обнаружили _ошибку_, не могли бы вы создать для нее новую проблему ? [_update_: см. #13064]

Не то чтобы это был аргумент против механизма подписки по умолчанию на / , @aaronfranke , но обратите внимание, что есть несколько крайних случаев, когда / вместо \ все еще не работает вещи на Windows; например:

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

Любопытно, что двойное цитирование пути помогает только с путями _directory_ - см. https://stackoverflow.com/a/43297482/45375 , который также показывает, что библиотека Excel COM Automation не поддерживает / .

Переполнение стека

Почему PowerShell не хочет сохранять мой файл в формате CSV

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Откройте документ Excel и извлеките рабочий лист Sheet1 $Excel = New-Object -Com Excel.Application $ Рабочая тетрадь...

@ markm77 , вы обнаружили ошибку - не могли бы вы создать для нее новую проблему?

Но является ли это ошибкой PowerShell? PowerShell создает правильную символическую ссылку с указанной косой чертой, что подтверждается проверкой символической ссылки с помощью dir . Однако кажется, что символическая ссылка, созданная с неправильным типом косой черты, может быть непригодной для использования в таких приложениях, как VS Code. Что тоже, наверное, понятно.

NB довольно легко обойти эту проблему, запустив convert-item на целях символической ссылки, что имеет дополнительное преимущество, заключающееся в том, что символические ссылки указывают на абсолютные пути (вероятно, уместно).

NB довольно легко обойти эту проблему, запустив convert-item для целей символической ссылки, что имеет дополнительное преимущество, заключающееся в том, что символические ссылки указывают на абсолютные пути (вероятно, уместно).

Не подходит, сломается при перемонтировании 😞

Не подходит, сломается при перемонтировании 😞

Справедливый комментарий, я не перемонтирую (это для локальной работы разработчиков), и у меня есть скрипт для перегенерации ссылок, который я могу запустить в любое время. join-path , очевидно, является другим решением, или даже лучше будет вариант new-item , чтобы гарантировать, что ссылки подходят для платформы.

См. № 12797

Но является ли это ошибкой PowerShell?

Хотя вы можете возразить, что в _Windows_ это ошибка WinAPI, учитывая, что \ и / обычно взаимозаменяемы, это определенно ошибка на Unix-подобных платформах, если вы сделаете обратное и пропустите путь на основе \ в качестве пути -Target — на таких платформах изначально поддерживается только / (только PowerShell позволяет использовать \ в качестве альтернатива, которая имеет свои проблемы — см. #9244), и PowerShell несет ответственность за преобразование чего-то вроде .\TestScript.ps1 в ./TestScript.ps1 при создании символической ссылки.

Исправление этого — заставив PowerShell нормализовать путь для использования (основного) разделителя _platform-native_ — также устранит проблему в Windows.

@iSazonov , #12797 принципиально включил поддержку _relative_ путей в качестве целей символических ссылок, но проблема заключается в отсутствии встроенной в платформу нормализации разделителей, что делает результирующие символические ссылки неработающими.

@iSazonov См. # 13064, чтобы узнать, что все еще не работает в PowerShell Core 7.1.0-preview.4 (который должен включать # 12797, верно)?

Спасибо @mklement0 за тщательное исследование относительного поведения символических ссылок и поднятие проблемы https://github.com/PowerShell/PowerShell/issues/13064. Я сделал примечание, чтобы продолжить рассмотрение конкретной проблемы, которая у меня была, и это обсуждение, но на самом деле кажется, что вы рассмотрели все в https://github.com/PowerShell/PowerShell/issues/13064 и фактически научили меня, как писать тесты PowerShell (я новичок в PowerShell).... Ура!

Я не следил за этим вопросом во всех деталях, поэтому извините меня, если я что-то упустил. Первоначальной проблемой был кросс-платформенный стандартизированный разделитель пути (возможно, косая черта). @iSazonov закрыл эту проблему. Не могли бы вы дать обзор, почему вы считаете, что это больше не действует, чтобы люди, которые были подписаны на мероприятия по закрытию проблемы, могли следить за ними?

Согласно https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471, он никогда не был действительным.

Что-то вроде того, что @lzybkr предложил выше , по-прежнему вполне разумно и, по-видимому, легко реализовать; резюмировать:

Я думаю, было бы неплохо, если бы в дополнении пути использовался разделитель пути, который явно появляется в тексте завершения, а если его нет, то по умолчанию используется родной разделитель платформы.

В этом случае ответственность за предотвращение редких случаев, когда / все еще не работает в Windows, лежит на пользователе (см. выше ).

Это вызывает настоящую головную боль при запуске скриптов wsl bash через powershell. Нравится:

bash .\updateTemplate.sh

Это должно быть автозаполнение для

bash ./updateTemplate.sh

Есть ли другой обходной путь для этой проблемы? в частности, я был бы полностью в порядке, если бы PS автозаполнял путь косой чертой только в контексте bash/WSL.

Есть ли другой обходной путь для этой проблемы?

Создайте собственный комплемент для bash.

Есть ли другой обходной путь для этой проблемы?

Создайте собственный комплемент для bash.

Как ты это делаешь?

У нас больше не будет дискуссий о необоснованном закрытии этого вопроса? Это серьезное неудобство для кроссплатформенной работы. Каждый раз, когда я автоматически заполняю пути, которые передаются в кросс-платформенные инструменты или косвенно через wsl в инструменты Linux, мне приходится перемещать курсор назад по всему пути и индивидуально заменять каждую обратную косую черту косой чертой. Никто никогда не должен работать таким образом, и это действительно делает Powershell как командную строку почти несостоятельной.