Pull to refresh

Comments 24

сейчас доля Windows составляет 14,7%, а доля Unix-подобных систем — 85,6%

Вместе больше 100%??

Та не, просто на некоторых серверах сразу две системы стоит

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

То-то макросы и скрипты есть буквально во всём: текстовых редакторах, видеомонтажках, звуковых редакторах, графических - достаточно вспомнить Actions в Photoshop. И речь не просто о горячих клавишах. Хотя, есть и программы, позволяющие последовательности нажатий клавиш записывать и повторять.

Создал Windows Powershell а потом Powershell 7 которые между собой не совсем совместимы.

Полюс версии Windows Powershell между собой не очень совместимы, как всегда MA в лучших традициях….

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

Это как с file link, вроде добавили, но пользоваться нормально нельзя. Что-то Linux подобное только в development mode можно включить.

Сей час залез в wiki, очень порадовало:

Powershell cmdlet : Test-Connection

Alias: ping

Windows command prompt: ping

Linux: ping

Кто этот гений, который для простой, де-факто стандартной команды: ping придумал имя Test-Connection?

Интересно, есть статистика, кто Test-Connection пишет вместо ping?

Дак там же (в Повершелле) под капотом Дотнет, насколько я помню. Оттуда и дотнетоподобные названия команд.

Там есть идея начинать команды с глагола из одобренного списка ради унификации, но обычно аз-за алиасов это проблем не вызывает ("Alias: ping" - откуда это? Ни в wiki, ни в 7.2 нет).

Гениев надо искать другим образом.

  • Powershell до последнего времени не умел передавать через пайпы двоичные данные. Объекты внутри Powershell - нормально, текст и нативные приложения - нормально, двоичные данные и нативные предложения - нельзя, они парсятся как текст, ломаются и это не отключалось первые 17-18 лет. Решение - вызывать cmd.exe /с и использовать пайпы в нём.

  • Powershell при вызове нативных приложений автоматически парсит аргументы, чтобы их можно было записывать как в обычном шелле (а не массивом строк), но отдельно доступа к парсеру не даёт. ./metaflac --show-bps --show-md5sum "some name.flac" - да, но если аргументы лежат в переменной-строке, то никак нет, распарсить в массив строк надо как-нибудь самостоятельно. С помощью вызова cmd.exe, например.

  • Команды по умолчанию принимают пути с wildcard'ами. * и ? в Windows и так нельзя использовать в именах файлов, так в чём же проблема? А к ним добавили [ и ]. Проблема решается специальным параметром -LiteralPath (-lit) вместо [-Path], но его повсюду добавлять утомительно, поэтому во все команды его решили и не добавлять...

  • И так далее. Powershell то гениален, то гениально туповат. Неизбежное "разворачивание" массива из 1 объекта в объект. Театр безопасности с запретом запуска двойным кликом или перетаскиванием, что решается опять не без помощи cmd.exe, подобными файлами-химерами:

<# : batch part begin
@echo off & pwsh -c "cat '%~f0' | Out-String | Invoke-Expression" & pause & exit /b
batch part end #>

# powershell code...

передавать через пайпы двоичные данные

Потому что Windows PowerShell делался для администрирования Windows, а там такое нужно супер-редко: за 15 лет мне ни разу такое не понадобилось.

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

Скажите, пожалуйста, в каком сценарии такое требуется? Тот пост на SO не даёт контекста зачем топикстартеру это нужно.

Потому что Windows PowerShell делался для администрирования Windows, а там такое нужно супер-редко: за 15 лет мне ни разу такое не понадобилось.

Зато парсить вывод утилиты самостоятельно (из-за того что она пишет в своей особенно кодировке) нужно супер часто, а нельзя.

Скажите, пожалуйста, в каком сценарии такое требуется? Тот пост на SO не даёт контекста зачем топикстартеру это нужно.

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

Потому что если ошибочно прочитать поток байт как текст в кодировке UTF-8 - то восстановить исходный поток байт уже не получится.

Всё-таки он уже 8 лет кроссплатформенный и на роль всесторонней замены cmd.exe его метили изначально.

Mozjpeg'овский jpegtran, например, имеет вывод только в stdout, в Powershell перенаправление двоичного потока в файл тоже сломано в рамках этой багофичи.

Скажите, пожалуйста, в каком сценарии такое требуется?

Когда строка аргументов уже есть*, или когда её нужно сильно менять. В некоторых программах строка аргументов плавно перетекает в целый скриптовый язык, как в imagemagick, нужна гибкость хотя бы на уровне батников.

* Выше можно дописать @echo off & set "bat_args=%*" & pwsh... и получить доступ из Powershell-части так:$env:bat_args (это будет сырая строка, которую надо парсить).

Mozjpeg'овский jpegtran, например, имеет вывод только в stdout

оо интересно, спасибо

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

Powershell при вызове нативных приложений автоматически парсит аргументы, чтобы их можно было записывать как в обычном шелле (а не массивом строк), но отдельно доступа к парсеру не даёт

Есть же Invoke-Expression, вы его даже использовали ниже

Неизбежное "разворачивание" массива из 1 объекта в объект.

Есть такое, "контрится" через Array subexpression operator, который @()

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

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

Что-то сложное у вас написано. зачем тут вообще Invoke-Expression?

pwsh -file "%~f0" -executionpolicy bypass

Что-то сложное у вас написано. зачем тут вообще Invoke-Expression?

Проще не выйдет, потому что cmd.exe и Powershell щепетильно относятся к расширениям. Файл должен иметь расширение .bat или .cmd, чтобы его выполнял cmd.exe. Но чтобы сработал pwsh -File, нужно расширение .ps1. Не обойтись без временного файла с правильным расширением (.ps1) или "eval" файла как строки.

Есть такое, "контрится" через Array subexpression operator, который @()

В одних случаях через @() , в других через ,(). Если если вместо первого по ошибке использовать второе, то вместо пустого массива можно получить массив с одним $null. Если наоборот, то где-то вместо двухмерного массива может получиться одномерный. В третьих случаях через -NoEnumerate, в четвёртых лучше заранее смириться. Для отладки полезен вывод ConvertTo-Json $obj.

Не знаю, возврат массива из одного элемента мог бы оказаться меньшей проблемой - выручала бы фича member-access enumeration, когда обращение отсутствующему члену массива разворачивается в обращение к членам всех элементов: @('abc','def').ToUpper() (у массива нет методаToUpper() , поэтому метод вызовется у каждого элемента массива).

Есть же Invoke-Expression, вы его даже использовали ниже

У eval есть известные недостатки, иногда его стоит избегать... и нелепым образом как-нибудь добывать парсер аргументов (самописный / на регулярках / из cmd.exe / изConvertFrom-Csv / из WinAPI CommandLineToArgvW).

Я такое не пишу, конечно. Но пишу sl вместо cd и gci вместо dir.

ping - это встроенная команда в ОС

Test-Connection - PowerShell командлет

Они обладают разными возможностями, отдают результат в разных форматах. Делать алиас ping, значит усложнять доступ к нативной команде. Вон с алиасом wget сколько уже наелись.

Кто этот гений, который для простой, де-факто стандартной команды: ping придумал имя Test-Connection?

Там все команды такие, лично меня уже через 10 минут работы они раздражать перестали (хвала автодополнению)

Создал Windows Powershell а потом Powershell 7 которые между собой не совсем совместимы.

Скрипты/команды Windows PowerShell прекрасно работают в PowerShell (который Core/6/7 etc.). Но в PowerShell добавили новые возможности, которые отсутствуют в Windows PowerShell - вот и всего.

Выглядит очень похоже на краткий пересказ подкаста CORECURSIVE #102 "Navigating Corporate Giants Jeffrey Snover and the Making of PowerShell", но почему-то никакого его упоминания нет. Правильно ли это?

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

Windows Script Host (WSH) поддерживается с середины 90-х. На JS или VBS можно было писать любые скрипты.

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

Sign up to leave a comment.