Понял. Значит, сравнивать его с Bash и прочими «нормальными» оболочками некорректно, потому что это узкоспециализированный инструмент администратора, тогда как Bash — именно что пользовательская оболочка. Иначе бы он уже запускался именно в качестве общей оболочки, но даже в десятке этого нет — там по-прежнему в качестве оболочки командной строки используется cmd.exe.
Вы сейчас спросили, как приготовить мороженое в натопленной бане :).
Потому что задали совершенно конкретный ключ, который влечёт за собой вывод списка файлов в совершенно конкретном формате, который совершенно не обязательно содержит год.
Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.
Увы, не припомню такой. Разве что запуск, по сути, отдельного приложения «Командная строка», но это не то. Консоль там открывается одной комбинацией в директории текущей панели, работает с файлами из этой панели (например, передаются выделенные в панели файлы)? Подробности, как это делается в FAR, я сейчас не вспомню, помню только, что как-то делается, а вот в Midnight Commander достаточно использовать placeholder %s и выделенные файлы будут вставлены в командную строку.
Главное преимущество Bash (shl, csh, tcsh, ksh etc) в том, что это именно оболочка, команды которой можно «сложить» в файл и получится новая команда. Причём, сами команды легко читаются и понимаются «без перевода». Проблема command.com и его наследника cmd.exe в том, что вторая часть там реализована плохо: код, написанный на их программном языке читается с трудом, у них куча невразумительных конструкций, которые простым прочтением мануала не проясняются — надо ещё долго укладывать в голове какие-то странные многожтажные условные обозначения. Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас. А PowerShell во многом его унаследовал, так что стройного языка не получилось.Какой этот синтаксис сейчас, я не знаю, но тогда, когда я пытался писать скрипты заказчикам, это был тихий ужас.
Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.
В WinXP его надо было ставить руками, насколько я помню. Если всё равно что-то ставить, то я предпочитаю интерпретатор нормального языка программирования. Опять же, как Вы сами указали, удобоваримым он стал с третьей версии, а я успел от него отказаться, ещё когда он, видимо, ещё из первой не вырос.
А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.
Пробовал работать с Cygwin и MSys2. В обоих случаях создаётся песочница, корневая директория, в которой всё и работает. Выход за её пределы возможен и сделать это не особо сложно, но всё равно это именно песочница. И все прелести такой организации прилагаются: дополнительные действия по перемещению корня куда-то, выход на корневые директории дисков Windows через какие-то странные структуры и так далее. Примерно такой же геморрой, как и при работе с WINE под Linux. Если мне нужны какие-то программы, у которых есть нормальные сборки под Windows, я не могу их использовать — система пытается установить то, что есть у неё в репозиториях, а это, зачастую, устаревшие на несколько лет версии. При этом, тянется, к примеру, собственная версия GTK, даже если у меня в системе уже есть программы, для которых установлена эта библиотека. То есть такая вот изолированная область с софтом в стиле *nix.
С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.
Я тоже так делаю, когда приходится иметь дело с этой ОС на хоть сколько-то постоянной основе. Но эти утилиты работаю… не очень хорошо, потому что установка по умолчанию настраивает пути так, что они рассчитаны на работу в своей песочнице и вывести их на «просторы» основной файловой системы очень сложно. К тому же, у Windows отстойно реализованы конвейеры. Я полтора года назад работал в одной странной конторе, где на все машины была установлена винда и работать приходилось в ней, хотя всё, что я писал, должно было работать в Linux. В итоге, у меня была возможность сравнить работу этих утилит одновременно и в винде, и в Linux. Увы, даже на куда более мощной машине с Windows они работали гораздо медленнее, чем на слабенькой виртуалке и древнем нетбуке (моём личном).
Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.
Я когда-то пытался разобраться с PowerShell, но его надо было ставить отдельно, это было маятно и всё равно пришлось бы ставить заказчику на машину руками. В общем, по моим ощущениям, он мало чем отличался от стандартной досовой оболочки. Возможно, я уже неправильно помню. Собственно, в винде главныая проблемв в плане консоли и того, как её привыкли видеть в более нормальных ОС — нет встроенного интерпретатора для написания скриптов. JScript и VB не в счёт, потому что там, насколько я помню, отсутствуют встроенные средства для работы с чем-либо вообще: каждый раз приходится задействовать шаманства, подгружая какие-то внешние библиотеки. Внешние по отношению к языку. Это как в программе на Python или C запускать внешнюю программу. Только там это делается для ненаписания своих велосипедов или чтобы использовать какие-то тяжеловесные инструменты, вроде Tesseract для распознавания текста с изображения или mencoder для перекодирования видео, а тут — по любому поводу. То есть не получается написать свою маленькую программку, не встревая в дебри WinAPI, тонкостей OLE, COM, DCOM и прочих ActiveX. А отсутствие возможности вот так, «на коленке», написать мелкую программку убивает саму идею отсутствия чёткой границы между использование программы и её написанием, а следом и консоль, потому что программирование это только для программистов. И завтрак должны готовить только профессиональные повара.
Они, собственно, и сейчас не работают: если использовать относительный путь, то, как я понял из экспериментов, без разницы, какой длины полный, а вот если отдавать полный, программа давится и умирает. Поэтому ничего не изменится, кроме того, что новые программы уже будут писать правильно.
FAR предоставляет полноценную консоль, как, в своё время NC и VC. У Total Commander консоли нет, что часто бывает крайне неудобно. Но да, вкусовщина.
Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами. Но даже без неё работать в винде очень сложно.
Может быть. Когда я выяснял, в чём разница между двумя файлами, то у одного путь был короче 255 символов, а у другого длиннее. Вполне возможно, что длина была больше 260: я этот момент не запомнил, меня поразил сам факт наличия ограничения, причём, настолько жёсткого.
Решил проверить и наткнулся на вот эту статью: Сравнение файловых систем/Ограничения. Дошло, что длина имени файла и длина пути в NTFS совпадают. В очередной раз выпал в осадок.
Кстати, не 260 тогда, а 259, потому что NULL — завершение строки вообще и к пути, как таковому, отношения не имеет.
О, да! Как-то помогал бабушке выяснять, почему у неё не открываются документы. Она пишет историю семьи, раскопала всякого больше чем на 400 лет назад, так что вложенность директорий впечатляющая, а названия — как у средневековых рыцарских романов. Выяснилось, что вот именно из-за них и проблемы: не ест винда (или Проводник) имена длиннее 255 символов. Кстати, из DOS ограничение-то. Но тогда полная длина имени была не более 12 символов (8 — имя, точка и 3 — расширение) и чтобы выбрать лимит надо было собрать путь их 20 компонентов в глубину при максимальной длине имени. Мне даже в голову не сразу пришло, что в 21 веке в современной ОС могут быть такие косяки.
Может быть и так — не считал, а сейчас уже спать пора и мне, честно говоря, лень. Но тут есть один момент: до Луны банально ближе и есть возможность оперативной доставки груза, пусть это и будет стоить невменяемых денег. А вот до Марса так телепать придётся долго, поэтому надо искать источники энергии только на месте. То есть сколько-то топлива и панелей можно будет забросить на начальном этапе, но надеяться на поставки с Земли — самоубийство. Кроме того, помним, что на Луне плотность солнечного излучения составляет тот же 1 кВт/м2 что и на Земле, а то и больше, с учётом исключительно формально присутствующей там атмосферы, тогда как до Марса Солнце досвечивает гораздо хуже, да и атмосфера, пусть и дохлая, там есть и «малину портит». То есть тех панелей понадобится куда больше.
В общем, с Марсом всё пока печально: надо не просто туда забросить группу «туристов», но и обеспечить им там производство всего, что может понадобится, потому что про оперативное возвращение можно забыть в принципе. Это с Луны можно вернуться в течении двух-трёх дней, а с Марса — полгода в лучшем случае (не помню, сколько туда зонды пилили).
Вроде бы были такие проекты, но не на уровне «загрузить в корабль и забросить на Луну», а на уровне «сложим запас на чёрный день, а когда всё накроется тазом медным и ванной чугунной, возродим цивилизацию». Источники сейчас не найду, потому что было это давно, пообсуждали эту тему на тусовке, в проекте использовали и забыли. Но, в принципе, и для космоса можно построить такой корабль-завод по производству всего и сгрузить в точку основания колонии. Самому теперь досадно, что ссылки не сохранил.
Построить доменную печь можно, но вот толку с неё? Если я правильно помню, химических состав у Луны примерно такой же, как у Земли, то есть железо там имеется, но вот каменного угля, ввиду отсутствия растений, не водится. То есть толку именно с доменной печи будет ровно ноль. Тут нужны другие технологии. Но главной проблемой там будет энергия: на Земле есть ГЭС и АЭС, но для первых нужна не просто вода, а много воды, причём, жидкой, а вторые строятся долго и топливо для них добывается специальными заводами, которые тоже надо построить. И если на Луну ещё как-то можно забрасывать уран или плутоний и солнечные панели, то с Марсом такое не выгорит — далеко. То есть надо сразу закладывать добывание и строительство чего-то, что обеспечит тот принтер энергией. Будет энергия — будет и остальное сырьё.
Насколько я себе представляю процесс, очищать его можно прямо в процессе сжижения: метан сжижается последним, поэтому достаточно просто слить всё, что стало жидким по достижении определённого давления и наличии останется только метан. Ну или перекачать то, что газообразное, на следующий этап, что, по сути, то же самое. Правда, не знаю, какой уровень чистоты получается таким примитивным способом.
Посчитал, сколько заливается керосина в Falcon9 — да, там его на четверть миллиона долларов получается. Учитывая, что старт стоит в районе 50-60 миллионов, разница и впрямь невелика будет. Значит, какой-то смысл переходить на метан появляется только при переходе на многоразовые аппараты, которые летают как самолёты (по частоте: заправил, слетал, снова заправил и снова полетел). То есть когда оборудование перестаёт теряться.
Кстати, цену метана так и не нашёл. Наверное, неправильно вопрос задал: в выдаче только про ГБО и мелкие объёмы уровня 40-литровых (кажется) баллонов.
Потому что задали совершенно конкретный ключ, который влечёт за собой вывод списка файлов в совершенно конкретном формате, который совершенно не обязательно содержит год.
Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.
Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.
А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.
С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.
Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.
Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами. Но даже без неё работать в винде очень сложно.
Решил проверить и наткнулся на вот эту статью: Сравнение файловых систем/Ограничения. Дошло, что длина имени файла и длина пути в NTFS совпадают. В очередной раз выпал в осадок.
Кстати, не 260 тогда, а 259, потому что NULL — завершение строки вообще и к пути, как таковому, отношения не имеет.
В общем, с Марсом всё пока печально: надо не просто туда забросить группу «туристов», но и обеспечить им там производство всего, что может понадобится, потому что про оперативное возвращение можно забыть в принципе. Это с Луны можно вернуться в течении двух-трёх дней, а с Марса — полгода в лучшем случае (не помню, сколько туда зонды пилили).
Построить доменную печь можно, но вот толку с неё? Если я правильно помню, химических состав у Луны примерно такой же, как у Земли, то есть железо там имеется, но вот каменного угля, ввиду отсутствия растений, не водится. То есть толку именно с доменной печи будет ровно ноль. Тут нужны другие технологии. Но главной проблемой там будет энергия: на Земле есть ГЭС и АЭС, но для первых нужна не просто вода, а много воды, причём, жидкой, а вторые строятся долго и топливо для них добывается специальными заводами, которые тоже надо построить. И если на Луну ещё как-то можно забрасывать уран или плутоний и солнечные панели, то с Марсом такое не выгорит — далеко. То есть надо сразу закладывать добывание и строительство чего-то, что обеспечит тот принтер энергией. Будет энергия — будет и остальное сырьё.
Кстати, цену метана так и не нашёл. Наверное, неправильно вопрос задал: в выдаче только про ГБО и мелкие объёмы уровня 40-литровых (кажется) баллонов.