Обновить
Комментарии 365
Наконец-то нормальный шелл! Прощай, bash!
Почему прощай? Его же запилили в Windows 10. Уверен, будет и в Windows Server 2016.
Рокировочка-многоходовочка.
Такое чувство, что Майкрософт хочет из Windows сделать Linux и из Linux сделать Windows.
Microsoft хочет заманить не .Net разработчиков на свою платформу. Потому что ресурса своих для наполнения стора UWP-приложениями уже недостаточно.
Microsoft хочет заманить всех разработчиков в своё облако и стричь купоны
Не совсем понятно, при чем тут юайный стор к скриптам powershell?
Я говорил про платформу в целом. PS работает на .NET с ней так или иначе сталкиваются разработчики под винду. Вот сейчас можно познакомиться с ним в родном окружении.

Ну и как ниже писали, nugget'ы часто используют PS для развёртки. Так что это нужно для разработки на .NETCore, ASP.Net Core. А там и до разработки для виндового магазина недалеко
Если у вас нету в команде человека, который знает баш — вам конец. Если у вас нету человека, который знает шеллскрипт — он его за полчаса узнает.
Смотря в какой команде. Я вот не знаю баш (хотя и пользуюсь когда вынуждает кривой UI) и как-то живу.
Да, смотря в какой. Но если вы пишите миддлваре или еще что-нибудь. А у вас тонны баш-легаси. То потерять человека — смерть. А если тонны повершелл-легаси, то его выучит любой питонист.
ну, в этом смысле, похоже что да. Баш команды иногда такие, что мозг выносят и маны не помогают :(
Что является мощным таким плюсом в пользу шеллскрипта, не?)
Или в пользу — учи и пиши сложные тулзы на python, а не извращайся с bash, потому что не знаешь python.
У меня довольно давно на эту тему есть конспирологическая теория — в Майкрософт в какой-то момент осознали бесперспективность и бессмысленность дальнейшего развития ядра Windows, и планируют постепенно перетащить свои успешные продукты (desktop, Office, Sql Server, .Net и т.д.) на ядро Linux. Пойти, так сказать, по стопам Эппл.

Раньше все коллеги смеялись в голос, когда я эту мысль вбрасывал, но с каждой следующей подобной новостью смеха всё меньше. :)
Ну не совсем верно, десктопная версия никуда не денется — очень много бизнес-приложений написано под Windows и переделывать их никто не собирается. Другое дело с серверной частью. Есть вполне сформировавшееся ощущение что MS готовит переход к частному облаку как инфраструктуры на базе либо Docker (что вероятнее), либо вообще стека Euqalyptus, где будет совершенно не важно на чем работает нода, Linux или Windows. Скорее всего Серверная часть со всеми сервисами будет постепенно мигрирована на Linux контейнеры, включая такие вещи как AD и Exchange/Lync. Подвижки в этом направлении уже есть. Тем более зная кто сейчас рулит компанией, думаю стратегия угадана примерно правильно.
Так натянуть Win32 на ядро Linux для MS никакой проблемы нет. Как известно, это даже энтузиасты без доступа к исходникам смогли почти полностью сделать.
Так и обратное пилят.
А вы ссылкой не поделитесь? В гугле трешь, угар и содомия одна выходит по такому запросу…
Я уж было подумал что что-то интересное есть… А тут вайн (:
Согласен.
По поводу офисных продуктов — очень надеюсь на выход OneNote для Linux
Я иногда троллил красноглазиков, что если вендекапец и наступит, то ледоколом революции будет Microsoft Linux.
А они в ответ раньше издевались, а теперь бесятся.

Будет проприетарный Microsoft Linux и открытый ReactOS :)

Они хотят зарабатывать деньги. Все остальное — вторично.
Напишите статью про сравнение shell, в том числе, bash и PowerShell, иначе ваше заявление голословно. А то вас плюсуют не за хер собачий.

И заминусуйте меня в пух и прах, но PowerShell в Linux как на корове седло. Осталось за малым, добавить в Linux немного AD'a и системный реестр, чтобы оптимизировать systemd.
Не можете в курсив, да? Это стеб такой, если что :)
Линуксоиды понимают, что это стёб, и плюсуют.
Виндовозники не считывают иронию, и тоже плюсуют.
win-win.
Просто вас задевает тот факт, что майкрософт, которые конкурируют с линуксом, выпускают туда рабочие продкуты. А вы не коммитили ни в один репозиторий, хотя кричите про открытое ПО.
Очень уж толсто, даже для хабра.
PowerShell куда больше, чем просто Shell, это, по-сути, язык. Вы можете писать полноценные приложения, с GUI, на нем, с загрузкой DLL и вызовом функций из них.
Простите, а зачем? Для тех же целей есть гораздо более подходящие языки.
Вполне удобный инструмент для кастомизируемой на полную катушку автоматизации. Можно, конечно и не использовать UI, но подгрузка DLL может выручить.
Уже просто не знают через какую дырку влезть в линукс
Так говорите, будто это что-то плохое.
.NET Core, ASP.NET Core и тёплый, ламповый C# на линуксах, ещё и open sourced — как по мне, одна из лучших штук, случавшихся с Microsoft.
МС очевидно хочет подтолкнуть девелоперов пишущих для линукса, посмотреть и подключиться/переключиться к девелопменту для МС. А хорошо ли это, и кому хорошо — покажет время.
скорее наконец разрешила dotnet разработчикам работать с линукса
Без WPF WCF workflow там много не нагреешься, будь эти лампы хоть горячими…
Всё есть маркетинг
WPF довольно нишевый. Сейчас тренд уходить в веб и облака. Только крупные коробочные продукты нуждаются в standalone desktop приложениях. Workflow тем более. WCF из вашего списка вроде как самый востребованный из всех перечислкенных.

Но хочется надеятся, их потуги в сторону open source не накроются медным тазом, как это с мобилками случилось.
Клиентская часть WCF уже доступна под linux — https://github.com/dotnet/wcf
Серверную часть обещают тоже.
Может вам пригодится https://github.com/Appercode/Appercode.UIFramework
Ввиду того что является обёрткой над нативными контролами бесполезен при наличии живых Xamarin.Forms и eto.Forms
Ну да, писался когда XF ещё не имел своего имени и был закрытым от посторонних проектом :) Сейчас уже все преимущества пали перед последней версией XF. ну, кроме синтаксиса, наверное.
А это был бы реально крутой план. Сначала в этом .deb пакете случайно оказывается телеметрия, котору «забыли выключить». А потом и GWX.
Вы так говорите как будто в той же убунте нет телеметрии по умолчанию
Уже нет. Сообщество кипешь подняло — отключили. С мелкомягкими такой фокус не пройдёт.
Да и потом: на убунте, даже если она данные собирает, можно узнать какие.
В вин. системе хз что течёт, помимо кода и номера моей кредитки. И это, только вершина айсберга.
— А вообще, мне .Net нравиться :)
Вы меня, кончено, извините, но ссылочка-то ваша от 1.04. как бы Fool's Day.
Ок. Я повёлся, довольно правдоподобно было.
В nuget-пакетах постоянно какие-то PowerShell-скрипты используются, да и в процессе билда часто мелькают.

Да, но давольно часто эти пс скрипты лезут в DTE2 :-)

Реализуйте уже это DTE у себя в Xamarin Studio, и старушку MSVS можно будет списывать.

В пользу XS вот вы сейчас серьёзно?

Не совсем так, как вы подумали. Просто я знаю, что Nagg замешан в разработке некоторых компонентов XS, и поэтому его изначальный выпад в сторону DTE2 делался именно с позиций XS.


Ну и давайте начистоту: я сейчас не пользуюсь XS, но считаю, что здравая конкуренция в сфере IDE для C# будет полезна всем — и MSVS, и VS Code, и XS, и Rider. Если они при этом будут совместимы друг с другом в плане работы нугетовых пакетов и проектной системы — я как пользователь IDE от этого выиграю.

Сомнительный выйгрышь, когда 3 из 4х IDE у одной фирмы )

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

Вопрос — а что такое DTE в данном контексте? Гугл не помог.

COM-объект автоматизации Visual Studio

Это просто инструмент. Как TypeScript. Он отдельно денег не приносит. Это как портануть Visual Studio Express или DirectX. +100500 пользователей.
Это как портануть Visual Studio Express или DirectX

Нет, это даже близко не как портануть VSE или DX.
Если портануть VSE и/или DX, то это -100500 пользователей в Windows
Для DirectX есть варианты трансляции в OpenGL и наоборот.
https://github.com/ValveSoftware/ToGL
Более полная поддержка есть в Wine, вплоть до уже запускающихся DX11 игр (поддержка все еще не полная).
Транслировать OpenGL в DX можно через ANGLE
https://github.com/Microsoft/angle
Портировать DX12 большого смысла нет, Vulkan ничуть не хуже (с точки зрения API, не реализации драйвера).
> Более полная поддержка
> поддержка все еще не полная
> назвал набор спецификаций
> ничуть не хуже
> сам в жизни ничего сложнее array.sort() не писал
весь хабр в одном коменте
Более полная чем в ToGL, ну не полная,, если сравнивать с реализацией Windows.а по поводу sort, твои предположение просто
Простая стратегия, рассчитанная на бизнес.
МС показывает, что их продукт(ы) можно использовать везде, и что Linux в Azure — вполне себе такое «рядовое» явление.
Менеджеры не будут вникать в тонкости: они на МС-конференции услышали, что «можно Линукс», и в результате мы имеем зоопарк из PHP, NodeJS, MySQL в Azure.
Правда ежикам, которые потом собирают инфрастуктуру в Azure приходится плакать. Но кого это волнует? Все делают деньги.
Это и про PS, и вообще всю стратегию «MS love Linux».
Но я с трудом представляю себе UNIX/Linux-администратора, который по доброй воле пойдёт в Azure хостить сервера.
Но я с трудом представляю себе UNIX/Linux-администратора, который по доброй воле пойдёт в Azure хостить сервера.

А можно более детально рассказать об этом моменте? Какие там подводные камни для UNIX/Linux-администратора, кроме того, что Azure — это «богомерзкий МС», их цен и разных «религиозных» заморочек.
Основная проблема для меня — не очень хорошая документация на REST API.

Вот сколько у вас времени займет найти, как сделать аналогичное вот этому:
https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-reserved-private-ip/

через REST? :)
Минуты две-три: загуглил как это делает Terraform (признаюсь честно, до этого момента я уже знал о Terraform :) )

Не кажется ли Вам, что
не очень хорошая документация на REST API

как-то слишком мало, что бы обосновать
Но я с трудом представляю себе UNIX/Linux-администратора, который по доброй воле пойдёт в Azure хостить сервера.

