Это делает использование rm , ls и т.д. отстойным, поскольку глобализация не выполняется:

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

Мля.

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

• Переменная среды для отключения всех псевдонимов, которые конфликтуют с двоичными файлами * nix.
• Одиночный символ (например, ^ ), который автоматически попадает в собственный PATH
• Скажите людям, что они должны bash -c (многие сказали, что это слишком много символов, чтобы их можно было использовать)
• Скажите людям, что они должны указать полный путь (технически этот опыт уже работает, но он очень плохой)
• Дополнительное предложение: используйте «подсистему подсказок», чтобы сообщить людям, что они, возможно, хотели использовать встроенную команду, если они используют наборы параметров, которые соответствуют шаблонам для встроенных двоичных файлов * nix. Это все еще может работать только в случае сбоя команды (например, rm -e не завершится ошибкой).

Я думаю, что это то, что мы хотим выяснить раньше, чем позже, поэтому я переместил это на v0.5.0. На мой взгляд, настройка PowerShell для переключения режимов - лучший первый шаг.

@andschwa и по умолчанию будет ....?

@vors мое _персональное_ мнение: псевдонимы PowerShell включены; потому что вы используете PowerShell.

В конце концов, нам все равно понадобится руководство по «началу работы» для PowerShell при первом запуске, и мы заявим, что это доступный параметр.

@BrucePay какие-нибудь обновления по этому

Сегодняшняя синхронизация удобства использования подтвердила, что псевдонимы должны быть возвращены. (Подключение к sort - это еще одна точка данных при полностью нарушенном опыте PS.)

Оставив Брюса в качестве правопреемника для определения наилучшего пути вперед с указанными выше смягчениями. @andschwa : нам, вероятно, понадобится еще кто-то, кто будет делать работу по возврату псевдонимов.

Я только что разговаривал с @jpsnover, и он очень ясно дал понять, что мы не возвращаем псевдонимы. Мы должны создать файл aliases.ps1 для папки входящих сообщений и продвигать его использование через точечные источники.

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

Псевдонимы PowerShell вообще не работают как псевдонимы в Linux, поэтому нам нужно либо определить ls как функцию, либо улучшить наши псевдонимы, чтобы они работали больше как псевдонимы bash.

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

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

Похоже, у нас есть история, закрывающая вопрос.

