Вот читаю я вашу «санту барбару» и понимаю что чего-то не хватает в аргументации Zmicier.
Надеюсь вы согласны что shell это все-таки не для рядовых пользователей а для админов.
Я в чем-то согласен с вашей аргументацией (насчет типизации и т.д), и также согласен с «больше и разных» но:
1.
Команды *nix знают и используют много лет. Это в плюс стандартному шелу, потому что я могу (с небольшими изменениями в зависимости от платформы) выполнить свою задачу быстро.
Например в случае аварийной ситуации я могу взять почти любой дистр linux (какой под руку попадется хоть 10 летней давности) загрузиться с него и провести необходимые действия.
2.
В минус сабжа, длинные команды. Про алиасы тут уже писали, я в курсе. Но вот ситуация сильно не стабильный/под-ддос канал где на набор/отображение нескольких буковок уходит большое время, я же не смогу там алиасы прописать, а набирать длинный текст просто не получиться потому что связь рвется (это я реальные ситуации описал).
3.
Теперь рассмотрим сроки жизни. Сколько лет никс командам и сколько за это время же m$ похоронило своих же разработок? Явно перевес не в пользу сабжа. Вот вы верите что через 20 лет сабж будет жив и в том же виде? Я нет.
4.
Минималистичность, об этом тут уже много писали, сколько ест (места и памяти) ваш «многослойный бутерброт» и сколько аналог с использованием стандарных никс средств? Тоже же в копилку минусов сабжа.
Итого: админ знающий только пс не сможет выполнить свои задачи на разнородной среде, а это и значит платформо зависимый админ, каким он сейчас и является.

1. Coreutils никто не мешает использовать из PS

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

3. Ничего по этому поводу сказать не могу сказать, но PowerShell уже 10 лет, с момента его выпуска он кардинально не менялся - добавлялись новые модули в стандартной поставке, добавлялись новые возможности синтаксиса, расширялись существующие модули, кроме того его под MIT лицензией выпустили, вроде она не мешает сделать свой форк?

4. Да, в этом плане PS проигрывает, так как он требует .NET для работы (так как его объектная система на .NET). Там где память настолько ограничена это недостаток.

Про итог: админ знающий только один шелл и не умеющий ничего больше и так и так будет страдать.

Ну и в ответ DonkeyHot. Скобки там потому, что GetType() - это не команда PowerShell а встроенный метод System.Object в .NET, я его использовал, чтобы показать, что $f - не System.String. В реальной ситуации его использовать не будешь никогда. По поводу магии - это не какая-то особая магия PowerShell, все эти форматы описаны в Format.ps1xml файлах, можно почитать в Get-Help about_Format как это все настраивается. Там задаются вьюшки для разных типов. Для файлов и директорий, например, описания в FileSystem.Format.ps1xml. При выводе на терминал используются эти вьюшки (которые как раз выводят таблицу), при вставке в строку используется ToString() метод, который для файлов просто отдает FullName. Я этот пример показал вообще к тому, что ты утверждал как неудобно будет писать с объектами, а теперь жалуешься на магию. Пример я просил привести так как сам я не могу представить ситуацию, где PS был бы менее удобен, а теперь ты просишь привести тебе пример в поддержку твоего аргумента? От тебя пока что вижу только недостаток в гипотетической ситуации, для которой ты не можешь привести пример.

Вот тебе пример, худшая вариант, который я могу придумать, где из-за объектов аж целых 2 символа надо добавить - $f.zip vs "$f.zip", тк . вне строки - оператор доступа к члену. Однако это более чем компенсируется тем, что больше не нужно использовать сотни разных скобок, когда нужно работать с чем-то отличным от текста (логические выражения, числа)

2. Можно все алиасы прописать в профиль, не обязательно же их каждый раз набирать.

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

Ну и жаловаться на длину команд, когда у того же systemd чуть ли не длиннее - лицемерие.

Эммм теплое с синим не путайте. Мы вроде как о шеле, а не о системе инициализации говорим.

Про итог: админ знающий только один шелл и не умеющий ничего больше и так и так будет страдать.

Пишу по своей практике, я не знаю сабж, но использую (скорее использовал) cygwin на офтопике. Но не наоборот.
Поймите правильно. Я не пытаюсь хэйтить сабж. Уже написал «больше и разных». Однако как программист понимаю что чем многослойнее бутерброд тем больше падение производительности и вероятности ошибки на каком-то слое. Для примера тот же sed, многим кажется совсем наркоманская вещь, однако поточность является его большим плюсом в части производительности.

Ну тут и с утилитами ситуация может оказаться аналогичная - придется вводить супердлинную команду. А про длинные команды в systemd я упомянул потому, что в большинстве шеллов команды = утилиты, без coreutils шелл вообще почти ничего не может, и команды настолько длинные, насколько длинно имя утилиты и её параметров. В PowerShell команды не обязательно являются утилитами.

Ну и я в принципе ничего не имею против этих аргументов, особенно против 4го, по крайней мере это реальные аргументы, а не гипотетическое «объекты мешают, но привести пример не могу». Просто 1 относится вообще в принципе к любой новой технологии, 2 верно лишь потому, что в PowerShell принятое именование параметров и команд такое, но с этим хотя бы автодополнение, сокращения и алиасы помогают, а в классических шеллах длина команд зависит лишь от прихоти авторов утилит.

а в классических шеллах длина команд зависит лишь от прихоти авторов утилит

Добалю только про это. Короткие команды и аргументы изначально появились не «от прихоти авторов» и чсх до сих пор для администрирования является благом не смотря на «высокие скорости».
В остальном мы вроде друг друга поняли.

в большинстве шеллов команды = утилиты, без coreutils шелл вообще почти ничего не может, и команды настолько длинные, насколько длинно имя утилиты и её параметров. В PowerShell команды не обязательно являются утилитами.

Фигасе умник нашёлся. Если команда cp стронняя утилита, то cd это вшитая в bash, программа. То же самое с PowerShell, её команды — это вшитые программы. В bash-е нет ничего лишнего, он самодостаточен именно в союзе со стандартными утилитами.

Это было написано не в упрек, это просто факт. Ничего плохого в этом нет.

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

при вставке в строку используется ToString() метод, который для файлов просто отдает FullName

Выше в 2х примерах vlc $f получал полный путь, cp ...$dest/.$_ - короткий. Ты видишь разницу в тексте? Я нет, отчего заключаю, что там либо магия либо телепатия, и то и другое в шеле хорошо, но необычно.

ситуацию, где PS был бы менее удобен

Я не утверждал, что PS менее удобен. Я говорил о полезности структурированных данных. Мне привели кучу аргументов, что в ПС это не мешает. Ну и ладно. Если ПС умудряется спрятать внутренности от пользователей - это не означает, что эти внутренности сколько-нибудь существенно полезны. Т.е. я бы сказал, что они полезны, но менее чем вредна неоднозначность или сложность преобразования из-в человеков.

Разница между пошем и башем в том, что в баше у тебя всегда «нишмогла» и никаких других вариантов нет.

В качестве тролинга (но не совсем): Вот когда появятся «тетрисы», «шахматы» и т.п. на сабже тогда и поговорим :)

на поше вообще пишут вполне полноценный софт с уи

Зависит от источника объекта FileInfo. Обычно это полный путь к файлу (при вызове конструктора). Однако при получении через функции типа GetFiles, например, это вроде путь относительно директории в которой перечисляются файлы. В моем коде ls (Get-ChildItem в PowerShell) при передаче имени конкретного файла просто напрямую дергает конструктор FileInfo с полным именем файла. В коде другого анонимуса используется ls -file, который получает все файлы в директории при помощи вроде бы EnumerateFiles, поэтому там короткое имя.

Вот нашел на MSDN - https://msdn.microsoft.com/en-us/library/system.io.fileinfo.tostring(v=vs.110...

Защитникам Майкрософта и продвигателям PowerShell

Ребята, вы понимаете абсурд всей этой ситуации. Предлагать лиуксоиду PowerShell, это всё равно, что предлагать иностранцам привыкшим ездить на Мерседесах, Ладу.

В Виндоуз все админы это щелкатели мышью, изредка запускают Командную строку чтобы написать бат-файл. Та же самая ситуация творится с Макосью. «Корпорация Зла» и «Яблоко» сначала времён приучали своих пользователей и аминов к графике. Вот и приехали!

бедняжка...

Ну так давайте примеры, а то 4.2 будет :)

Нет никакого смысла в этом повершелле. Лучше уж ipython в качестве шелла юзать, если функциональность нужна.

В Виндоуз все админы это щелкатели мышью, изредка запускают Командную строку чтобы написать бат-файл. Та же самая ситуация творится с Макосью. «Корпорация Зла» и «Яблоко» сначала времён приучали своих пользователей и аминов к графике. Вот и приехали!

