Как стать автором
Обновить

Комментарии 45

Пусть они сначала научат PowerShell хотя бы работать с какой-то адекватной скоростью, а не так как сейчас. Эти две строчки:
powershell -NoProfile "(Get-ChildItem -LiteralPath '%outp%').CreationTime = (Get-ChildItem -LiteralPath '%inp%').CreationTime"

powershell -NoProfile "(Get-ChildItem -LiteralPath '%outp%').LastWriteTime = (Get-ChildItem -LiteralPath '%inp%').LastWriteTime"

всего лишь копируют дату/время создания с одного файла на другой. Процесс занимает порядка 4 секунд. На 4,3 ггц процессоре с достаточным объемом свободной памяти и ssd диском.
И да, там есть разные танцы с бубном (вот эти вот "-NoProfile" в командах, например), которые позволяют время несколько сократить, раза в 2. Но это все равно адски много для столь простой операции.

Так что нет, за CMD — будущее
В большинстве случаев, работа в командной строке — это не программирование. Простые вещи выполнял всю жизнь в cmd. А с этими конструкциями в PS без пива не разберёшься.
Ну мне лень было программу писать, чтобы эту операцию переноса дат с файла на файл делать. А встроенной в cmd команды для работы с датами или хотя бы какой-то консольной утилиты в винде до сих пор нет. Пришлось вот на PS извращаться. Причем меня поразило даже не то, что команды для PS круче кода на Haskell'е, а то, что в 2020 году они ТОРМОЗЯТ!

Ну и да — PS явно под синтетическими наркотиками делали…

МС последнее время вообще считает, что если народ так любит командную строку — надо туда команды подлиннее запихнуть. Они всё так же не интуитивны, догадаться, какой параметр будет, не гугля — почти невозможно, при этом любой процесс описывается тремя-четырьмя последовательными командами с этими длиннющими параметрами. Достаточно хотя бы посмотреть, как прописывается через консоль загрузчик на нужный раздел и добавляется в меню выбора при загрузке. Зачем это все так извращённо сделано — я до сих пор понять не могу. Как-будто в МС засели любители юниксов, но самую важную часть про короткие консольные команды им в детстве никто не рассказал…
Немного оффтоп, в bash тоже не все гладко, это и замысловатые конструкций if, case/esac, работа с массивами… Для себя выбрал nodejs, если что-то выходит за адекватные границы для команд, в самом деле, ощущение, что обкуренные программисты все это писали
Эм, что не интуитивно в if/case в баше? Там все весьма очевидно и понятно.
Они всё так же не интуитивны, догадаться, какой параметр будет, не гугля — почти невозможно

JFYI


Имя-Команды -?
help *ключевое_слово*

Как-будто в МС засели любители юниксов, но самую важную часть про короткие консольные команды им в детстве никто не рассказал…

Get-Alias
Ну-ну. Что help, что Get-Alias в современных консольных утилитах от МС — это мёртвому припарки, проблема не в длине команд (это фигово, но с этим можно жить). Проблема в том, что для ЛЮБОЙ операции надо отдавать десятки этих длинных команд, последовательно. И вот в этом и жесть.

Ну вот, например, зацените по ссылке инструкцию. Начните с подраздела «Пересоздание BCD файла загрузчика Windows 10».

И вот просто прикиньте, как вы ВОТ ЭТО будете делать используя только встроенную в утилиты справку -help. Без гугла, ага. Это просто нереально, даже если бы справка выдавалась развернутая, а не в одно предложение.

P.S.: чтобы было понятнее, о чем я — во времена WinXP эти действия выполнялись ОДНОЙ командой и редактированием .ini-файла в блокноте. А не вот этой вот жестью в 13 последовательных вызовов одной и той же утилиты с разными параметрами

Я не вижу там вообще powershell

Ну мы же вроде бы переключились на обсуждение, что длинные команды — плохо, но можно обойти?

Ну а про PowerShell если говорить, то каким-таким способом без гугла я бы смог добраться до конструкции (Get-ChildItem -LiteralPath '%outp%').CreationTime?