?
Маленьким фирмам REST API вообще не нужен, а для больших компаний идеальная документация по приоритету будет стоять, скорее всего, далеко не в начале списка при выборе IaaS-провайдера.
Я не то, чтобы обосновывал (это не я сказал), просто мои 5 копеек. Я вот сам себе маленькая фирма, мне нужен, я автоматизацию делаю. Когда искал, потратил минут 15. Про Terraform не знал :)
Она не просто «не очень хорошая» она местами неверная. библиотеки api для разных языков иногда не поддерживают все сценарии использования, приходится составлять руками полный рест-запрос.
Сценарии использования соответствуют определённому кругу представлений менеджмента облака, шаг вправо-шаг влево — начинается ад.
Попробую. Мнение, конечно, субъективное и вполне допускаю, что в какой-то мере предвзято — никогда не понимал Windows 200{3,8,etc} на серверах.

Я работаю с Azure достаточно плотно где-то c марта месяца, пришёл один проект — и многие инструменты могу использовать неправильно или не знать об их возможностях. Тем не менее — расскажу немного о своём опыте.

Общее впечатление об Azure — это много достаточно хороших и интересных решений. Взять те же Deployment Slots — чрезвычайно удобно.

дальше
Проблемы начинаются, когда приходится строить инфрастуктуру более чем на пару виртуалок. Т.е. — по отдельности продукты неплохие (в целом). Но как только начинается процесс их «вязки» :-) — начинаются и сложности.

Пожалуй, начать стоит с документации. Это, на мой взгляд — самая главная проблема Azure.

Она разнородная, она неупорядочена, она пишется всеми подряд (да, blogs.msdn — это не оф. документация, но именно эти блоги попадают в первых результатах Google). Если для быстрой подсказки по AWS CLI — ответ *всегда* есть в первых 1-3 результатах поисковой выдачи, которые ведут на четкую, внятную, up-to-date и связанную друг с другом документацию, из которой порой можно просто копипастить — то для Azure приходится перебирать несколько страниц Google.

Ещё одна проблема (проблема ли — но тем не менее) — это то, что она написана во многом только под MS-решения. Буквально сегодня я матерился плохими словами, когда мне в Azure WebApp надо было поменять права доступа на файл — и все очень многие нагугленные решения начились слов «Open your Visual Studion and press button N [...]». Сидя под какой-нибудь Ubuntu, когда привыкаешь 90% задач решать/выполнять через консоль — такие «советы» дико бесят, особенно — когда вопрос простой, а на поиски ответа *как* — тратишь непозволительно долгое время.

Кстати, о консоли. Это ещё одна «особенность» Azure, которая дико напрягает. MS пилит решения типа PS под Linux — но сделать *нормальную* консоль в Azure Portal- они не хотят. Нельзя вставить текст. Нельзя переместить курсор по строке. Нет автоподстановки (по TAB), и т.д.

Если уже говорить о Portal — то к нему тоже много «претензий».

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

Смена цветовой схемы по дабл-клику, Карл!

Глюков и проблем при работе с панелью очень много. Зачем было делать «выплывающие» в сторону панельки? Кому это надо? Удобно? Может быть — кому-то, не спорю. Но была ли реальная необходимость в таком усложнении системы? Пусть даже и мелочном, типа каких-то JS-скриптов и что-там-ещё. Но у меня в Chromium под Ubuntu — перетаскивание панелей не работает, приходится использовать горизонтальный скрол. Да, на Mac — всё замечательно. Мне кажется — в погоне за эффектами и красотой — MS (как обычно, просто как обычно) жертвует простотой. Вспомните панельку AWS — никаких лишних плюшек. Всё очень строго, функционально, удобно и, главное — оно просто работает.

Ну и напоследок — это, конечно, глюки самого Azure, как IaaS/SaaS/ИтдS.

Мы деплоим через Git, и это иногда боль. Как-то я потратил целый день из-за того, что деплой в WebApp отваливался с какой-то ошибкой (которая ничего не говорила и гугление никаких результатов не принесло). Было предположение — что проблема из-за размера данных при деплое — 24.000 файлов, 1.5G, если не ошибаюсь.

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

Недавно у нас на два часа упало приложение из-за проблем с MySQL. Ответ саппорта Azure был в духе «MySQL == ClearDB, котрая является thirdparty-сервисом, и мы ничем вам помочь не можем, пишите письма им». И даже дали ссылку. Возможно — спорный момент (но ведь платим мы не ClearDB?), но радости от работы с Azure не добавило.

Кстати, о саппорте. Если вы захотите спросить о чём-то (кроме вопросов оплаты) тех. поддержку — вы должны купить саппорт. план. За деньги. А уровень поддержки и их ответы… Это тема отдельной статьи, наверно.

Чего только стоят ответы в духе «Мы знаем об этом баге, но исправлять его не планируется». Честное слово — так ответили. Или когда пишешь со вставкой своих команд из консоли (to reproduce), в которых написано «ssh -p 2222», а в ответе пишут «Мы заметили, что у вас нестадартный порт демона SSH, попробуйте подключаться на порт 2222». Кроме мата, опять-таки — никаких других слов тут не находится.

Ух, накатал! Высказался. Очень меня достал Azure за эти полгода. С ним сложно работать. По крайней мере — мне. И да — я с трудом представляю, что бы человек, «выросший» *не* на использовании PowerShell, Win Server, MS SQL, .NET и прочей «кухни» MS — добровольно начнёт пользоваться ими.

Ну и напоследок — немного улыбательного:

> Hello %USERNAME%,
> Thank you for contacting Azure Subscription Management Support. My name is Stalin.

Такое вот получал :-)

Всех с Пятницой.

Да, во многом ваш гнев справедлив. Даже для меня иногда продукты от МС это очень много стресса и нецензурщины:) хотя я и «вырос» на Винде и сопутствующих ей продуктах :)

На тему Win-серверов комментарий давать не буду, тут на вкус и цвет. Сам использую связки Win+Lin.

Пожалуй, начать стоит с документации

Да, документация у них далека от идеала! Хотя с упорядоченостью у меня проблем никогда не было, но вот «капитанский» стиль написания меня всегда раздражал. И тупые примеры туда же!
С разнородностью иногда возникают проблемы, но не очень часто. Гугление дискомфорта не вызывает.

Ещё одна проблема (проблема ли — но тем не менее) — это то, что она написана во многом только под MS-решения

Ну, это прямое следствие из того факта, что до последнего времени НЕ MS-решений просто не было. Это как искать Gnome под Винду :) Если его нет, то искать бесполезно.
Если курс не изменится (на что я очень надеюсь!), то через два-три года будут решения и под другие платформы. А с ними появятся и блоги, и статьи.

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

Вау! Я вообще первый раз о таком слышу О_о Надо будет опробовать!

С оформлением портала они 100% перемудрили. И хотя панели немного раздражают, я бы не записывал их в список проблем платформы. Главное, что UI довольно однообразен и предсказуем, это сильно упрощает начальное обучение.

Как-то я потратил целый день из-за того, что деплой в WebApp отваливался с какой-то ошибкой

У меня так отвалилась настройка Network Adapter. И потом также чудесно всё начало работать.
В некоторых случаях можно попробовать альтернативный путь. Например, если не работает в портале, то делать через скрипты или API.
К сожалению, с вашей проблемой при деплое никаких конкретных решений на ум сейчас не приходит.

Недавно у нас на два часа упало приложение из-за проблем с MySQL

Нет, ну, это точно не к MS! :) Я даже не уверен сами ли они создавали виртуалки с MySQL :)

Кстати, о саппорте. Если вы захотите спросить о чём-то (кроме вопросов оплаты) тех. поддержку — вы должны купить саппорт. план. За деньги. А уровень поддержки и их ответы… Это тема отдельной статьи, наверно.

Поделюсь хаком: надо написать вопрос или на SO, или на MSDN Answers, а потом затвитить линк на вопрос с референсом аккаунта службы поддержки Azure (@AzureSupport). Отвечают в течении часа и абсолютно бесплатно :)
> до последнего времени НЕ MS-решений просто не было

На самом деле — да, вы совершенно правы. Но в духе вопроса «Почему Linux админ *не ...» — на сегодня вполне актуальная сложность.

> Поделюсь хаком

Ух, спасибо! Жаль — не могу плюсовать. Попробую. Хотя от периодической тупости глупости ответов их саппорта такой хак всё-же не спасёт. Он даже на премиум саппорт плане не помогает :-(

Ребята из проекта xgu.ru на своем канале в youtube вполне активно используют azure, хотя казалось бы?
Тоже не вижу ничего плохого в том что бы использовать облако от ms, инструменты для работы с облаком у них кроссплатформенные, довольно удобные и если не ошибаюсь вполне опенсорсные.

Я, как .NET разработчик, уважающий и любящий Linux, давно этого ждал. Несмотря на необходимость разрабатывать для Windows, все равно не перестаю держать в уме кроссплатформенную разработку на .NET. Но для сборки проектов использую Psake (и очень им доволен), и очень удручала бессмысленность пытаться разрабатывать кросс-платформенный проект, используя windows-only инструмент. Наконец-то и эта проблема решена! Осталось дождаться релиза IDE Rider от JetBrains, и однажды смогу перевести рабочее место под Linux… Эх, мечты =)) Еще бы WPF открыли и под Mono портировали, и настанет светлое будущее (для меня, ИМХО) =)))
С появлением UWP WPF становится потихоньку legacy для старых ос.
Ну, на корпоративном рынке оно живет. UWP это, на мой взгляд, в первую очередь для массовых (ориентированных на отдельных пользователей) приложений.

Ну, надежда (на порт WPF) умирает последней :)
UWP — это ещё и новая система дистрибьюции пакетов, чем-то похожая на Mac OS, когда вы можете полностью удалить приложение не боясь, что что-то сломается в каком-то другом. Это нацелено и на корпоративный рынок тоже.

А там уже начинается по-мелочи, вроде хотите использовать Windows Hello — конвертируйте в appx или мучайтесь с костылями. Хотите нормальную поддержку HDPI — что-то поправим в WPF, WinForms пошлем лесом, полноценно — только в UWP. Хотите встроится в системный поисковик (то бишь в Cortana) — конвертируйте в appx. И так далее.

Про систему дистрибьюции нам то же самое говорили про ClickOnce. И где оно? Наверняка некоторые до сих пор используют, но как массовая система — не выстрелило.

Хром же, нет?

А appx — единственный способ дистрибьюции через стор

Ну, вроде бы да, хром. И из распространённых приложений больше, пожалуй, никто. Даже Microsoft больше ничего не стал заворачивать (впрочем, я не уверен, и с интересом выслушаю поправки к этому утверждению).

Посмотрим, что с кроссплатформенным WPF Avalonia станет. Может выстрелит.

Кроме Psake, посмотрите ещё на Invoke-Build. Оно во многом лучше — особенно когда вам хочется пересобрать из группы файлов только те, которые надо. Например, мне надо было только новые SVG сконвертить в PNG. Это очень просто делается на Make или Invoke-Build, но со скрипом шло на Psake и FAKE.