Ты жертва стереотипов.

По моим наблюдениям, анон только чуть-чуть не прав, не " все админы это щелкатели мышью" а 99,9% из них :)

PowerShell-ом можно делать в венде вообще всё, что можно делать мышкой. Это серьёзный объём работы — выставить единообразные программные интерфейсы для всего. Для 0,1% эту работу не стали бы делать.

Тебя в гугле забанили?

Зависит от источника объекта FileInfo...

O! Начинается :)

Особый жесткач заключается в том, что под венду теперь делать трояны и малварь которая не палится антивирусами и подобным легко и приятно :]

Но в целом да, под виндовс альтернатив нет.

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

зависимый админ

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

в 10 скрипты отключены по дефолту, не знаю как в 8 было, скорее всего неподписанные отключены

Смотря что понимать под словом «отключены»

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

https://www.youtube.com/watch?v=xyB9yEw1gdE

Окэ, а теперь вопрос знатокам, эта же фигня на онтопике также будет работать?

Винформс там вроде есть, так что по идее должно. Хотя надо проверять, конечно.

так что по идее должно

1. По идеее... а как на деле хз.
2. Я изначально писал про консольные варианты, а не gui (тут уж простите, сразу надо было написать, моя вина)
Итого: «Шахматы и тетрис» на винде работают, а обратного мы пока увидеть не можем.

2. Я изначально писал про консольные варианты, а не gui

Есть и консольные

В NET Core нет пространства System.Windows(и не будет по понятным причинам) так что из PS их дергать нельзя.

В моно есть. Почти уверен, что его можно заставить работать на моно.

Продолжение, только что пришлось набрать команду «ifconfig | grep -E '(tun|ppp)'» это я сделал «не приходя в сознание», как оно на пс будет интересно?

1. Coreutils никто не мешает использовать из PS

стандартные алиасы мешают. т.е. вместо ls надо набирать /bin/ls или ls.exe. или удалить нафиг эти алиасы. кстати, эпичный срач с автором curl по поводу этих алиасов: https://github.com/PowerShell/PowerShell/pull/1901

также, только sls вместо grep. А можно и с грепом, тоже будет работать.

Стандартные алиасы только в виндовой версии PowerShell. Уже несколько раз, даже в этой теме писали. Хоть почитай, что пишут по ссылке, которую даешь.

По теме: годно, нужно, но только вместе с эквивалентом coreutils/util-linux в стандартной библиотеке.

Такие люди как ты, уничтожат линукс.

Нееет. Тут же про «объекты» говорят. Вот мне и интересно, как тоже самое, но в объектной моделе будет выглядеть?

Как сделаешь, так и будет. А в чем ты видишь тут проблему?

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

Как-то так вероятно Get-NetIPAddress | % поле -in значение1,значение2.

Get-NetIPAddress

Пара вопросов:
1. А оно возвращает название интерфейсов? Просто по названию не очевидно.
2. Опять конвейер получается, а хотелось что-то типа объектного доступа, о чем здесь много говорили.

2. Опять конвейер получается, а хотелось что-то типа объектного доступа, о чем здесь много говорили.

Так конвеер объектный, а не текстовый

1. А оно возвращает название интерфейсов?

Оно возвращает весь объект, со всей информацией, которая есть. Наверное, в этом объекте будет название интерфейса (иначе было бы очень странно).

Ясно. спс. за пояснения.

Net TCP/IP Cmdlets in Windows PowerShell https://technet.microsoft.com/en-us/library/hh826123.aspx

А вот это «очень удобно» Get-NetIPAddress –InterfaceIndex 12 по сравнению с ifconfig | grep -E '(tun|ppp)'
Что это там за цифра 12 я еще и выяснить заранее должен?
Мне нужно было узнать что поднялись все ppp и tun интерфейсы. Визуально увидеть, не более того. Это вот то, о чем пытался здесь сказать DonkeyHot, просто увидеть выхлоп, но вы так и не поняли его.

Что это там за цифра 12 я еще и выяснить заранее должен?

Ну то, что через tun/ppp можно грепнуть выхлоп ifconfiga ты же знаешь? А это сложнее.

Да, я знаю что у меня два ppp и два tun должны быть подняты, (заметьте я пишу без цифирок потому что не помню какие им номера выдаю) а тут какая-то цифирка 12 и все.