Ну т.е. вот возьмем cmd: большая часть команд или встроенная, или — внешние утилиты, которым дофига лет уже. Все эти команды — выдают вполне доступные справки, большая часть из них делают ВСЕ нужные операции в одном вызове. Современное решение от МС: узнать какие команды есть — можно встроенной справкой, которая никак не объясняет, зачем эти команды нужны. Справка по каждой конкретной команде так же никак не помогает понять что это и зачем. Половина параметров или без справки или изначально — составная часть других параметров и применяется только совместно. Встроенной справки на соотв. сочетания параметров — нет. Любая полезная инфа — только гуглится, т.к. справка на сайте МС в общем случае примерно так же полезна, как и встроенная.

В общем, использовать это всё «очень удобно».

А как вы без гугла добрались бы до команды dir?
Можно help Get-* узнать все команды которые что, что получают
Про параметры есть справка (наберите help dir или dir -?)


Или intellisence.


Свойства есть в intellisense или ls | gm


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


А сейчас есть powershell_ise с intellisense и справка в которой есть поиск и способ изучить структуру выхлопа при помощи gm

Если запустить CMD и набрать там help, то он, в общем-то все команды там перечисляет. Если я правильно помню, то вообще это так работало еще со времен ms-dos.

Ну вот вам самому не кажется, что наличие intellisense в PS — это как бы сами разработчики расписались в том, что они сделали настолько плохо, что без подсказок с этим уже как бы и нельзя нормально работать?

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

Я честно не представляю человека, который в это вот всё полезет добровольно. Искренне жалко профессиональных сисадминов, которым с этим приходится жить и работать.
Ну вот вам самому не кажется, что наличие intellisense в PS — это как бы сами разработчики расписались в том, что они сделали настолько плохо, что без подсказок с этим уже как бы и нельзя нормально работать?

Нет. Просто с подсказками удобнее чем без подсказок.


Я честно не представляю человека, который в это вот всё полезет добровольно.

Он удобнее чем CMD только тормознее.

Проблема в том, что для ЛЮБОЙ операции надо отдавать десятки этих длинных команд, последовательно.
Ну, во-первых, это неправда — множество операций выполняется куда меньшим количеством команд, а, во-вторых, можно подумать, в линуксах вы без гугла или обширного опыта последовательность команд для увеличения размера диска отгадаете.

даже если бы справка выдавалась развернутая
Используйте help с ключом -detailed
НЛО прилетело и опубликовало эту надпись здесь

Ага, 4 сек выполнения к минуте набора команд со всеми этими -getCloserDateToDateOfFolderCreationIfItNotAThursday
Как это вообще можно запомнить?


«PowerShell — это будущее», — добавил он.

А я-то думал что в терминаторе самое ужасное будущее...

Нет насущной необходимости прям запоминать. Если ты знаешь, как конструируется имя командлета, ты и сам его в уме можешь предположить и дальше уточнить через get-command.
В линуксовом cli каждый, кто создавал какой-либо бинарник, придумывал имя, такое ощущение, с единственной целью — быть непохожим на других. Тут только запоминать либо гуглить. Даже man -k не всегда спасает.

Падажжи. То есть ты серьёзно хочешь всю эту объектную модель powershell'а (которая будет работать в однострочниках, без всяких доп. команд импорта), но при этом на каждой итерации запускаешь отдельный инстанс powershell, и считаешь, в общем-то время запуска инстанса, а не исполнения конечной команды?

Ну, во-первых, bat-файл тоже запускает новый инстанс cmd. Это ему совершенно не мешает работать быстро. Даже если он использует внешние консольные утилиты, а не (уже) встроенные, типа date, attr и т.п.

А во вторых, нужную мне задачу не получилось реализовать в рамках одной команды, не смотря на всю эту объектную модель. Что, кстати, тоже хорошо показывает качество разработки этого самого PS.

Ну и в третьих, сам cmd запускается мгновенно, а ps — минимум за 2 секунды. Когда я гуглил в попытках как-то это всё ускорить до разумного времени, выяснилось забавное: в целом скорость запуска PS колеблется от 1,5 до 8 секунд. Причем скорость на разных компьютерах — разная, как повезет. В некоторых случаях можно применить разные шаманские пляски и/или ngen, чтобы ускорить процесс. Но это все равно 1,5 секунды на старт — минимум. А cmd — мгновенно. И я выберу cmd, при прочих равных.