Как вариант — админить Nano Server 2016 из под линукса/мак ос.
WinWM.
Сидим на линуксовой машине, сервера админим не слезая. Так себе случай, но право на жизнь имеет. Хотя мне всё же логичным выглядит админить win-сервера с виндовых же машины, а никсовые сервера — с никсовых станций.
В чём тут «логика»-то? Скажите уже, что просто привычнее. :)
И потом, удалённый рабочий стол же…
Ссылки на инструкции битые (в них домен github.com не указан, только относительный путь)
Теперь можно будет под виндой запустить баш, а в нем запустить повершелл!

А уж как он умильно жаловался на отсутствие /usr/bin/perl.exe, такая была милота :)

Как и все прочие любезные жесты MS 2 Linux — слишком поздно.
Почему же? Как по мне то одним и вторым удобно
Если бы еще мне кто кейс использования под Мак рассказал…
Я работаю фрилансером, админю много виндовых серваков. Есть много домен контроллеров в версии Core. Зачастую клиенты дают ВПН канал для управления серверами. Так что я со своего мака с удовольствием буду писать скрипты для администрирования клиентских Active Directory.
Выше kekekeks привел пример: разворачивание пакетов из nugget.
А каков юзкейс разворачивания каких-то девелоперских пакетов (я ведь правильно понял его назначение) на маке?
Не сочтите это каким-то издевательством, я правда слишком далёк от девелоперской инфраструктуры мс, да ещё и на маках. Чистое незамутнёной любопытство.
Имеется в виду — побилдить на маке виндовый проект?
Друг мой, NuGet-пакеты содержат скрипты для добавления библиотек в текущий проект.
Нужна тебе обработка JSON — ты пишешь в Dev-консоли
Install-Package NewtonSoft.JSON

Можно и без этого обойтись, но так удобнее.
Давайте ещё раз, я с первого раза так и не понял юзкейса — нужно добавлять виндовые девелоперские пакеты в текущий проект на маке? Рречь о разработке на маке под винду? Или что-то хитрое кроссплатформенное? Я пытался делать кроссплатформенность с помощью cmake, но на маке он генерит крайне странные проекты для xcode, пришлось пилить руками. Вот эта балалайка мне поможет?
Для сборки проектов использую Psake. Теперь, его можно будет использовать и на Mac (теоретически; к сожалению, пока сам попробовать не могу). Сам долго перебирал системы сборки для .NET, и остановился на Psake (он моим требованиям полностью удовлетворил, а теперь и кроссплатформенность подъехала). Попробуйте, может и вам поможет.

Стоит также упомянуть, что в состав Mono входит утилита xbuild, которая умеет собирать "виндовые" солюшены и проекты. Мы этим пользуемся в нескольких случаях. Собранные бинарники работают и на винде, и на линуксе.

xbuild\msbuild использую только для сборки самих visual studo — проектов. Но кроме сборки есть еще очень много дополнительных телодвижений, которые я предпочитаю выполнять из скриптового языка (а не xml). После долгих метаний (ruby, python, f#) окончательно остановился на Powershell + Psake

Побилдить или создать на маке кросс-платформенный проект на .Net Core

А, вон оно что! Спасибо. А IDE на маке при этом какое используют? Или в виме пишут?

Не все сразу. Когда-то и фраза "кросс-платформенный проект на .Net " считалась смешной шуткой.


Кстати, для простого билда IDE не нужна. А вот powershell может пригодиться.

Попробуйте посмотреть сюда IDE Rider. Пока что early access, но проекты уже собирать можно. Да и вроде в этом году релиз обещали (это без пруфов).
Там вроде своих пакетов хватает, благо пакетный менеджер есть давно.

Не путайте системные пакеты и те, которые ставятся в проект.

У меня был случай, надо было написать скрипт по развертыванию небольшой системы, что бы он работал у заказчика. На питоне я не хотел писать по религиозным соображениям. На bash — решил, что у завазчика винда и ставить cygwin он не захочет.
Написал на PowerShell, а у заказчика оказался Мак… Я был бы рад, tсли бы тогда под Мак был портирован PowerShell…
Довольно комичная ситуация, их шел не нужен никому кроме майкрософт, а если подумать, то и им не нужен.
повершелл имеет огромное количество инструментов для работы с АД и устройствами в виндовс. Будет отлично писать скрипт на баше, который вызывает готовые повершелловские скрипты без извратов. или даже скрипт на повершелле запускать по крону линукса.
А АД контроллеры в мелких фирмах на базе самбы, с повершелловскими скриптами?

Про МС я скажу так: Вот это поворот.
Вот эффекта «вот это поворот» у меня не было, на фоне открытия кроссплатформенного .Net Core было скорее ожидание «скоро тут появится PowerShell»
«Мне не нужен, значит, никому не нужен». Прекрасно.
Вообще то я многократно сертифицированный специалист в области серверных ОС майкрософт, выражаю, так сказать некую общую точку зрения с высоты моего личного опыта и моих коллег.
По-моему они явно показывают, что стремятся организовать множество инструментов, совместимых с другими операционками.

А потом, когда все Линуксовое будет работать под виндой, а виндовое, как обычно, не будет нормально работать под Линуксом, внезапно что-нибудь случится.
И что же, мышкой и драг-н-дропом сервера админите?
Вы так говорите, как будто это плохо. Я тоже админю мышкой сервера и прекрасно себя чувствую. Коммандлайн остался в прошлом с выходом win95
Вот они какие неленивые админы…
Я очень ленивый. По мне так лучше тыкать в чекбоксики и радиобаттоны, чем запоминать кучу ключей с параметрами
Да нет, человек, которому не лень при каждой необходимости тыкать в чекбоксики и радиобаттоны, чем один раз написать скрипт для повторяющихся действий, очень даже трудолюбивый…
Что то я не очень понимаю, зачем администрить одно и тоже несколько раз? С первого раза не работает?

Если у вас 1 сервер — пожалуйста, продолжайте админить его мышкой.

Сервера приложений, сервера баз данных, сервера администрирования и сервера вспомогательных файловых хранилищ настраиваются абсолютно разним способом, никакой волшебный скрипт тут не поможет
Хотите сказать, что ко всему есть GUI?
Например, к Exchange 2013 (да, там есть ecp, но там не всё)?
Мне как-то поставили задачу сбора статистики по количеству входящих и исходящих писем для определённого списка сотрудников. Как думаете, решается она мышкой?
Это далеко не единственный пример, и совершенно не уникальный. Уверен, у других похожих задач полно встречалось.

Ещё пример: сможете мышкой разрешить пользователям пользоваться командой msg на осях старше Windows 7\2008? И не только разрешить, но и пользоваться. И не самописными\сторонними средствами (ибо скрипты уже и утилиты), а встроенными.
/? -h --help спасает
И да, я очень ленивый, мне лень каждый раз тыкать чекбоксы, когда можно один раз сделать скрипт. С параметрами. И да, с превого раза не работает — серверов много, рабочих станций — ещё больше, обезьян^Wэникеев учить сложно — напутают со своей мышиной возьнёй, а так дал скрипт — он отработал и всё хорошо.

>> никакой волшебный скрипт тут не поможет
А когда серверов баз данных пара сотен — очень помогает, и про клиентов уже упоминал.
А у сисов не работает отмазка: «настройка это 1% рабочего времени, 99% мы думаем над задачей, потому автоматизация не нужна, мы будем конфигурировать сервера с помощью г**на и палок!» — ? У нас вон в среде редакторов так постоянно говорят и считают это аргументом.
Админ спит — служба идёт. Сейчас я администрирование занимаюсь постольку-поскольку, но скрипты для сопровождения продуктов приходится делать — это проще, чем объяснять что и как настроить руками (когда нужны единичные настройки — да, но массовые так вносить слишком сложно). PS в этом плане отличная вещь, т.к. альтернатива — cmd. Ещё перловые использую, но он не везде есть (речь о виндах). С никсами проще — [ba]sh всяко лучше cmd.
Group Policy полностью прекрасно управляется мышкой
GP — это не единственное что требуется. Тем более большинство много серверов находится в изолированных сегментах и не имеют доступа к консоли/шеллу снаружи. Собрать логи с управляемого оборудования проще скриптом(и обработать тоже), чем рассказывать где взять, как упаковать и что надо, а что — нет.
PS. На самом деле спасибо — я как раз благодаря этому вспомнил что в понедельник надо будет написать скрипт для анализа параметров нетипичного поведения железа (вылетело совсем из головы) и мышкой там тыкать абсолютно бесполезно.

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


Например в винде — посмотреть на состояние всех сервисов для sql server


    gsv *sql*

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

Это неправильная команда, так как инстансы совсем необязательно должны содержать sql в названии

А какой сервис не содержит этого в имени?

Имя любого windows сервиса может быть изменено. Каких либо атрибутов принадлежности нет, DisplayName вообще используется только в косметических целях. Можно конечно позапрещать юзерам админские права, но в реальной жизни Get-Service *sql* отнюдь не гарантирует ничего

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

Имя любого Linux сервиса тоже может быть изменено. Но зачем?

Давайте переименуем explorer.exe в проводник.исп, чтобы никто не догадался?
Я утверждаю, что графические инструменты управления компьютером гораздо более удобны и комфортны в использовании. Мой собеседник утверждает, что ему коммандлайн удобнее для выполнения однократных задач. Он запускает программу PowerShell для выполнения комманд, вспоминает команду для получения списка сервисов Get-Service, затем вспоминает что у неё существует короткое имя, затем приступает к вспоминанию параметров этой команды, набирает ёё и затем анализирует многострочный текстовый результат выполнения. Запуская графическую программу Services, я сразу получаю удобное окно со списком сервисов с описаниями, состояниями, аккаунтами с возможностью сортировки, скроллингом и управлением сервисом. Кому что удобнее — дело субъективное. Я просто не понимаю критику отчаянных коммандлайнеров, которые неприемлют графические 'драг-н-дроп' интерфейсы и утверждают что жизнь в коммандной строке лучше. Нет, не лучше — я видел этот мир до выхода win95, это безумие параметров команд которое нужно держать в голове или на листиках перез глазами и очень рад что сейчас все могу сделать мышкой.
Всему свое. Я давеча был горячим поклонником интерфейса. Теперь у меня пачка батников и .sh-шников на многие случаи жизни. Некоторые из команд я помню наизусть, банально по тому что zsh, когда я стал админить сервера, постоянно перед глазами и из нее можно быстро получить результат. Конечно я себя все еще ощущаю скованно, нежели под RDP к хиперви, или когда я использую оснастку стандартную, но админить именно сервер мне стало удобнее.

Для меня это был нелегкий путь в 7 лет, от знакомства с убунтой-сервер и ее немедленным удалением, до вполне комфортной работой в freebsd через терминал.

Мне кажется, вы перешли в режим спора для победы


Он запускает программу PowerShell для выполнения комманд,

ISE у меня как правило открыт и комп я перегружаю редко


вспоминает команду для получения списка сервисов Get-Service, затем вспоминает что у неё существует короткое имя,

Не, я просто пишу gsv — для меня gsv это уже непосредственно команда получения статуса сервиса, а вот длинный алиас придется вспоминать


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

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


Да, когда надо отредактировать я иду в gui. Я не говорю, что command line или gui всегда удобнее или неудобнее. Я говорю, что часто даже для выполнения однократной задачи удобнее cli

Мне нужен.
Я по работе вынужден был использовать винду, и подсел на PowerShell, что теперь под Linux нейдобно жить стало.

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

Тем, кому оно надо — те bash знают хорошо, к его сомнительным моментам давным-давно привыкли, и везде есть из коробки.

А powershell изучать надо, зачем? Там, где bash-скрипт становится слишком монстроузным, проще написать нужное на python/ruby.

Единственный кейс, который я вижу, — запуск какого-нибудь шарп-приложения с powershell-обвязками на линуксе.
А powershell изучать надо, зачем?

Почему именно изучать? Для тех, кто работает на обеих платформах, будет проще иметь один и тот же инструмент.
Скорее, для тех, кто работает в основном на Windows. :) Ну, мне как старому юниксоиду так кажется. Хотя, честно говоря, и среди Windows-разработчиков/админов не видел, чтобы его активно использовали.