Мой 2p по этому поводу - новая переменная настроек PowerShell, аналогичная $ PSModuleAutoLoadingPreference, которая была представлена ​​в PSv3, позволила бы конечному пользователю контролировать это в своих профилях (также можно было бы собрать простой пример, показывающий некоторые команды, работающие с PS и без него. Псевдонимы как хорошее

Предполагаемое имя $ PSUsePowerShellAliases, и если для него явно не задано значение true (в профиле или интерактивно), вместо него будут использоваться стандартные псевдонимы * nix.
Я считаю, что это, вероятно, также улучшит UX для тех, кто теперь может решить протестировать воду с помощью PowerShell, чего раньше не делал бы, поскольку это не отнимает то, что они знают, но позволяет тем из нас, кто знает способ PS, возможность сделать то же самое.

не забирая то, что они знают

Абсолютно. Если нужен компромисс, то он должен быть в пользу пользователей Linux Bash, то есть потенциальных новых пользователей PowerShell. Существующие приверженцы PowerShell могут достаточно легко воссоздать свои псевдонимы * nix, а еще лучше - избавиться от этих псевдонимов.

Фактически, теперь, когда у нас есть PowerShell в Linux, я бы хотел, чтобы встроенные псевдонимы * nix были удалены из всех версий ОС PowerShell Core - если они еще не были. Это оставит встроенные псевдонимы, которые соответствуют встроенным командам PowerShell и не пытаются вас «обмануть».

Я сторонник удаления общих псевдонимов из ps в Linux по умолчанию - я не поклонник «исправления» этого в Windows, как предлагает Кейт. Мой аргумент в пользу этого заключается в том, что если вы склоните пользователя Linux к PowerShell, а затем он решит также попробовать его в Windows, у них не будет общих псевдонимов.

Можно ли добавить в PSReadline возможность включения псевдонимов Linux или нет? Для меня легко исправить мой код, который использует короткие имена для функций. Тем не менее, я всегда буду вводить сначала LS и ожидать, что он будет работать как псевдоним PowerShell LS для Get-ChildItem .

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

Я думаю, что то, что затронули @kilasuit , @rkeithhill и @ 1RedOne, кажется лучшим решением - отключите его по умолчанию в Linux и macOS, но в то же время упростите нам включение его в консоли или в наши скрипты.

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

Не по теме - очень рад, что PowerShell доступен на других платформах! 😄

что касается PSReadLine, то @lzybkr должен иметь возможность предложить, возможно ли это вообще, хотя я бы предпочел это как переменную PS, чем требование для PSReadLine, поскольку есть такие, как @juneb, которые вообще не используют PSReadline

Конечно, я мог бы опубликовать образец для PSReadline, чтобы заменить определенные псевдонимы командлетом PowerShell, он будет основан на этом образце: https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354

Тем не менее, я не думаю, что это реальное решение ..

На мой взгляд, самая большая проблема - это конфликт между переносимостью сценария и его привычностью. Мы дали рекомендации, что в сценариях не следует использовать псевдонимы, но это все еще обычная практика. Некоторые псевдонимы могут быть более проблематичными, чем другие, например, sort может использоваться в скриптах больше, чем ps или ls .

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

Замена команд PowerShell собственными исполняемыми файлами без поддержки глобализации определенно не поможет убедить разработчиков bash использовать PowerShell.

Так что, ребята, может быть, лучше просто добавить поддержку глобусов в нативные исполняемые файлы? Это решит все проблемы и сделает PowerShell более удобным для всех, верно? Ссылка № 954.

Как пользователь * nix, который почти никогда не касался окон, я хотел бы решительно проголосовать за то, чтобы оставить псевдонимы. Многие годы мышечной памяти научили меня использовать ls , rm и т. д. Я не хочу заново изучать свою мышечную память (а затем заново изучать ее всякий раз, когда я попадаю в bash), чтобы получить собственный опыт Powershell.

Поправьте меня, если я ошибаюсь, но разве это отличается для dir на windows? В PS в Windows dir не является dir.exe . Это Get-ChildItem . На * nix, почему ls должно быть /bin/ls вместо Get-ChildItem ?

@Gaelan Я понял вашу точку зрения, но учтите, что в Windows нет файла dir.exe . dir - это внутренняя команда процессора команд cmd , аналогичная встроенной команде bash . Возможно, это (одна) причина, потому что PowerShell не был разработан для прямого вызова этой внешней команды dir.exe .

@Gaelan , @ForNeVeR : Хотя встроенные cmd никогда не будут конфликтовать, потому что они не существуют в виде программ, существуют псевдонимы PowerShell, которые конфликтуют с собственными исполняемыми файлами, даже в Windows.

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

PS> gal|?{gcm "$_.exe" -ea 0}

CommandType     Name
-----------     ----
Alias           fc -> Format-Custom
Alias           sc -> Set-Content
Alias           sort -> Sort-Object
Alias           where -> Where-Object
Alias           write -> Write-Output

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

Лично я предпочел бы оставить псевдонимы. Как правило, они используются для ускорения и удобства навигации и общего использования оболочки. Их удаление ухудшит впечатление от использования PowerShell.

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

Если вы посмотрите здесь историю, я предложил то, что я считаю лучшим решением с точки зрения UX для псевдонимов, которые соответствуют эквивалентным командам, отличным от Windows.

Это давняя проблема PowerShell. Я жалуюсь, что у него нет команды, сопоставимой с dir cmd или даже с ls . Каждый раз ответ: «Но есть псевдоним!».

Псевдонимы не являются и никогда не были решением этой проблемы. Псевдонимы dir и ls не предоставляют функциональных возможностей, которые предоставляют dir и ls . То же верно и для псевдонимов wget и curl .

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

Почему определенные системой псевдонимы не могут быть просто гражданами второго сорта по сравнению с двоичными файлами в PATH?

Я бы сказал, удаляйте все псевдонимы * nix в Linux, сборках OS X, пока вы не поймете, что делать.

Изменить: спасибо за пояснение, что это уже было сделано, извините за прерывание.

@okket, что уже сделано. Мы обсуждаем, нужно ли что-то менять.

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

bash-aliases.ps1
dos-aliases.ps1
initial-aliases.ps1

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

Не будем забывать (@sleepypikachu), что псевдонимы PowerShell не делают ничего, кроме переименования команды и отмены порядка разрешения команд. Функциональность alias Bash требует _функций_ в PowerShell.

@Gaelan, ваша мышечная память заставляет вас использовать псевдоним, но не расстроились бы вы, если параметры и поведение не работают так же, как настоящая команда?

Это настоящая проблема, и @DrPizza на

Итак, здесь действительно есть три связанных проблемы:

1. Не все параметры имеют псевдонимы
2. Не все собственные параметры или поведение отображаются в CmdLet PowerShell.
3. Нужен способ запустить собственную команду, если существует псевдоним

Я не думаю, что №1 - это слишком большая проблема, и если бы они были псевдонимами, ситуация усугубилась бы. В любом случае dir -recurse - более читаемый параметр, чем dir / s. Кроме того, кроссплатформенность делает скрипты несовместимыми при переходе с Windows на Linux и наоборот.

2 и № 3 являются наиболее важными. Я никогда не использовал curl, но я знаю, что столкнулся с ограничениями Invoke-WebRequest, которые, как я ожидал, может делать curl. (Не помню с головы).

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

По умолчанию, оставьте его включенным. Это PowerShell .... в Linux. Он должен вести себя как PowerShell, чтобы они могли узнать, какие CmdLets использовать. Моему коллеге, имеющему опыт работы с Linux и Perl, было намного проще вычислить cmds, которые нужны ему для работы сценария. Я думаю, что для него ключевыми были grep, ls и man. Использование man должно помочь им понять, как правильно использовать cmd.

В долгосрочной перспективе добавьте покрытие к собственным командлетам, чтобы иметь все параметры и возможности собственных команд. Это расширяет возможности PowerShell для Windows и Linux, предоставляя нам более мощные возможности. Некоторые варианты поведения, вероятно, потребуется преобразовать в несколько CmdLet и использовать объекты и конвейеры, но это замечательно! Если бы этого не произошло, тогда в чем был бы смысл PowerShell?

Мое мнение - оставить как есть. В PowerShell нет псевдонима (кроме select и т. Д., Они обязательны), псевдонима в Windows PowerShell.

Предоставить вариант лучше, но предоставить все псевдонимы в качестве параметров ... ну, не невозможно.

IMHO имеет смысл иметь псевдоним ls для dir, поскольку я мог легко использовать Where-Object для фильтрации файлов. Я много лет пользуюсь Linux, и набирать dir не так естественно, как использовать ls.

Мне кажется, что последовательность важна. Я не против удаления псевдонимов с других платформ, но меня беспокоит наличие интерфейса, который ведет себя по-разному в зависимости от ОС. Одним из основных моментов использования PS на * nix является то, что это один интерфейс для управления всем. Если псевдонимы будут удалены из PowerShell на вновь поддерживаемых платформах, я думаю, что следует подумать над тем, следует ли их удалять и в Windows.

Нет, я решительно поддерживаю то, что PS предоставляет псевдонимы по умолчанию, но реальная вещь ниже должна иметь точно такую ​​же функциональность (и, возможно, совместимость параметров) с исходными собственными двоичными файлами, за исключением поддержки ввода.
PowerShell без типов бесполезен.

Использование базовых системных двоичных файлов и принятие философии инструментов Unix будет способствовать их принятию. Как человек, который занимается DevOps в магазинах Unix, я был приятно удивлен, обнаружив, что обычные двоичные файлы unix в какой-то мере работали в этой реализации. Что касается проблемы с символом *, я думаю, что большинству людей на стороне * nix было бы удобно использовать escape-символ перед * при указании глобуса оболочки * nix, в отличие от того, что его текущее поведение находится в powershell. Наверное, было бы приемлемым решением для | поскольку канал, создающий объект вместо потока октетов, передаваемых между файлами, противоречит опубликованным стандартам и будет препятствовать их принятию. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis обратите внимание: никто не собирается удалять типы из PowerShell ; либо gci и Get-ChildItem остаются одинаковыми как в Windows PowerShell, так и в Linux PowerShell. Здесь мы говорим только о том, должен ли встроенный псевдоним типа ls -> Get-ChildItem существовать в Linux или нет. Ваши сценарии не должны вызывать ls или gci любом случае, если вы хотите вызвать Get-ChildItem (поскольку использование псевдонимов в сценариях не рекомендуется и никогда не рекомендовалось). ls и gci - это всего лишь удобные псевдонимы для использования в командной строке, и это _ может_ запутать пользователя Linux, если ls внезапно получит псевдоним Get-ChildItem а не его любимая родная команда; это запутает его еще больше, если у него нет краткого способа вызвать эту команду напрямую.

Я за использование команды для включения псевдонима в PowerShell.
Сохраните все псевдонимы и постепенно откажитесь от них в Windows PowerShell.

Я думаю, используя команду вроде

Enable-Alias Unix
Enable-Alias dos

Включение псевдонима имеет следующие преимущества

1. Это решает проблему для людей, которые хотят использовать собственный curl.
2. Это отговаривает людей использовать псевдонимы в скриптах (что мешает читабельности скрипта).
3. Людям, которые любят эти псевдонимы, очень легко включить их
4. и это практически не влияет на производительность.

@ForNeVeR Я использую ls как gci весь день, потому что это на одну букву короче ...
Однако введение этого изменения (удаление псевдонимов unix-y и dos-y) определенно является критическим изменением (это не похоже на curl ). «Идеальным» решением может быть реализация этих команд для типизированного расширения существующих инструментов.
Для скриптов, может быть ... выражение using ?

@ForNeVeR Я думаю, вы неправильно поняли @ be5invis . Он решительный сторонник PowerShell. Я думаю, что он имеет в виду, что «powershell без типа бесполезен», так это то, что людям не следует использовать собственный curl в powershell.

@ be5invis Также я думаю, что ваше представление о совместимости собственного curl далеко идёт. Грамматика powershell несовместима со стандартной грамматикой unix, например, вы можете сделать rm -rf в unix, но в powershell вам нужно сделать rm -r -fo .
Поэтому вы никогда не достигнете совместимости параметров ни при каких условиях.

@chantisnake Так почему бы не добавить параметр под названием «rf», равный -recurse -force ?

@ be5invis Это fr . Также внезапно -Recurse больше не сможет быть сокращено до -r но вместо этого должно быть -re чтобы не конфликтовать с предложенным вами параметром -rf .

Тот же вопрос можно задать и с другой стороны: почему бы не указать оба параметра по отдельности? Вы готовы пойти против принципов и соглашений кода PowerShell в значительной степени, только чтобы продолжать делать вид, что вы все еще работаете с теми же инструментами Unix, даже если это не так. Однако соглашения о параметрах GNU с их короткими и длинными именами вряд ли универсальны, и многие хорошо зарекомендовавшие себя инструменты идут против них, например, tar или find . И все же вы не в силах воспользоваться их трекерами ошибок, чтобы их изменить. В то время как ядро ​​Unix всегда заключалось в том, что существует миллиард различных служебных программ, каждая из которых работает немного по-разному, внезапно появляется еще одна из них (по общему признанию, она делает немного больше и пытается охватить в себе множество других утилит). настолько обескураживающий и проблемный, что его нужно изменить? Я так не думаю.

Помните: оболочка вашей машины - ваша. Точно так же, как люди используют псевдоним rm для rm -i для собственного удобства, ничто не мешает вам удалить псевдоним rm и получить функцию, оборачивающую Remove-Item называется rm с параметром -rf .

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

Функциональность и результативность ls были хорошо определены в течение многих лет. Команда ls выводит поток октетов в хорошо известном формате. Команда ls не выводит объекты DirectoryInfo и FileInfo. То, что ls выводит что-то другое, как минимум сбивает с толку и, возможно, немного обманчиво.

Когда пользователь будет готов воспользоваться преимуществами объектов в конвейере, он узнает о Get-ChildItem и gci. Если пользователь не хочет иметь преимущества или иметь дело с объектами в конвейере, ему может быть лучше использовать bash, ksh, csh, sh и т. Д.

То же самое можно сказать и о команде DIR в Windows.

Пусть * nix будет * nix, и Powershell станет лучше.

@ Литург

Когда пользователь будет готов воспользоваться преимуществами объектов в конвейере, он узнает о Get-ChildItem и gci. Если пользователь не хочет иметь преимущества или иметь дело с объектами в конвейере, ему может быть лучше использовать bash, ksh, csh, sh и т. Д.

Это противоречит вашей точке зрения. Если люди используют Powershell, им, вероятно, нужны объекты в конвейере. Мы не должны заставлять затем переучивать основные команды, чтобы воспользоваться этим.

Согласитесь с @Gaelan.
Если кому-то не нужны объекты, он может просто переключиться на bash или zsh.
Им нужны преимущества объектов, и наложение таких вещей, как ls на совместимую, но типизированную версию, даст им именно то, что они хотят.

@Gaelan и @ be5invis , я понимаю желание ограничить количество изменений, которые пользователь должен сделать для использования Powershell. Кажется, мои пальцы печатают ls до того, как мой мозг посылает им сигнал.

Проблема в том, что существующие базовые команды не производят объектов. Фактическое изменение, которое необходимо сделать, не с ls на gci . Более значительный переход от мышления к обработке строк текста к размышлениям о свойствах и методах, которые можно применить к объекту.

Каждый пользователь имеет право создавать любые псевдонимы по своему усмотрению. Я согласен, что это можно упростить для пользователя, добавив метод и свойство в $ Host (System.Management.Automation.Internal.Host.InternalHost), чтобы включить или отключить замену собственных команд. Я видел и другие, но есть ли в Powershell инструмент настройки профиля графического интерфейса?

Если кому-то не нужны объекты, он может просто переключиться на bash или zsh.

Почему PowerShell не может предоставить «легкий путь» для людей, которые годами использовали bash, а затем решили окунуться в воду PowerShell? Пусть они начнут с того, что они знают, и начнут поэтапно внедрять функции PowerShell (например, объекты, генерирующие команды и объекты в конвейере), по мере того, как им становится удобнее использовать PowerShell.

Я не могу сказать вам, сколько раз мне приходилось использовать строку «_PowerShell - это оболочка . Она прекрасно выполняет ваши любимые нативные утилиты_», чтобы люди перестали думать, что они могут использовать PowerShell только с этими забавно звучащими командами. и заставить их попробовать PowerShell. PowerShell необходимо как можно лучше уважать популярные нативные утилиты и работать с ними. В конце концов, это одна из основных задач «оболочки».

@rkeithhill Итак, позвольте мне прояснить: пользователям, которые хотят использовать Powershell, нужны типы, верно? Однако ваши собственные инструменты, такие как /bin/ls , не могут взаимодействовать с типами. Следовательно, переход на типизированную оболочку, но без типизированных утилит, изменение бессмысленно.

Следовательно, типичные пользователи Unix могут захотеть ввести идентичную команду, но получить результат сразу. Итак, есть два варианта:

1. Цель типизированной протокол IPC и сказать Линус , чтобы обновить свои инструменты - Нет, они wont't, потому что он определил их ВРАГОМ, то ЗЛО Господь, разрушитель свободного мира! Нас собираются «обнимать, расширять и тушить»! или же...
2. Псевдоним ls встроенной функции с совместимыми параметрами.

Пользователи хотят использовать Powershell, им нужны типы, верно?

В конце концов, вероятно, так и будет. Тем не менее, я работаю с рядом разработчиков, которых я начал над PowerShell, просто продавая им использование его с Git и Posh-Git (чего CMD не может предоставить). На данный момент они редко что-либо разрабатывают, но я ожидаю, что они добьются этого. Дело в том, что утилита git.exe работает в PowerShell так же, как в CMD. Легкий переход.

Для меня ls (например, ps, grep, sed, awk, gcc, curl и т. Д.) - это просто еще одна нативная утилита, которую может запускать любая "оболочка". Теперь, если кто-то готов и хочет, чтобы команда выдачи объекта для вывода содержимого контейнера отображалась, он может использовать Get-ChildItem или его псевдоним gci . Если они настроены никогда не использовать встроенную утилиту ls , тогда они могут создать псевдоним ls для Get-ChildItem в своем профиле.

Кстати, я не думаю, что попытка сделать параметр Get-ChildItem совместимым с ls возможна. Вы очень быстро зависнете, если параметры PowerShell не чувствительны к регистру, например -c / -C, -d / -D, -i / -I. PowerShell не поддерживает комбинирование параметров, например ls -rt. Это досягаемость, и это нарушает принцип монад PowerShell. Такая задача, как сортировка, будет выполняться отдельным командлетом (Sort-Object), а не самим Get-ChildItem.

@rkeithhill Я не собираюсь делать Get-ChildItem совместимым с ls . Я предлагаю другой командлет, который может называться UnixCompatibles-ls качестве его полного имени и иметь отдельный синтаксический анализатор команд, который принимает вариант GNU getopt вместо PowerShell.

@ be5invis Разве в этом случае не более простой вариант - отдельная функция, которая запускает ls , передает ей все свои аргументы, анализирует вывод и создает из них объекты? Полностью отдельный синтаксический анализатор команд (вместе с полностью отдельными метаданными команд, форматирование для Get-Help , ...) - это немного излишне (не считая репликации большей части внутренней работы PowerShell несовместимым образом.

Здесь всегда будет два разных мира, один родной, другой типизированный. PowerShell уже обслуживает их обоих, имея возможность выполнять собственные программы и командлеты. Лично я не вижу никакой выгоды (просто масштабное мероприятие при разработке) в попытке добавить слой над собственными командами, который реплицирует их метаданные параметров в PowerShell. Кроме того, что бы вы сделали с tar или find (и множеством других программ), которые AFAIK не придерживаются соглашений GNU. Реализовать еще _другой_ синтаксический анализатор команд вместе с функциями оболочки для их вызова? Также обратите внимание, что для работы синтаксического анализатора команд аргументы собственной программы должны анализироваться в PowerShell и не должны конфликтовать с языком. Что-то, что может быть сложно со странными вещами, такими как [ .

@ygra Ничего страшного.

Пользователи хотят использовать Powershell, им нужны типы, верно?

@ be5invis , возможно, здесь происходит небольшая ls создает поток текста.

UnixCompatibles - глагол? Изменит ли это сценарий $ PROFILE пользователя навсегда или только для этого сеанса? Я бы не хотел, чтобы Get-ChildItem был ls-совместимым. Пусть ls будет ls и сделает то, что делает ls . Похоже, это даст пользователю возможность заменить ls на Get-ChildItem . Все в порядке. Я не уверен, что хочу этого, но для тех, кто хочет, это нормально.

@Liturgist Я думаю, что @ be5invis означает, что если люди ls (в Linux или macOS), они бы никогда не возились с Powershell.

@Gaelan Значит, мне не следует использовать PowerShell, если мне нужно использовать gcc или git? Что плохого в том, чтобы позволить людям решать, нужен ли им текст (ls) или объекты (gci)? Есть больше причин для использования PowerShell, чем просто его объектно-ориентированный характер - каким бы мощным он ни был. Черт возьми, я бы предпочел использовать PowerShell только для его C / C # подобных операторов потока управления (vs if / fi и switch case / esac) и его правильной системы типов (где числа - это числа, а не строки).

@rkeithhill

Значит, мне не следует использовать PowerShell, если мне нужно использовать gcc или git?

В системе * nix, если бы пользователи просто хотели использовать оболочку для gcc или git, они бы не стали беспокоиться о PowerShell, потому что оболочка, поставляемая с их ОС, отлично справляется с этим.

Черт возьми, я бы предпочел использовать PowerShell только для его C / C #, например операторов потока управления (против if / fi и switch case / esac)

Возможно, если бы кто-то уже использовал PowerShell, он бы предпочел это из-за этого, но я сомневаюсь, что кто-то установил бы PS только для этого.

его правильная система типов (где числа - это числа, а не строки)

/bin/ls также не работает с системой типов: если я запустил ls -l , я получу размеры файлов в виде строки вместо правильного номера PS.

Я чувствую, что причины, по которым новый пользователь переключится на PS на * nix, в значительной степени связаны с объектно-ориентированным дизайном и системой типов. Мы должны максимально упростить для новых пользователей начало работы с PS - если бы я увидел что-то о PS, попытался проверить это, только чтобы обнаружить, что мне нужно заново изучить все о командной строке, чтобы использовать ее, я, вероятно, У меня гораздо меньше шансов запомнить его, чем если бы я мог запустить PS, набрать ls и сразу увидеть систему типов в действии. Да, я мог бы использовать псевдонимы, но если я просто опробую PS в течение нескольких свободных минут, я вряд ли захочу много настраивать, прежде чем я начну играть.

В системе * nix, если бы пользователи просто хотели использовать оболочку для gcc или git, они бы не стали беспокоиться о PowerShell, потому что оболочка, поставляемая с их ОС, отлично справляется с этим.

Возможно, если бы кто-то уже использовал PowerShell, он бы предпочел это из-за этого, но я сомневаюсь, что кто-то установил бы PS только для этого.

Извините, но я категорически не согласен. Как пользователь Linux, я хочу использовать PowerShell вместо оболочки, поставляемой с моей ОС. За все. Потому что это круто, знаете ли :)

Черт возьми, я даже упаковываю PowerShell для NixOS прямо сейчас, чтобы использовать его для всего.

Учтите, что наши целевые пользователи - это не только пользователи Unix, которые случайно используют Windows + PowerShell, но и пользователи Windows, которые случайно используют Unix + PowerShell;)

Одиночный символ (например, ^), который автоматически попадает в собственный PATH

Я также предпочел бы, чтобы псевдонимы были совместимы с ОС, когда они действительны на этих платформах, и использовать escape-символ (например, ^ls ), чтобы получить неявный доступ к собственным командам, как предлагает @joeyaiello
Я не знаком со всей философией PowersShell, но что может быть плохого в таком подходе?

Собственно, еще один момент для использования односимвольного экранирования: bash уже делает это. https://twitter.com/climagic/status/806536501232340992

\ls игнорирует все псевдонимы.

Решается ли ответ на псевдонимы включением WSL (подсистема Windows для Linux)? Это предоставит встроенные команды sed, awk, ls и т.д. в оболочке bash.

Хотя это все еще бета-код для Windows 10, он наверняка появится и станет доступным в Server 2016 и 2012.

@Liturgist В настоящее время WSL - это очень отдельная среда от PowerShell. Команды нельзя вызывать из сеанса PowerShell. Кроме того, многие текущие пользователи Windows PowerShell, вероятно, сочтут это регрессом, поскольку многие сценарии сломаются, если получат вывод, скажем, от GNU ls а не от ls -> Get-ChildItem . Хотя использование псевдонимов никогда не рекомендовалось в сценариях, факт остается фактом: они использовались, и их поломка может вызвать трудности у многих людей.

@Liturgist : @bgshacklett прямо здесь. Проблема не в том, что что- ls , вопрос в том, какие параметры вы ожидаете при их использовании, и является ли выводимый результат потребляемым объектно-ориентированным способом другими командлетами PowerShell (например, ls | Where-Object Name -like *foo* не будет работать, если вы используете WSL ls ).

Первоначальная проблема с конфликтующими псевдонимами с собственными cmds была решена. Если необходимо иметь возможность добавлять популярные псевдонимы Windows PowerShell, это должно быть отдельной проблемой.

Открыл https://github.com/PowerShell/PowerShell/issues/3610, чтобы зафиксировать вторичную проблему.