Upd: ну и да, я в упор не понимаю, зачем тащить ВСЮ объектную модель и ссылки на внешние сборки в скрипт, который не будет их использовать. Почему оно использует аж 32 мб оперативки если я хочу, например, посмотреть текущую дату в консоли? При этом оно еще проверяет права доступа, учитывает профиль под которым запущено и еще миллион приседаний — и все это, чтобы вывести мне дату по запросу. Ага.
Почему бы это всё не подгружать по мере необходимости-то? Зачем тащить сразу и всё в процесс, если оно там в большом количестве сценариев никогда не будет использоваться?

core i7 2.8ghz, SSD, оперативы предостаточно, при этом прямо сейчас куча всего запущена, но увидев цифры я даже не стал заморачиваться с закрытием.


Схожий с вашим кусок кода
Measure-Command { 
    powershell -NoProfile "(Get-ChildItem -LiteralPath 'file.txt').CreationTime = (Get-ChildItem -LiteralPath 'file2.txt').CreationTime"
}

Measure-Command { 
    (Get-ChildItem -LiteralPath 'file.txt').CreationTime = (Get-ChildItem -LiteralPath 'file2.txt').CreationTime
}

Вывод:


PS D:\Dev\> .\test.ps1

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 267
Ticks             : 2673650
TotalDays         : 3.09450231481481E-06
TotalHours        : 7.42680555555556E-05
TotalMinutes      : 0.00445608333333333
TotalSeconds      : 0.267365
TotalMilliseconds : 267.365

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 11
Ticks             : 114739
TotalDays         : 1.32799768518519E-07
TotalHours        : 3.18719444444444E-06
TotalMinutes      : 0.000191231666666667
TotalMilliseconds : 11.4739

Или вот ещё
Measure-Command { 
    powershell -NoProfile "Write-Host 'Hello'"
}

Measure-Command { 
    Write-Host 'Hello'
}

Вывод:


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 309
Ticks             : 3095771
TotalDays         : 3.58306828703704E-06
TotalHours        : 8.59936388888889E-05
TotalMinutes      : 0.00515961833333333
TotalSeconds      : 0.3095771
TotalMilliseconds : 309.5771

Hello
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 17
Ticks             : 178523
TotalDays         : 2.06623842592593E-07
TotalHours        : 4.95897222222222E-06
TotalMinutes      : 0.000297538333333333
TotalSeconds      : 0.0178523
TotalMilliseconds : 17.8523

Всё ещё не понимаю о каких 1.5 — 8 сек речь.


ну и да, я в упор не понимаю, зачем тащить ВСЮ объектную модель и ссылки на внешние сборки в скрипт, который не будет их использовать

Не "ВСЮ". И для того, чтобы ваш скрипт смог оставаться однострочным для простейших системных операций и структур данных, и не содержал в себе кучу импортов. Сторонние модули / сборки вы всё ещё способны подгрузить когда нужно.
По такой логике можно было бы в скорость работы скрипта ещё и приплюсовать время загрузки винды, ведь без неё powershell не работает.


Конкретно по вашей ситуации — можно же написать цикл на том же powershell, передавая в обрабатывающий скрипт собранный результирующий список файлов (пайпом, или промежуточной выгрузкой в файл)

Ну я писал выше — скорость сильно зависит от внешних к PowerShell'у причин. Т.е. проблемы чаще в винде, чем в PS. Однако, если вы таки погуглите, то увидите, что вопрос времени старта PS — очень актуальный и народ постоянно с этим сталкивается, как только дело доходит до массовой обработки чего-либо, а не единичного вызова.

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

PS тормозит по простой причине — она на C#.

Но далеко не все приложения на C# тормозят!

Тут имеется ввиду время старта.

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