Баш с coreutils, при всех исторически сложившихся неконсистентностях, имеет одно большое преимущество — команды короткие и компактные, можно написать довольно сложный однострочник одним взмахом руки над клавиатурой, становясь таким образом инструментом, который испольуется не то, что ежедневно, а ежечасно. Таким образом это все изучается до уровня «пишу спинным мозгом».

Powershell, при всей его концептуальной красоте, по факту слишком многословен для такого применения — я ж однострочник одноразовый пишу, а не программу на века.
У многих комманд PowerShell вроде псевдонимы повторяющие команды в «привычном нам с вами», разве нет?
Для простейших случаев — да. А аналоги из реальной жизни с наворотами sed-ов, grep-ов и прочих wc и sort/uniq становятся все же сильно длиннее.

Ну, можно же и sed из powershell вызвать...

НЛО прилетело и опубликовало эту надпись здесь

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

И это правильно, семантика несколько разная.
Надо бы у себя алиас curl и wget отключить, спасибо за идею…

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

Как юниксойд использую powershell для автоматизации развертывания и настройки Windows в облаках.
Скажу честно, работать с ним намного приятнее, чем с cmd и другими устаревшими консольными виндовыми утилитами.
Но на linux вполне устраивает и bash, честно говоря даже не представляю жизни без него.
Считаю, что powershell хорош, но для винды. Под linux он нужен в первую очередь для решения виндовых задач.
Полностью заменять им bash думаю, что никто пока не собирается. Скажем так, концепция у них разная. :)

В PS есть возможность задавать свои алиасы (сокращения для команд). И, если не ошибаюсь, настроить их на постоянную работу вместо сессионной.
Кстати, есть мнение, что реюзабельные однострочники — зло. Ибо читаемость для неопытного коллеги на порядок хуже. Хотя для единичных запросов однострочники гораздо удобнее, да.
Для однострочников есть комплетишен. Хоть в PowerShell он и хуже следан, чем в bash, но мне хватает, что бы от многословности не страдать.

Интересу ради — а расскажите, где (в чём) комплишен хуже сделан в PowerShell, чем в баше? Просто начиная с Windows 10, по-моему, в повершелле из коробки подключается PSReadline с подсветкой и семантическим автодополнением. Если честно, я такого изкоробочного опыта ни в одном линуксе не припомню (хотя я положительно уверен, что его можно добиться в баше и в альтернативных шеллах тоже).

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

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

Ну если пользоваться еще и vim, который такие файлы любит создавать, эта фича становится несколько назойливой.
Да и про PSReadline я не так давно узнал, без него плохо было.

Нужное на python/ruby проще написать только тому кто знает python/ruby. А тому, кто знает C#/VB.Net — проще писать на powershell, ведь у этих языков общая стандартная библиотека.

В универе нас пытались посвятить в C#, я не проникся. А вот в работе админа PS теперь использую. Не сказать, что похоже как-то сильно. Хотя может сейчас и поменялось что-то в шарпе по сравнению с 2005 годом.

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

Хотя может сейчас и поменялось что-то в шарпе по сравнению с 2005 годом.

Посмотрите на LINQ


Не сказать, что похоже как-то сильно

Система типов, .NET FW в качестве основы

Новое изучить обычно очень приятно.
Да и как язык PowerShell удобнее питона для простых приложений.
до сих пор не представляю, как нормальным способом сделать в винде что-то типа:
VAR=`ls -1 | grep bin`

Все предельно просто:


$VAR = (Get-ChildItem | Where-Object {$_.Name -like "*bin*"})
Чуть попроще:
$VAR = Get-ChildItem *bin*

Ну, не забывая, что у Get-ChildItem есть нескольо алиасов а-ля dir, gci, ls (последний, впрочем, пока что отключен на линуксе).

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

Да, это верно. Лично я никогда не использую алиасы в скриптах (за исключением % и ?), но в 90% случаев использую их в командной строке.

Это просто? Это как Hello World на Java.
Ну ничего себе, на Power-Shell это выглядит намного понятнее, чем на bash.
понятнее — да, но в повседневной деятельности башевый вариант гораздо удобнее из-за компактности, а команды стандартные
Там же выше привели вариант на PS:
ls *bin*

Он и короче, и функциональнее.
В чем именно удобность компактности? Если набивать строку, то есть IntelliSence. Или что-то ещё?

Никто не мешает писать повершелльные команды сокращенно. Существует масса алиасов и никто не запрещает создавать свои. Кроме того, Powershell разрешает использовать короткие версии ключей, написав несколько первых символов, однозначно их определяющих. Например, у того же ls есть длинный ключ LiteralPath, но его смело можно сократить до -l или -L, а ключи -Recurse или -ReadOnly можно сократить до -rec или -rea соответственно.
Это если помнишь и часто используешь команду, помнишь ключи и набираешь ее "на автомате". А если не помнишь — Tab или Ctrl+пробел переберут/покажут все возможные варианты.

Powershell больше похож на язык программирования типа перла или питона, а баш — это именно клей для самых разных утилит. Например, на PowerShell вы не сделаете:
# dd if=/dev/sda1 | ssh user@host sudo dd of=/dev/sdb2
(передача образа диска по сети без промежуточного сохранения в локальный файл).
Не вижу, как баш и PowerShell мешают друг другу, наоборот дополняют.
Например, на PowerShell вы не сделаете:
dd if=/dev/sda1 | ssh user@host sudo dd of=/dev/sdb2

Вы пробовали это на PSh под Linux — если dd это что-то внешнее — а не встроенная команда, почему бы нет?

На Powershell это превосходно можно сделать — никто не мешает использовать внешние утилиты и отправлять их вывод по конвейеру.


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

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

На этот вопрос я прямо сейчас ответить не готов :-) Проверить на практике не очень сложно, так как Powershell уже можно установить в линуксах.
В конце концов, не исключено, что в данном конкретном случае и разумнее использовать bash. Однако, по моему представлению, гораздо чаще возникает необходимсть "склеить" bash-eм вывод несколько утилит, анализируя и обрабатывая текстовый вывод одной утилиты перед отправкой его по конвейеру на вход другой. И вот тут, возможно, Powershell может оказаться в преимущественном положении ввиду тех причин, о которых я говорил уже неоднократно: многие вещи на нем "заскриптовать" и отладить проще и быстрее.

но это только в повершелл, а не в обычном .bat?
setlocal /ENABLEDELAYEDEXPANSION

set var=
for %%i in (*bin*) do set var=!var! %%i

Если ничего не напутал, то вот так.

это вроде не совсем то. Я имел ввиду как в переменную присвоить значение ЛЮБОЙ команды или связки, а не конкретно ls
спасибо… но как это криво и нелогично выглядит…
Выше написали, но можно короче:
$var = ls | ? { $_ -match 'bin' }


И в результате будут объекты, т.е. например можно
$var.FullName # вывести полные имена
$var.CreationTime # даты создания

А насколько читаемым и естественно выглядящим в bash-е будет аналог следующего PoSh-однострочника?


ls | where { $_.CreationTime -gt (Get-Date).AddDays(-222)  -and $_.LastWriteTime -lt "2016-07-07"  -and $_.Length -lt 2GB  -or $_.Name -match 'bak' }

Спойлер для начинающих

Отобрать все файлы, созданные не раньше 222 дней назад, запись в которые осуществлялась до 7 июля 2016 года, размер которых меньше 2ГБ, плюс к ним те, которые содержат в своем имени шаблон "bak".


Обратите внимание: для написания такого однострочника (равно как и подавляющего большинства других powershell-скриптов) не нужно использовать сторонние утилиты (типа grep, sed, awk, find..., каждая из которых, к тому же, обладает своим собственным заковыристым неинтуитивным синтаксисом). Кроме того, Powershell подсказывает возможные ключи при наборе команды привычным нажатием на клавишу Tab. Man-ы Help-ы по нему тоже внятные и понятные. Ну, и комплектование PoSh-a полноценным отладчиком — это тема, которую очень сложно переоценить. Нужно ли говорить о том, что posh-скрипты еще и самодокументированные благодаря хорошо проработанному синтаксису? При этом гибкость проявляется еще и в том, что для быстрого запуска одной-двух команд можно использовать алиасы и сокращения, а когда отлаженный и полезный скрипт захочется отлить в граните, то можно использовать полный "рассказывающий" синтаксис.


Упаси боже, это не попытка раздуть "холивар", а просто демонстрация изящности и мощности инструмента, который отныне появился в руках *никсоидов. Powershell — вовсе не bash-киллер, но дополнительная и не самая "отстойная" возможность улучшить качество жизни системного администратора. Потратьте день (ну, хорошо, неделю) на освоение этого продукта от ненавистного MS — полагаю, и у вас возникнут ситуации, когда вы предпочтете Powershell bash-y или Python-y. И уж точно — не пожалеете о потраченном времени.

find . -maxdepth 0 -ctime  -222 ! -newermt "2016-07-07" -size +2G -name "*bak*"
Я не знаю синтаксиса, честно говоря, где тут логическое ИЛИ?

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


find . -maxdepth 0 -ctime  -222 ! -newermt "2016-07-07" -size +2G -o -name "*bak*"
В условии нельзя использовать find.
Компьютером-то хоть можно пользоваться?
А как вы хотите показать преимущество баша над повер шеллом, запуская стороннюю утилиту, которую с таким же успехом можно будет запустить и из повер шелла?

bash нельзя рассматривать отдельно от coreutils. Они неотделимы. Даже MinGW и Git for Windows тащут за собой минимальный набор этих утилит.

Использование множества узкоспециализированных утилит — это философия юникса. Баш — это просто «клей» для них.
В юниксе куча разных шеллов из которых можно запускать утилиты. Как функциональность одной утилиты показывает преимущество баша над остальными «клеями»?
Да причём здесь какое-то преимущество? Есть разные инструменты и философии, пусть они вместе живут. Хорошо, когда инструментов много и не приходится молотком шурупы закручивать.

Ветка началась с вопроса «насколько читаемым и естественно выглядящим в bash-е будет аналог следующего PoSh-однострочника?». Народ набросал ответы. А вот вы зачем-то на вентилятор вместо этого набрасывать пытаетесь.

Я так понимаю разговор идет не о bash конкретно, а bash+coreutils, так как обычно говоря "на баше" подразумевают и базовые утилиты, которые как правило всегда идут в комплекте с ним.


Вам наверное занятно будет узнать, что:
ls, echo, cat, cp, mv… — это все отдельные программы и лежат они как отдельные бинарники.
Чего уж там, [ и ] — это тоже две отдельные программы...

Вы написали, что не поняли условие задачи. Я вам пояснил, что в ней открытым текстом написано:
не нужно использовать сторонние утилиты (типа grep, sed, awk, find..., каждая из которых, к тому же, обладает своим собственным заковыристым неинтуитивным синтаксисом)

Ок, где провести грань "стороние утилиты"? — да, я увидел команду find в вашем условии и позволил себе отсупить от него. Но вы же уже получили ответ, что find — это такая же часть системы как и bash, рассматривать их отдельно бессмысленно. Не понимаю, чего еще вы хотите...

Большая доля времени изучения bash уходит на трюки и фокусы по парсингу строчек. Если от этого можно будет избавиться — уже хорошо. В этом примере без этого обошлось, что большая редкость на самом деле. Глаза на лоб лезут когда иной раз глядишь на простые задачи решаемые через всякие авки, седы. Совершенно не читаемый код, монструозный и ненадежный.

Абсолютно верно! Стандартная и набившая оскомину фраза о преимуществах Powershell: "в результате выполнения командлета передается объект, а не строка" — не впечатляет подавляющее большинство опытных "bash-истов"… пока они сами серьезно не начинают работать с Posh.
А ведь передача объектов — это настоящая "киллер-фича" Powershell! Но абсолютно неоцененная огромным количеством админов. Потому что десятилетия использования bash и иже с ним выработали мнение "по-другому быть не может".

я увидел команду find в вашем условии


Это не мое условие. Я от вас ничего не хотел.

Вы написали, что не поняли условие задачи. Я вам пояснил, что в ней открытым текстом написано:
не нужно использовать сторонние утилиты (типа grep, sed, awk, find..., каждая из которых, к тому же, обладает своим собственным заковыристым неинтуитивным синтаксисом)

Вобщето написанно, что в PS не надо использовать сторонние утелиты. Но вот для решения задачи в bash незапрещенно их использовать.
Ненадо вырывать из контекста фразы.
Хорошо, можно трактовать и так, но тогда это получается не решение в баше, а запуск решения задачи в баше. Я думал человек хотел два шелла сравнить.
Там написано «не нужно», а не «нельзя», т.е. это не требование к реализации («в вашем решении нельзя использовать...»), а объяснение существующего решения («в данном решении не пришлось использовать...»).
Интересная логика ) А давайте я напишу свой шел, в коробку которого засуну awk. От этого он станет лучше bash? )) А есть ли разница, из коробки ли эта утилита в оболочке, или не из коробки? Есть! Лучше чтоб она была не из коробки, ибо философия юниксов и все такое. Маленькийсофт с этой философией не знаком, потому и засовывает во внутрь своей поделки все подрят, создавая «функциональность для галочки».
sefus, философия линукс предполагает, что создавая инструмент, нужно создавать простенький удобный инструмент, заточенный под конкретную задачу, а не суперкомбайн. Потому из стабильных, простых, быстрых инструментов через конвейеры баша можно создать любую нужную задачу.

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

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


Это и есть так называемый KISS, ему стараются следовать почти все *nix системы, отсюда и такая разрозненость.
И как сказал mayorovp bash нельзя рассматривать отдельно, т.к. его основное предназначение — это как раз предоставлять интерфейс связывающий все эти маленькие кусочки воедино.

Вариант, что в системе не будет команды find вы не рассматриваете?
Я скорее рассмотрю вариант, что павершелла не обнаружу.

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

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

А его и нет в некоторых случаях и ничего — никто не умер. Если система не слишком сильно урезана — менеджером пакетов можно поставить пакетик с find, будь то сам find или какой-нибудь busybox. А если система настолько урезана что не подразумевает наличия пакетов в принципе — то чего вы туда полезли? Подмонтируйте ФС и делайте что вам нужно привычным инструментом. Ну или закиньте туда статично скомпилированный busybox.

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

Суть темы такова: MS открыла исходный код инструмента, который позволяет системным администраторам Windows находиться в Linux и чувствовать себя как дома. Также речь идет о том, что в систему Windows будет добавлен альтернативный инструмент из мира Unix для ее управления. Все это ведет к тому, что будет меньше костылей для управления серверами Windows из систем Linux. Именно серверами, так как для обычных пользователей это совершенно не актуально.

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

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

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


Кстати, вышеупомянутый find — вообще "белая ворона" в юникс-утилитах, ибо использует "словесные" ключи типа "-maxdepth" или "-ctime". Юникс-стиль — собирать за единым дефисом несколько однобуквенных опций, а "словесные" предварять двойным дефисом — здесь нарушен. А ведь чаще всего приходится собирать в конвейер несколько команд с разнородным синтаксисом.

По синтаксису так:


find . # искать в текущем каталое
-maxdepth 0 # глубина поиска 0 (то есть нерекурсивно)
-ctime -222 # Создан раньше, чем 222 дня назад
! # Не
-newermt "2016-07-07" # дата модификации, новее чем 2016-07-07 (опция новая, в старых системах не работает)
-size +2G # Размер больше 2G
-o  # Или
-name "*bak*" # Имя содержит bak
Спасибо. Но вот неподготовленному программисту PS читается очевиднее. (хотя может все дело в том, что пишу на c#)
Для меня PS тоже не совсем понятный. Или вас не устраивает Windows, но в Linux не хватает инструментов Windows?
Я линуксом вообще не пользуюсь (по крайней мере как пользовательской ОС), PS тоже ) Маком приходится и башем в нем иногда. Спрашиваю в основном из спортивного интереса.
Да ладно. Зачем неподготовленному программисту такое видеть.
Я вот очень редко пользуюсь и bash и PS, прям крайне редко, но проблем ни с одним ни с другим не возникает. Все гуглится на ура.
Когда я нагугливаю скрипт я стараюсь понять что он делает. Для этого читаемый синтаксис очень важен.
Линукс, такой линукс. Решил проверить эту «команду», состоящую из запуска одной программы с параметрами. Не работает. Стал разбираться почему. Первый же поиск в гуглах:
http://unix.stackexchange.com/questions/162411/find-maxdepth-0-not-returning-me-any-output
Глаза краснеют.
О минусуют. Хотя мне на это как-то по, поясню:
Пользователь линукс выложил на обозрение неработающую команду. Причем такую, что ни один пользователь НЕ линукса и многие пользователя линукса не поймут что она не работает пока не запустят. maxdepth=0 ассоциируется с тем что по внутренним каталогам лазить не надо (как и написано у многих в пояснениях), хотя по факту означает что имена файлов надо брать из командной строки.
И весь линукс примерно такой. Либо ты пользуешься только линуксом и тебя эти моменты не беспокоят ибо привык и все запомнил, либо постоянно лазаешь по хелпам, манам, гуглям, потому что не помнишь все детали или они путаются с другими ОС или абсолютно не интуитивны.
Пользователь линукс выложил на обозрение неработающую команду.

Да с чего Вы взяли, что неработающую? :)

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

Ровно то же самое можно сказать и о всех прочих, на любой ОС. Вот «пока не запустят» — так и «не поймут», как правило. А очень многие «не поймут» и после того, как запустят. И что? Разве это хоть что-то говорит хоть о чём-то, кроме «качества» самих пользователей? Да нет же. :)

Прощу прощения, редактирование недоступно, поэтому дополню здесь:

maxdepth=0 ассоциируется с тем что по внутренним каталогам лазить не надо (как и написано у многих в пояснениях), хотя по факту означает что имена файлов надо брать из командной строки.

Там всё написано нормально. В man find, во всяком случае.

И весь линукс примерно такой.

Вы передёргиваете. :)

Ну, или тогда уж можно сказать, что «все ОС такие».
Пока не разберёшься — не работает, зачастую. :)

Т.е даже после того как я сказал что она не работает, вы в это не верите? Забавно. Ну проверьте сами вот это:

krey@gw:~/test$ touch file1
krey@gw:~/test$ ls -lah file1
-rw-rw-r-- 1 krey krey 0 Aug 20 07:47 file1
krey@gw:~/test$ find. -maxdepth 0 -name file1
krey@gw:~/test$ find. -maxdepth 1 -name file1
./file1
krey@gw:~/test$ find. file1 -maxdepth 0 -name file1
file1

Забавно что в текущих man`ах это вообще не поясняется. Через пару лет это уйдет в подвал гугля, будут слагаться мифы и легенды, а новичкам этот behavior будут объяснять ссылаясь на личное отношение разработчика find к погребальным обрядам.
Т.е даже после того как я сказал что она не работает, вы в это не верите?

Таки да. :)
Меня ещё дед учил: «Доверяй, но проверяй». Я проверил. Работает, сволочь!.. :)

Забавно.

Мда? А по-моему, просто разумно. Мне давно уже не 5 лет, чтобы быть настолько доверчивым…

Ну проверьте сами вот это:

Вам, видимо, станет ещё забавнее, но я проверил.
Причём до того, как писать Вам первое сообщение. :)

Ещё одна проверка поведения find почему-то :) не изменила:

[user@host ttt]$ find. file1 -maxdepth 0 -name file1
file1
[user@host ttt]$ find. file1 -maxdepth 1 -name file1
./file1
file1

Что я делаю не так? :)

Забавно что в текущих man`ах это вообще не поясняется.

Мне кажется, что имеют место быть «трудности перевода», Ну, или понимания…
Что я делаю не так? :)

Очевидно вводите другую команду:
krey@gw:~/test$ find. -maxdepth 0 -name file1
[user@host ttt]$ find. file1 -maxdepth 0 -name file1


Оригинал:
find . -maxdepth 0 -ctime -222! -newermt «2016-07-07» -size +2G -o -name "*bak*"


$ find . -maxdepth 0 -ctime -100
.
$ find . -maxdepth 1 -ctime -100
.
./.bashrc
./Videos
...
А Вы не пробовали читать, на что именно я отвечал? :)
Мой оппонент предложил мне проверить именно эту команду. Что я и сделал.
Пробовал, попробовал ещё раз, ткните носом, пожалуйста.
Давайте разбираться. Вот его команды:

find. -maxdepth 0 -name file1
find. -maxdepth 1 -name file1
find. file1 -maxdepth 0 -name file1


Вот ваши:
find. file1 -maxdepth 0 -name file1
find. file1 -maxdepth 1 -name file1


Жирным выделены общие, т.е. те, которые вы повторили. Несложно видеть, что вы повторили одну из них, а не все, и вывод у вас обоих для неё не отличается, т.е. «а у меня работает» тут явно не применимо.
Вторая и третья команда вашего собеседника — это не оригинальная команда, и вот они-то работают, какой смысл повторять их? А вот оригинальную, первую, о которой и идёт речь, вы не повторяли.
Да, все верно.
find. -maxdepth 0 никогда не вернет никаких результатов, потому что требует перечисления файлов, а там стоит только точка. Я же так и написал. Поэтому либо ставим maxdepth=1 либо перечисляем файлы рядом с точкой. Что я и продемонстрировал.
Поражаюсь как можно спорить столько сообщений подряд так и не поняв предмет спора.
Кстати, ещё один вариант, который сработал бы при -maxdepth 0 — это
find * -maxdepth 0

Но в оригинальной задаче он не подойдёт.
Вы утверждали, что: «в текущих man`ах это вообще не поясняется», и что «она не работает»
Я писал, что таки работает, и что «Там всё написано нормально. В man find, во всяком случае.»

Смотрим в man find. Там случай с maxdepth 0 выделен специально:
-maxdepth 0 means only apply the tests and actions to the starting-points themselves.


То самое Ваше «хотя по факту означает что имена файлов надо брать из командной строки.», только не «по факту», а штатное поведение, описанное в документации.

Но Вы, видя и зная это, всё равно почему-то утверждаете, что «не работает». :)
Видимо, имея в виду, что работает не так, как ожидаете Вы.

Не спроста я писал о «трудностях перевода»…

Резюме: работает. Причём особенность поведения при maxdepth 0 прямо заявлена в документации.

Так что «спорить столько сообщений подряд» можно не только «не поняв предмет спора», но и не поняв (отказываясь понять?) документации к утилите.

Я надеюсь, теперь-то мы поняли друг друга? :)
Про трудности чтения или понимания это вы верно подметили.
Неработающая команда, это вот эта, привожу её ещё раз целиком:
find . -maxdepth 0 -ctime  -222 ! -newermt "2016-07-07" -size +2G -o -name "*bak*"

Не утилита find нерабочая, а вся целиком эта команда (find — не команда), так как она не делает то, что просили. Работоспособность и корректность самого find никто не оспаривал.
Изначально всё-таки речь шла о том, что именно find «не работает».

Вы в этой вот своей командой появились гораздо позже. Откуда она взята, я не знаю, но… И она тоже работает. ;)
И именно так, как «просили», но!.. Вы, похоже, не понимаете, что именно просите. Krey писал ведь чуть выше:

find. -maxdepth 0 никогда не вернет никаких результатов, потому что требует перечисления файлов, а там стоит только точка.


Так что Вы своей командой пытаетесь что-то найти в «файле» с именем "." (точка), а такого файла нет.

В общем, и Ваша команда работает, и работает ровно так, как Вы и «просили» — вот только результат совсем не такой, как Вы почему-то ожидаете.

Но и это не самое забавное! :)
Самое — это то, что именно Вы, чуть выше, уже привели правильный вариант команды поиска только в текущем каталоге с maxdepth 0. :)

Опции, специфичные для Вас, я пока опускаю (мне они только мешают), но вот с поиском каталогов и файлов только в текущем каталоге прекрасно справляется команда:
find * -maxdepth 0

По умолчанию поиск выдаёт и файлы, и каталоги. При необъодимости можно искать только файлы (опция -type f) или только каталоги (опция type -d).

Что-то ещё?

В общем, я надеюсь, мы хоть немного да продвинулись в процессе понимания друг друга. :)

Спасибо.
Это уже просто не смешно. Прочтите наконец всю ветку от начала и до конца.
Я вам помогу. Ветка началась с этих сообщений:

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

Пользователь линукс выложил на обозрение неработающую команду. Причем такую, что ни один пользователь НЕ линукса и многие пользователя линукса не поймут что она не работает пока не запустят. maxdepth=0 ассоциируется с тем что


Во всей ветке речь идёт именно о том, что не работает команда, а не программа. И под не работает подразумевается именно что, что это и значит — не делает то, что задумано. Я вам даже процитирую, что было задумано:
Отобрать все файлы, созданные не раньше 222 дней назад, запись в которые осуществлялась до 7 июля 2016 года, размер которых меньше 2ГБ, плюс к ним те, которые содержат в своем имени шаблон «bak».


А теперь будьте добры, покажите, где шла речь о том, что не работает программа find.
Прочтите наконец всю ветку от начала и до конца.


Да зачем же?? Дорогой товарищ, вы, возможно, не заметили, но лично я в этой (под?)ветке обсуждал с Krey — не с Вами! :) — «неработу» find с опцией maxdepth 0.
И это всё. :)

Вашей любимой команды мы с Вами коснулись, когда в наш с Krey диалог вмешались Вы.
Я ни Вас, ни Вашу команду не трогал, обсуждал только совершено конкретный частный случай опций утилиты find.

P.S.Команда таки работает — ­правда, только будучи записанной правильно. Но, как Вы и просили, я больше о Вашей команде ничего писать не буду.

Спасибо Вам за Ваше время и всего Вам наилучшего в жизни. :)
Да зачем же?? Дорогой товарищ, вы, возможно, не заметили, но лично я в этой (под?)ветке обсуждал с Krey — не с Вами! :) — «неработу» find с опцией maxdepth 0.
И это всё. :)

По-моему, это вы так и не заметили, что с Krey вы обсуждали именно то, о чём пишу я, от этого у вас такое недопонимание сначала его, а потом и меня. Не верите, спросите его лично, он вам подтвердит. Или хотя бы обратите внимание на его ответ мне, где он подтверждает мои слова.

P.S.Команда таки работает — ­правда, только будучи записанной правильно. Но, как Вы и просили, я больше о Вашей команде ничего писать не буду.

Команда работает, будучи другой командой.
По-моему, это вы так и не заметили, что с Krey вы обсуждали именно то, о чём пишу я


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

Команда работает, будучи другой командой.


Мда… «5-й класс, вторая четверть»… :)))

Команда работает, будучи записанной правильно, дорогой друг. :)
Ну да и это уже не важно. Останемся при своих мнениях.
Всего Вам доброго, ещё раз.
Его конкретный пример команды — обоснование того, почему не работает и не будет работать исходная.

Команда работает, будучи записанной правильно, дорогой друг. :)

А правильно — это как? Так, чтобы работала? Ну тогда любая команда работает, если её правильно написать, но это уже какое-то альтернативное толкование слов.
А правильно — это как? Так, чтобы работала? Ну тогда любая команда работает, если её правильно написать

Глубокая мысль! Я горжусь, что имел счастье общаться здесь с таким умным человеком! :))

но это уже какое-то альтернативное толкование слов.


Это понимание того, что команды надо писать правильно, а не «тупо и уныло» добиваться работы любого произвольного сочетания символов. Как-то так, мой юный друг… :)

И давайте уже закончим, надоело. Колдуйте дальше. :)

Осталось вам понять, что исходная команда, и «команда, записанная правильно» — разные команды. Одна работает, а другая — нет. Или вы всерьёз считаете, что это одна и та же команда?

Заканчивайте в любой удобный момент.
Я, естественно, обсуждал самую первую команду, данную в ответ на команду powershell. Сказал что она не работает, привел пример это демонстрирующий

find. -maxdepth 0 -name file1

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

find. -maxdepth 1 -name file1
find. file1 -maxdepth 0 -name file1

Sav1812 почему то решил обсуждать команды, в работоспособности которых никто не сомневался и напрочь проигнорировал исходную нерабочую команду.
И я вас прошу, не надо в очередной раз мне писать, какие стоит указать другие параметры (а значит и использовать другую команду), я с этим разобрался ещё с первых сообщений и прекрасно понимаю, почему find работает именно так, и какими способами можно поставленную задачу решить. Это не отменяет того факта, что исходная команда этого не делает. Вот она исходная, ещё разок:
find . -maxdepth 0 -ctime  -222 ! -newermt "2016-07-07" -size +2G -o -name "*bak*"
Да не все они такие. Посмотрите на приведенную команду powershell. Там нет никаких двояких толкований, скрытого поведения и непоняток вроде -222, -2G и не нужно лезть в хелп, что бы понять что значит -o: output как обычно или внезапно or. Почему o а не or? Это млин один символ!
Да не все они такие

Все. Не они, так вы, пользователи. :)
Совсем без проблем не бывает нигде и никогда.

и не нужно лезть в хелп, что бы понять что значит -o: output как обычно или внезапно or.

Не вижу проблемы. По-моему, это всего лишь проблемы личного восприятия.
В первый раз почитать придётся в любом случае. А дальше — либо запомнится, при регулярном применении, либо придётся периодически читать мануал, освежая в памяти «детали».

Почему o а не or? Это млин один символ!

Вам самому-то не смешно? :)

«Почему ВОТ ТАК, а не ЭТАК??' — этот вопрос гораздо старше программ и компьютеров… :))
Речь о Вашем личном предпочтении, всего лишь. А у другого оно будет своим. А разработчик find предпочёл вот так.

Лично я никогда не делаю из этого трагедию — просто читаю мануалы, если это необходимо — и пользуюсь.
Станет вдруг и мне „забавно“, как Вам — возьму исходники и переделаю под себя. Но я никогда не стану требовать, чтобы кто-то подстраивался под меня. :)

Даже в этой подветке быстро всплыла одна из самых серьезных "закавык" юниксовых утилит: их сложность как для освоения, так и для восприятия. Как модно говорить, "уровень вхождения" в скриптописание в "Линуксах и ко", всё-таки, очень высок. И это — большой минус, да простят меня люди, которые могут на bash-e за пять минут сделать то, на что иным людям не хватит и жизни.
Нелогичность, отсутствие целостности в интерфейсе команд, составляющих основу взаимодействия с ОС и файловой системой, просто поражает: в той же утилите find запросто используются ключи типа -maxdepth, и при этом, почему-то, в ней же OR ужат до -o, то есть ровно на одну букву. Возникают риторические вопросы: зачем? Почему?! Ага, печемся о POSIX-совместимости! Удивительно, что это коснулось лишь логических операторов.


Или вот еще такая ерунда:


wsadmin@books:~$ find . -maxpat 0
find: unknown predicate `-maxpat'

То есть авторы утилиты, предлагая человеку самому выяснять и помнить, что -o на самом означает or, сами не собираются прощать тому же самому человеку ошибки, вернее, неполноту ввода? Да что там говорить, они просто плюют на время своего пользователя, ничтоже сумняшеся придумав опции типа -ignore_readdir_race (не говоря уж о -noignore_readdir_race)! Скажите на милость, возникнет ли какая-то неоднозначность в случае, если я напишу -maxpat или даже -noign? Нет, не возникнет! Просто нет других опций, начинающихся с приведенных символов! Но никто до сих пор так и не рассказал об этом разработчикам find, и теперь в масштабах планеты в наборе этих многобуквенных ключей похоронены сотни тысяч человеко-часов (и еще в два раза больше — в исправлении неверно набранных опций: bash, к сожалению, не помогает человеку не ошибиться, не подставляет за него опции, присущие той или иной утилите).


И эти "непонятки" — всего лишь по одной программе.


Изначально я не знал, как на bash-e создать решение, аналогичное моему Powershell-примеру. Мне было интересно узнать, как это сделать, и как это будет выглядеть. И ответ был очень показательным: вопросов возникло немало как по синтаксису, так и по наглядности. (Хотя, признаюсь, я ожидал более громоздкого варианта.)


Да, я понимаю, что серьезные люди должны изучать "маны/хелпы". Да, я прекрасно отдаю себе отчет в том, что за десятилетия к подобному безобразию необычному положению вещей все привыкли и, чего уж там лукавить, смирились с ним. И именно по причине подобного понимания я крайне рад тому, что MS замахнулись со своим Powershell-ом на Linux-вселенную. Ребята, которые программировали Posh, учли накопленный опыт (в том числе и те нюансы, которые я упомянул несколькими строками выше) и сделали очень достойный, практичный продукт. И он вовсе не только (и не столько) для "руления AD из Linux", как считают многие, это просто другой (но вовсе не "еще один"!) скриптовый язык. Повторюсь: это ни разу не попытка сотворить bash-killer, но это инструмент, который, на мой взгляд, обязательно должен быть в арсенале современного системного администратора. Ну, примерно так же, как Python должен хоть в какой-то мере присутствовать в арсенале любого программиста.


Потратьте время на изучение Powershell. Полагаю, вам оно вернется сторицей и очень быстро. Практически уверен, что даже самый завзятый bash-скриптер, не признающий ничего, кроме unix-way, найдет в Posh-e то, что он будет использовать. Это продлит его жизнь за счет более быстрой реализации своих идей, когда время будет уходить на продуктивное творчество, а не на экстенсивное изучение веера синтаксических правил каждой команды и последующую борьбу с ними.


P.S.: На всякий пожарный случай, поясню: к MS я имею отношение примерно такое же, как к Canonical, Oracle, Adobe, Apache, Percona, VMware и Corel: я активный пользователь разнообразных продуктов этих компаний, и не получаю от них ни копейки (наоборот: иногда трачу на них очень даже заметное количество своих полновесных рублей :-) )
P.P.S.: Да, мне нравится Powershell. Нравится намного больше, чем bash (точнее, архаично-анархичные coreutils). Но я постарался быть объективным. Надеюсь, ничьи чувства не затронул :-)
P.P.S. Я понимаю, что в моем тексте присутствует несколько достаточно смелых заявлений. Готов ответить за каждое из них :-)

Потратьте время на изучение Powershell. Полагаю, вам оно вернется сторицей и очень быстро.

Говоря о «похороненных сотнях тысяч человеко-часов», Вы тут же предлагаете мне продолжить обряд погребения, но уже с другим телом? :))

«Много букв», много эмоций, но суть осталась всё та же: различие во взглядах, мнениях, подходах.
Я останусь при своём мнении.

И да, минусующие могут продолжать минусовать. :)
Мне известно, что здесь именно так принято «доказывать свою правоту». :))

Нет, уровень вхождения в написание posh-скриптов — очень невысокий, а время на обучение измеряется единицами часов. А главное — Powershell очень часто "подсказывает" человеку, что надо делать. Слышали про IntelliSense?

Мой любимый вопрос: зачем?? :)

Зачем, если существующие задачи прекрасно решаются уже имеющимися средствами, имеющимися в системе? К чему множить число сущностей?
Мне это не нужно. «Принцип МНВ» — моё «всё». :)
Мой любимый вопрос: зачем?? :)

Например мне будет проще. Это же просто инструмент.

Вот пока я не купил машину — я тоже задавался вопросм: зачем? Ведь все транспортные задачи "прекрасно" решались кроссовками, велосипедом, автобусами и такси! Так же, как и моя пожилая мама долго не понимала, зачем ей нужен мобильный телефон при наличии стационарного домашнего? К чему множить число сущностей? :-)
Сходу отвергать использование нового инструмента, слабо представляя его функционал, и при этом утверждать, что старым инструментом задачи решаются "прекрасно", не совсем логично :-)

А куда там ИЛИ? 2G или "*bak*"?
find . -maxdepth 0 -ctime  -222 ! -newermt "2016-07-07" \( -size +2G -o -name "*bak*" \)
Любопытно, я не знаю синтаксиса PS но могу прочитать, что там куча условий на размер и дату создания ИЛИ *bak* в имени.

Кстати, +2G это больше или меньше 2гб?
Логично, что больше, а '-2G' — меньше. Так и есть. Правда не ясно, почему было не использовать '>2G' и '<2G'.

Потому что > и < — спецсимволы баша, их бы пришлось экранировать.

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

find -size -2G -ctime -222 -not -newermt 2016-08-17
find -name '*bak*'


с OR заморачиваться не стал — это, как раз, неинтуитивно.
Судя по предыдущим комментам с OR будет так, да?
find -size -2G -ctime -222 -not -newermt 2016-08-17 -o -name '*bak*


А вот это означает дата изменения не меньше? (Я правда хочу понять синтаксис)
-not -newermt 2016-08-17 
-newermt (mt — modification time, есть ещё at — access time и ct — create time) — дата модификации свежее, чем указанная.

-not (или просто !) — отрицание последующего условия.
Как тут уже обсудили, это все делает find. А вот давайте что-нибудь веселее: например, потом взять этот список файлов и найти файлы, присутствующие в этом списке, но отсутствующие в git-репозитории, после чего скопировать их туда.

А так не вижу смысла осваивать то, чего ни на одном сервере не будет. Я даже zsh-ем и прочими «более продвинутыми» шеллами не пользуюсь, чтобы не создавать привычек. А bash есть везде.
ваше желание не использовать сторонние утилиты показывает ваше непонимание unix-way, в котором это даже не обсуждается. Bash изначально предполагался как один из инструментов, а не комбайн сам в себе.

Если же взять, например, ваш powershell, как им найти все папки с одинаковым iNode? Никак? То есть сразу весь повершелл бесполезен.
Unix-way предполагает, что вы можете настрогать сложный скрипт из готовых утилит, и если чего-то не хватает, дописываете еще одну маленькую утилиту, которая делает недостающую функцию. Все остальное — уже есть. И ставить условие «не использовать core или gnu utils, тем более то что вы перечислили входит в поставку практически каждого дистрибутива линукса — это категорически нечестная постановка задачи.
Ну, вот такой подход… И «минусы», как «последний аргумент», при их полном отсутствии.

Согласен, по существу. Голосовать, к сожалению, не могу, поэтому вот так: "+". :)

Вы абсолютно не поняли меня. Не было у меня такого желания и никаких условий я не ставил. Я просто отметил, что скрипты на Powershell очень часто бывают самодостаточными (здесь, как и в юниксах, "всё придумано до нас", только вместо coreuitls "из коробки" используются так называемые командлеты "из коробки"). Очевидные преимущества такого подхода — это управляемый, гибкий, эластичный и единообразный синтаксис, а также возможность отладки скриптов "взрослыми" методами: с точками останова, слежением и модификацией переменных, а не раскидыванием отладочных echo по коду.
Утилиты в Posh-e дописывать ничуть не сложнее, не выходя из среды разработки, а уж если автор скрипта знает программирование .NET… Кроме того, нет абсолютно никакого запрета на вызов из Powershell любой другой программы (хоть ту же find или даже bash-скрипт) и "парсить" ее вывод. Более того, даже текстовый вывод из консольных утилит можно превратить в объект .NET и использовать его со всеми вытекающими отсюда "вкусностями". Возможно, для многих, читающих эти строки, все написанное мною звучит дико, но на самом деле всё это имеет вполне практический смысл.

Кто осмелится скомпилить последний PowerShell под Windows 7, а может даже под XP?
Это пятая версия, на гитхабе шестая лежит, и бинарники собраны только под 8.1 и 10.
Ну и на XP старше второй ничего не вижу))
Выход в open source — это благо для любого проекта.
Одни получают возможность изучать исходники и самообразоваться, особенно если знаешь, на что обращать внимание.
Другие получают возможность взять в руки напильник и… дальше сами знаете: добавить пару фич, нужных именно вам, исправить пару багов, воркэраунд для которых требовался ещё вчера и т.д.
Если подумать, огромное количество народу получает профит, счастье всем.
Но нет, всё равно находятся хэйтеры, способные паразитировать на таких актах маленького чуда. Как?!
Ну не преувеличивайте. Никакого чуда в этом нет, это просто очередная попытка Маленькогософта пропихнуться в неохваченную ими сферу. Не получилось ОСями, пробуют тулзами. Конечно, еще «пара кружек» кода в море open source это хорошо.
Вот-вот. PowerShell не самая бесполезная поделка Microsoft, к тому же. Как linux shell основной он, понятное дело, не нужен (zsh, python/ruby). А вот для тех, кому нужно админить винду, отдавать клиентам домена с samba скрипты настройки, профилей. Или например записать кроссплатформенные сборки/генерации кода в каком-нибудь репозитории, чтобы собирать или конфигурить и на винде и из других системах (при open source PowerShell, проще поставить его на linux, к примеру, чем городить на win огороды с cygwin/mingw, чтобы можно было в bash). Да и как замена пакетных файлов на винде, мне кажется, он всяко лучше подходит чем python. Не удобно на винде без нормального пакетного менеджера, так что если PowerShell будет на ней по-дефолту, а на linux или что-то другое его можно будет без проблем поставить или добавить в зависимости — не проиграет от этого никто, это точно.

Да кстати, как админ интерфейс для контроллера домена на samba должен он отлично подойти.
Что бы не качать проприетарные виндовые утилиты.

Если они действительно так любят Linux, то почему не обновят Skype?

Оффтоп, но обновляют, как могут: https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299 Да, это веб-версия, завернутая в окошко, завернутое в свою очередь в пакет, но работает сносно. Пока практически нет настроек и видеозвонков, в остальном — полный аналог виндового.

У меня к вам два вопроса: где в этом поделие поиск по истории за пол года и сколько багов вы в нем нашли?
Оно не покрывает мои юзкейсы, жрет ресурсы и глючит. На кой черт это нужно?
И да — я больше месяца им активно пользовался, я знаю о чем говорю.

НЛО прилетело и опубликовало эту надпись здесь

Что допилят? Кривожопую загрузку аж целого месяца истории? В том виде как оно работает сейчас — лучше бы не работало вовсе.
Пусть бы выпустили libskype какой-нибудь — сообщество дальше разберется без их "помощи".

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

Голословное заявление. Прошу предоставить доказательства.
сообщество дальше разберется без их «помощи»

Голословное заявление. Прошу предоставить доказательства.
А если серьёзно, то холиворами не занимаюсь. Хотите доказательств, вот вам намёк: De omnibus dubitandum!
сообщество дальше разберется без их «помощи»

Здесь как бы говорить, что — остальное это уже не их проблемы — а не то, что сообщество таки разберется.

пардон, это был ответ в другую ветку

Простите, но без видеозвонков какой в нём смысл? В таком состоянии он не «работает сносно», а не работает вовсе. Полный аналог виндового — это, в смысле, «имеет такой же (чудовищный) интерфейс»? Хм, мне всегда казалось, что скайп если и юзают, то не для этого. :)
Они его любят таким, какой он есть!
По той же самой причине, по которой многие компании вообще отказываются что-либо разрабатывать под Linux в целом (часто разрабатывают под конкретно один или несколько дистрибутивов) — по причине зоопарка. Написать под Windows или Mac — стоит X денег, под Linux — X*Y, где Y — это неизвестная вовсе не образно.
Напишите под Ubuntu, откройте исходники, умельцы сами портируют куда им надо.
Умельцы, прекратите наконец-то городить сотни форков, займитесь качеством и стандартизацией, пофиксите существующие проблемы — и не придётся в очередной раз что-то куда-то портировать и плакаться, что вот, мол, снова на Linux что-то не выпустили.
Так исходники то откройте сначала )
Намёк не поняли… вот вам ещё один: в Windows и в OS X софт умудряется работать. Без открытия исходников. На всех версиях. Проприетарные операционки нам инопланетяне присылают, а?
в Windows и в OS X софт умудряется работать

Естественно, оно же пишется под эти ОСи. Я потому и говорю:
Напишите под Ubuntu, откройте исходники, умельцы сами портируют куда им надо

Как бы говоря — вы хоть под один дист напиште нормально, а дальше уже не ваши проблемы. Если откроете исходники, то вообще прелесно будет. Проблема в том, что скупе даже под один конкретный дист Маленькийсофт написать толком не смог, о зоопарке тут можно даже не говорить.
Проблема в том, что скупе даже под один конкретный дист Маленькийсофт написать толком не смог

Обвинять во всех бедах «Маленькийсофт» — это новая замена старому «у меня всё работает — пользователи дебилы»?
Хорошо, объясняю на пальцах. Скайп — софт, который как минимум задействует: сеть, аудио in-out, видео in-out, UI. Какой из этих компонентов в линуксе стандартизирован или работает на любой (экзотику не берём) машине? Ни один (не спорьте: плаваем, ругаемся, #ненавидимторвальдса). Работает через раз, через машину. В общем рецепт всегда один — нужно пилить.
И вот, значит, «Маленькийсофт» должен заниматься этими проблемами операционной системы вместо разработчиков этой системы. Всегда воинственно и фанатично настроенное сообщество, поддерживающее эту операционную систему — за проблемы это не считает. А если какой производитель софта отказывается выкидывать деньги на ремонт этих костылей — то он редиска и ведьма, подлежит сожжению. Мягко говоря нагло: и разработайте нам, и сырцы дайте, и попилите за нас. Что ещё за вас сделать? Всё сделаем — говорят в Linux сообществе любят оплачивать труд! (последнее предложение — сарказм)
Дабы вы не сочли меня защитником «Маленькогософта» — поинтересуйтесь почему большинство крупных производителей софта отказываются производить под Linux. Забегая вперёд скажу: потому что никто не хочет решать проблемы, на которые само сообщество Linux'а плюёт.
Поэтому повторюсь — перестанет сообщество страдать хернёй, нормально решит свои проблемы — и производители на Linux потянутся.
Обвинять во всех бедах «Маленькийсофт» — это новая замена старому «у меня всё работает — пользователи дебилы»?

На весь ваш коммент я могу ответить одним замечательным фактом — до того, как Маленьокийсофт купил скайп, я им пользовался и он работал отлично! работали видеозвонки в групповых чатах, работала передача файлов без танцев с бубнами, работал шарниг рабочего стола — как только он был куплен, все эти функции разом перестали работать на моей старой Ubuntu 12.04. Поверьте, ничего в составе ядра или библиотек у меня не менялось, просто новые владельцы скайпа либо криворукие, либо осознанно испортили ПО.
Skype купили. Что хотят, то и делают. А начали с обновления архитектуры. Возвращаемся к моим словам: «если какой производитель софта отказывается выкидывать деньги на ремонт этих костылей — то он редиска и ведьма, подлежит сожжению». Если бывшие хозяева Скайпа хотели выделять ресурсы на Линукс версию — то это не значит, что новые должны выделять.
Наша компания, в частности, часто закрывает проекты Линукс клиентов, т.к. разработка под Линукс — весьма дорогое удовольствие, учитывая весь зоопарк и отсутствие стандартизации.
Skype купили. Что хотят, то и делают

Ну так с этого и следовало начинать и этим стоит закончить ) Вам удачи.
Вот вам на вскидку пара статей про конкурент Скайпа — Вайбер. Установка на Линукс.
http://www.linuxrussia.com/2015/03/viber-ubuntu.html
http://linux-user.ru/distributivy-linux/programmy-dlya-linux/viber-dlya-ubuntu-linux-mint/

Смотрите сразу комментарии. Снова Маленькийсофт виноват?

P.S.
Естественно, оно же пишется под эти ОСи. Я потому и говорю:

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

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

Я вам показываю корень проблем Линуксов.
под какой нить один дист

А какой из них работает без пилы?
Я вам показываю корень проблем Линуксов

А какой из них работает без пилы?

Так пилите под убунту. Будет вам счастье и, возможно, поддержка комьюнити. А, ну да, чуть не забыл, прежде чем пилить, хорошенько изучите ядро и окружение, это важно!
Вот повторяю вопрос:
А какой из них работает без пилы?

Вы думаете Убунта — панацея? Один из лучших дистрибутивов — да. Но все проблемы, которые требуют допила — не отменяет.
Пилить, безусловно, необходимо в любом проекте. Но если сравнить программирование под Windows и OS X c Линуксом — то это как обработка наждачкой, иногда напильником vs. лесопилка.

P.S.
хорошенько изучите ядро и окружение

я думаю, это само собой подразумевается.

Ок-ок!


Вот вам на вскидку пара статей про конкурент Скайпа — Вайбер.

Да? У них появился поиск по истории?!


А какой из них работает без пилы?

А Windows всегда работает гладко? Везде? За вас погуглить проблемы Viber под Windows? А может погуглить проблемы несовместимости между версиями Windows?


Или может за вас погуглить проблемы свежих версий Skype под Android?


Пускай откроют протокол — куда его приткнуть — придумаем.

Погуглите проблемы в Vista ) Это пустой разговор, есть очевидные факты на которые можно закрывать глаза, но от этого они не исчезнут — проблема не в Linux, проблема в целях Маленькогософта.
А какой из них работает без пилы?


Fedora, например. А что? :)

И — да-да, тот самый, который вечно в разработке. Работает, сволочь! Всё никак времени не найду, чтобы пожаловаться… .:))

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

Ждём статьи от PVS-Studio. Сколько там ошибок найдёт их статический анализатор?
Для 32-разрядной архитектуры (Intel Atom) я так понимаю [пока] недоступен, и самостоятельная сборка весьма не тривиальна?
Да, пару месяцев назад https://habrahabr.ru/post/278767/
НЛО прилетело и опубликовало эту надпись здесь
https://www.microsoft.com/en-us/cloud-platform/sql-server-on-linux
Радует настоящая свободная лицензия. В отличие от.
Объясняю тем, кто минусует: GPL код может быть использован только в GPL проекте. Хотите использовать GPL библиотеку в своем проприетарном продукте — идете лесом. Хотите использовать GPL библиотеку в открытом проекте с лицензией MIT, например, — тоже идете лесом. Это никак нельзя назвать свободой.
Почему нельзя?? Вы же можете свободно использовать продукт под этой лицензией в рамках лицензии. Обычное же дело… :)

И, кстати, а откуда возник GPL?

Вот же: «PowerShell is licensed under the MIT license.»
Радует настоящая свободная лицензия. В отличие от.

Перевожу для тех, кто не понял:


Радует настоящая свободная лицензия (MIT). В отличие от GPL.


— И.О. К.О.

Повторюсь… Эта надпись у него за спиной — образец ихнего лицемерия
ихнего
Пишете ерунду — так хотя бы по-русски. :(
не русских
Совсем беда.
Впрочем, неважно.
Полностью с вами согласен — беда!
Со всем уважением — да займитесь уже делом.
Ваши убеждения устарели на пару лет.
Убеждения устарели? ) Это все, что вы можете ответить?
Сдаётся мне, что майкрософт решили задушить коммерческие дистрибъютивы на основе линукс в «дружеских объятиях».

После прочтения комментариев, снова взглянул на заголовок статьи — "Microsoft открыла исходный код PowerShell".
… открыла исходный код… Microsoft… и понеслось — линуксоиды негодуют, изливают тонны ненависти. Вот недаром линуксоидов считают IT аналогом религиозных фанатиков. А между прочим Microsoft делает очень много для Linux.

Не начинайте. Фанатики есть с обоих сторон и сложно сказать где их больше и где они громче. Ну и open source сообщество делает много того, что используется и Microsoft'ом.

Патологоанатомы тоже делают очень много для людей. :)

Написали свой комментарий так, будто патологоанатомы делают что-то плохое.
Очередной демагог?

«Вас это беспокоит? Хотите об этом поговорить?..» © :)

Пожалуйста, не надо переносить на меня Ваше субъективное восприятие моего текста. :)
Критикуют милую Вашему сердцу Microsoft вовсе не за «открытие исходного текста». Да и в критике нет ничего плохого, зря Вы это так болезненно воспринимаете.

P.S. И, насколько я помню русский язык, вопросительный знак в подписи — это уже лишнее…