Просто PS занимается кучей вещей на старте. Знаете, почем в моем примере команд "-NoProfile" написано? Потому что иначе PS подгружает инстанс того профиля под которым запускается, с соответствующими проверками на безопасность, права доступа и все остальные приседания, что и занимает минимум 2 сек на неслабом железе. И это только малая часть того, что там на старте происходит, достаточно погуглить как люди с проблемой задержек на старте борются. Это, наверное, вообще топовая тема вокруг PS — и C# тут, в общем-то, ни при чем.

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

Иногда скорость не имеет ни малейшего значения. В моём случае главным плюсом оказалась глубокая интеграция с остальными продуктами Microsoft и office в частности. Да, работает медленно, чуть ли не по секунде на заполнение каждой ячейки данными, но я просто запускаю скрипт и он делает всю ежедневную рутину за меня, освобождая меня от ручного переноса кучи данных из проприетарной программы в таблицы отчёта. CMD этого не может. Есть куча других инструментов, которые помогут сделать это быстрее, но PS уже есть на каждом компьютере нашей сети и не надо ничего устанавливать/настраивать.


Вам никто не запрещает использовать и дальше cmd, но я его не запускал уже очень давно.

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

Не хочу вас расстраивать, но в этот раз вы неправы примерно во всём: posh в разы экономит моё время (потому что иначе - вручную), электричество у нас вообще халявное (своя ГТЭС на попутном нефтяном газе, который всё равно сжигать) и нервы тоже экономит, потому как это posh нервничает, а я в это время пью чай и залипаю в телефоне.

Варианта кодить не на posh нет. Ничего нестандартного для windows безопасники не пропускают.

Просто это как пилить дрова лобзиком. Вроде бы и можно, но кпд… Я в итоге нужные мне задачи просто на C# решать стал, вместо PS. Потому что я не готов ждать по 4 секунды, пока оно запустится, чтобы выполнить операцию, которая должна работать за наносекунды.

Т.е. получается, что PowerShell будет проходить всё то, что сейчас делает десятка? Постоянные апдейты, патчи, патчи патчей — то, о чём сейчас выходят все новости про Windows. О стабильности можно будет забыть? Так это вроде главная фишка винды была долгое время, из-за которой те же игры на неё выпускать было проще.
В Linux примерно та же ситуация, еженедельный apt-get update\upgrade приносит много нового. И уж лучше так, чем годами сидеть в застое с одними и теми же багами см. VBA
при этом шелл в Линукс обратно совместим и не страдает нестабильностью десятки лет
В основном обновляется несистемный софт и изредка ядро и какие-то важные библиотеки. При этом можно в любой момент откатиться на предыдущее ядро, если вдруг что-то перестало работать.

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

тут скорее смотря для чего используете. Если ты администратор зоопарка win-машинок, и тебе нужно писать скрипты, трогающие самые дебри windows, то да, powershell это твой инструмент. Опять же, тут он не является заменой cmd т.к. для этого cmd не подходит.

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

Зависит от разработчика. Для .NET разработчика posh очень удобен тем, что можно использовать свои знания и инструменты там — весь фреймворк нативно доступен.


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

Powershell слишком раздутый. Ей богу лучше бы Lua встроили или что-то похожее.
просто сложные вещи на PowerShell делать не будешь, а для простых должны быть простые инструменты.

У вас мало опыта с posh, предположу. Он вроде годится и для простых и для сложных вещей. Просто другая идеология использования, чем в том же bash.

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

Зато эти команды не обязательно зубрить, как в bash.

а в баше надо зубрить? и в pwsh все само пишется? с завтрашнего дня перехожу на pwsh

CMD использовался как оригинальный интерпретатор командной строки по умолчанию в эпоху линейки ОС Windows NT в 90-е гг

Разве не в эпоху всей линейки MS продуктов включая windows 3, и ДОС?

А хотя, в дос был command.com… но в винде cmd был еще до НТ
До NT, если мне не изменяют память и понимание, он назывался «Сеанс MS-DOS», и предоставлял интерфейс к тому же самому command.com, просто следующей, седьмой версии.
А cmd — это вроде бы уже нтшное приложение.
Хм, а я bash-эм WSL пользуюсь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости