Комментарии 268
Не понял фразы. "Программа пришла на смену управлению файлами в MS-DOS и стала заменой многочисленным файловым оболочкам вроде Norton Commander, хотя многие пользователи по привычке ещё долгие годы пользовались NC и Windows-версией Total Commander."
Тотал фар и т.п. обладают мягко говоря куда большими возможностями. Именно поэтому они применяются до сих пор, хотя и заметно меньше.
Вполне нормальная фраза.
На смену управлению файлами в MS-DOS, диспетчер файлов пришел в ранних версиях Windows.
На тот момент ни тотала ни фара еще не было, они появились уже во временя win-95, если не во время OSR-2.
На смену управлению файлами в MS-DOS, диспетчер файлов пришел в ранних версиях Windows.
На тот момент ни тотала ни фара еще не было, они появились уже во временя win-95, если не во время OSR-2.
Был Dos Navigator. Собственно из того что я видел, все переходили NC->Dos Navigator, потом в винде уже ->Far или ->Total Commander. Я ни разу не видел в своем окружении, чтобы тот, кто ими пользовался, перешел на стандартный проводник.
тотал(тогда еще windows) появился в 93 году
Тотал появился позже, но до него был Norton Commander, это ПО еще с седых времен DOS было.
DN появился кажется еще в 91году.
хотя многие пользователи по привычке ещё долгие годы пользовались NC и Windows-версией Total Commander
До сих пор для меня Far — основной файловый менеджер :) Перешел на него с Norton Commander, Total мне не пошел.
FAR или синяя табличка (как его некоторые называют) — это навсегда!
Volkov Commander forever!!!
Far? Да ты шутишь. Или ты про CLI?
Не, я серьезен. Far 2.0.1420 :)
Хорошо, но на какой системе? Я о том, что пользоваться этим на какой нибудь винде (тоесть с GUI) было бы странно.
Я только в винде и работаю. С линуксом я очень сильно на "Вы", могу только раз в пару месяцев подправить или обновить что-то на удаленном сервере хостинга :)
А чем пользоваться-то? Проводником, прости господи?
Сидел на Far в любых версиях винды, от 98 до 10 включительно и никуда слазить не собираюсь.
Сидел на Far в любых версиях винды, от 98 до 10 включительно и никуда слазить не собираюсь.
Особенно удобен FAR при разгребании коллекций фоток, ага.
Каждый инструмент в чем-то удобен, в чем-то нет.
Каждый инструмент в чем-то удобен, в чем-то нет.
Для файлового менеджера фотки — это один из сотни возможных сценариев, частность. Для фотоколлекций абсолютно любой файловый менеджер будет не самым удачным выбором и лучше воспользоваться специализированными программами.
Но кстати сказать, картинки просматривать Far умеет, есть соотвествующий плагин, пользуюсь регулярно.
Но кстати сказать, картинки просматривать Far умеет, есть соотвествующий плагин, пользуюсь регулярно.
Вообще-то фар очень удобен при разгребании коллекций фоток, если пользоваться встроенным просмотрщиком. Можно при просмотре фотки ее сразу выделять, а затем нужнаяоперация выделенные файлы
Активно использую mc на макбуке, очень удобно. Не мышкой же файлы выделять, право дело.
FAR всё ещё весьма популярен на Windows. Я-то подсел в начале 2000-х сразу на Total Commander, но многие мои знакомые продолжают до сих пор пользоваться FAR'ом. На самом деле отличия не принципиальны, плагинов полно везде. Не путайте интерфейс с функциональностью, с ней у FAR всё в порядке, и это полноценное win32-приложение, в отличие от DN.
Ничего страшного. Когда-то многие и Оперу вместо браузера использовали.
Лучше бы Explorer выложили, раз сами не могут сделать в нем поддержку длинных путей.
Включение в политиках не помогает?
Даже в документации MS этот вопрос до конца не прояснён: в одном месте написано, что этого достаточно, а в другом — что ещё и у конкретного приложения в манифесте должны быть разрешены длинные пути.
Даже в документации MS этот вопрос до конца не прояснён: в одном месте написано, что этого достаточно, а в другом — что ещё и у конкретного приложения в манифесте должны быть разрешены длинные пути.
Вы мне меня же цитируете) Очевидно что не помогает.
Нет, не помогает.
О, ещё одно тайненькое знаньице для решение проблемы, которой могло просто не быть, и решение которой тривиально.
Во-первых, для проводника не помогает.
Во-вторых, для прочих приложений, просто не требуется, если они нормально написаны. Тотал коммандер, например.
О, да! Как-то помогал бабушке выяснять, почему у неё не открываются документы. Она пишет историю семьи, раскопала всякого больше чем на 400 лет назад, так что вложенность директорий впечатляющая, а названия — как у средневековых рыцарских романов. Выяснилось, что вот именно из-за них и проблемы: не ест винда (или Проводник) имена длиннее 255 символов. Кстати, из DOS ограничение-то. Но тогда полная длина имени была не более 12 символов (8 — имя, точка и 3 — расширение) и чтобы выбрать лимит надо было собрать путь их 20 компонентов в глубину при максимальной длине имени. Мне даже в голову не сразу пришло, что в 21 веке в современной ОС могут быть такие косяки.
Может быть. Когда я выяснял, в чём разница между двумя файлами, то у одного путь был короче 255 символов, а у другого длиннее. Вполне возможно, что длина была больше 260: я этот момент не запомнил, меня поразил сам факт наличия ограничения, причём, настолько жёсткого.
Решил проверить и наткнулся на вот эту статью: Сравнение файловых систем/Ограничения. Дошло, что длина имени файла и длина пути в NTFS совпадают. В очередной раз выпал в осадок.
Кстати, не 260 тогда, а 259, потому что NULL — завершение строки вообще и к пути, как таковому, отношения не имеет.
Решил проверить и наткнулся на вот эту статью: Сравнение файловых систем/Ограничения. Дошло, что длина имени файла и длина пути в NTFS совпадают. В очередной раз выпал в осадок.
Кстати, не 260 тогда, а 259, потому что NULL — завершение строки вообще и к пути, как таковому, отношения не имеет.
А чего удивительного? Есть over 9000 существующих программ с кодом вида
char path[260];
(ну и далее там хранится какой-то путь). Если ограничения снять, эта программа перестанет работать.
Они, собственно, и сейчас не работают: если использовать относительный путь, то, как я понял из экспериментов, без разницы, какой длины полный, а вот если отдавать полный, программа давится и умирает. Поэтому ничего не изменится, кроме того, что новые программы уже будут писать правильно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Maximum Path Length Limitation
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.
…
To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.
…
To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
Там то же самое было у их OneDrive
Причем в 10-ке только с 1607 есть поддержка длинных путей, но спасают UNC пути в тот же Explorer. Только так и пользуемся в таких ситуациях.
Только FAR, только хардкор. Надо мной коллеги посмеиваются, дескать, что это за нортон коммандер в 2018-ом, но я не представляю, как работать в этом винфайле, в эксплорере. Я начинал работать разрабом в 98-99 году, WinNT (захватил 3.51 только дома, на работе уже 4-ка была; под юнихами как-то прикипел к deco за простоту, но он уж совсем-совсем простой), был тогда дос навигатор виндовый, нортон коммандер заточенный под винду/фат32, потом фар. И всё.
а что еще использовать в 2018-м?
я в нескольких разных полу-ИТ конторах работал с количеством сотрудников от 50 до 500 человек, везде очень активно использовался FAR, даже среди менеджмента и рядовых сотрудников
я в нескольких разных полу-ИТ конторах работал с количеством сотрудников от 50 до 500 человек, везде очень активно использовался FAR, даже среди менеджмента и рядовых сотрудников
а что еще использовать в 2018-м?
Total Commander ничем не хуже. Вкусовщина конечно.
Мне total никогда не нравился как раз тем что он очень похож на обсуждаемый WinFile ;)
а про 2018 год… так тотал старше фара и интерфейс у обоих «устаревший для 18 года», только у фара он так и остался в привычной среде, а тотал казался чуждым уже в 95 винде не говоря уже о современных версиях (P.S. сугубое imho, знаю что ярых поклонников тотала великое множество и меня заминусят)
а про 2018 год… так тотал старше фара и интерфейс у обоих «устаревший для 18 года», только у фара он так и остался в привычной среде, а тотал казался чуждым уже в 95 винде не говоря уже о современных версиях (P.S. сугубое imho, знаю что ярых поклонников тотала великое множество и меня заминусят)
В тотале есть возможность чтения файлов и поиска по содержимому, в том числе с просмотром? Не нашел сразу и копаться лень стало.
FAR предоставляет полноценную консоль, как, в своё время NC и VC. У Total Commander консоли нет, что часто бывает крайне неудобно. Но да, вкусовщина.
Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами. Но даже без неё работать в винде очень сложно.
Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами. Но даже без неё работать в винде очень сложно.
НЛО прилетело и опубликовало эту надпись здесь
Я когда-то пытался разобраться с PowerShell, но его надо было ставить отдельно, это было маятно и всё равно пришлось бы ставить заказчику на машину руками. В общем, по моим ощущениям, он мало чем отличался от стандартной досовой оболочки. Возможно, я уже неправильно помню. Собственно, в винде главныая проблемв в плане консоли и того, как её привыкли видеть в более нормальных ОС — нет встроенного интерпретатора для написания скриптов. JScript и VB не в счёт, потому что там, насколько я помню, отсутствуют встроенные средства для работы с чем-либо вообще: каждый раз приходится задействовать шаманства, подгружая какие-то внешние библиотеки. Внешние по отношению к языку. Это как в программе на Python или C запускать внешнюю программу. Только там это делается для ненаписания своих велосипедов или чтобы использовать какие-то тяжеловесные инструменты, вроде Tesseract для распознавания текста с изображения или mencoder для перекодирования видео, а тут — по любому поводу. То есть не получается написать свою маленькую программку, не встревая в дебри WinAPI, тонкостей OLE, COM, DCOM и прочих ActiveX. А отсутствие возможности вот так, «на коленке», написать мелкую программку убивает саму идею отсутствия чёткой границы между использование программы и её написанием, а следом и консоль, потому что программирование это только для программистов. И завтрак должны готовить только профессиональные повара.
Даже самая первая версия PowerShell очень сильно отличалась от стандартной досовой оболочки и даже от bash (в лучшую сторону).
от баша в лучшую сторону? да банальный grep в том Powershell превращался в
Очень удобно
%command%| Select-String -Pattern %regexPattern%Очень удобно
Вы уже мне про баш-то не зачёсывайте, я на нём часто пишу.
Давайте выберите мне из «ls -l» все файлы этого года.
Давайте выберите мне из «ls -l» все файлы этого года.
Парсить ls настоятельно не рекомендуется
mywiki.wooledge.org/ParsingLs
find. -type f -newermt 2018-01-01
mywiki.wooledge.org/ParsingLs
find. -type f -newermt 2018-01-01
все файлы этого года
Созданные в этом году? Модифицированные в этом году? man find?
Я знаю что такое find. Речь совсем не об этом.
Речь о файлменеджерах?
Речь о том, что в bash по конвееру идут строки, а в PowerShell — объекты.
Это в некоторых случаях важно, спорить не буду. Просто напомню, что строка — это тоже обьект, только очень простой. А с простыми обьектами проще обращаться.
Вот, например, из кучи картинок выбрать картинки с определенными размерами. bash + imagemagick + awk — и за 2 минуты фильтр будет готов, а через 10 минут я про него забуду, за ненадобностью.
Вот, например, из кучи картинок выбрать картинки с определенными размерами. bash + imagemagick + awk — и за 2 минуты фильтр будет готов, а через 10 минут я про него забуду, за ненадобностью.
Вы сейчас спросили, как приготовить мороженое в натопленной бане :).
Потому что задали совершенно конкретный ключ, который влечёт за собой вывод списка файлов в совершенно конкретном формате, который совершенно не обязательно содержит год.
Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.
Потому что задали совершенно конкретный ключ, который влечёт за собой вывод списка файлов в совершенно конкретном формате, который совершенно не обязательно содержит год.
Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.
Всё что угодно сделать можно. Проблема в том, что bash оперирует строками, а вот PowerShell — объектами. Отсюда и вот эти костылёчки, типа -print0. Так что сравнение bash и powershell не в пользу баша.
единственное чем полезен powershell — это управление объектами .net
Не именами файлов, не выводом ls или dir, а возможностью обратиться к конкретной проперти юзера в AD, или даже ячейки excel без сторонних библиотек.
Под Linux, где вместо объектов .net есть /dev, /proc — powershell заметно проигрывает.
Также он заметно проигрывает башу в простоте конструкций и кроссплатформенности.
Не именами файлов, не выводом ls или dir, а возможностью обратиться к конкретной проперти юзера в AD, или даже ячейки excel без сторонних библиотек.
Под Linux, где вместо объектов .net есть /dev, /proc — powershell заметно проигрывает.
Также он заметно проигрывает башу в простоте конструкций и кроссплатформенности.
По кроссплатформенности — пожалуй (хотя есть кривой posh), а по простоте конструкций всё же не критично. Зато там нет беды с экранированием пробелов в именах, например, и прочего обо что все спотыкаются постоянно.
Есть уже Powershell Core
Как раз наоборот: Bash оперирует теми же типом объектов, что и пользователь, то есть человек. Поэтому Bash — оболочка, а PowerShell — инструмент для администрирования, с которым обычный пользователь и не должен сталкиваться. Потому PowerShell не обязан быть удобным для ежедневного использования для чего-то отличного от управления объектами .NET, как написали выше.
Да кто сейчас в Линуксе сталкивается с башем, кроме админов-то?
Как ни странно, многие. Вот я ни разу не админ, а пользуюсь. Потому что удобно. И, Вы не поверите, но в MacOS X рядовые пользователи тоже используют консоль, в которой — вот неожиданность! — запускается всё тот же Bash. А всё потому, что удобно. Потому что Bash, как я уже написал, оперирует теми же типами объектов, что и пользователь. Потому что он изначально — именно пользовательская оболочка.
У меня другая статистика использования консоли на «Маках», у меня у самого «Мак» (но я не рядовой пользователей), а вокруг очень много менеджеров с ними же. Они вообще не знают, что такое консоль. Далеко не все даже спотлайтом-то пользуются.
Ну… Я видел инженеров, настраивающих связь у абонентов, которые консолью пользоваться не умели. То есть виндовой консолью ещё как-то пользовались, а вот с Bash управиться не могли и моя жена им на пальцах объяснял. Замечу, это профессионал, то есть человек, которому за такую работу деньги платят, и домохозяйка, которая в Linux только кино смотрела, документы в OpenOffice правила и по интернету лазила.
Это к тому, что у нас выборки разные и слишком маленькие, чтобы быть репрезентативными. Я писал про своих клиентов, которых не особо затруднял запуск скрипта из командной строки в MacOS X. Был только один случай, когда заказчик с этим не справился. А вот те, кто пользуется Windows не справляются регулярно. Вплоть до того, что они не знают, что такое файл и что такое директория, что обнаруживается уже на этапе приёмки работы. Вплоть до того, что один явно изъявил согласие на интерфейс командной строки, не зная, что это такое.
Это к тому, что у нас выборки разные и слишком маленькие, чтобы быть репрезентативными. Я писал про своих клиентов, которых не особо затруднял запуск скрипта из командной строки в MacOS X. Был только один случай, когда заказчик с этим не справился. А вот те, кто пользуется Windows не справляются регулярно. Вплоть до того, что они не знают, что такое файл и что такое директория, что обнаруживается уже на этапе приёмки работы. Вплоть до того, что один явно изъявил согласие на интерфейс командной строки, не зная, что это такое.
Разработчики, тестировщики.
Пользователи консольных утилит. В отличие от powershell, основы баша невероятно просты.
Тот же ffmpeg запустить, чтобы на даче с камеры видео сжимать/править — скриптик написал из двух строк и все.
Пользователи консольных утилит. В отличие от powershell, основы баша невероятно просты.
Тот же ffmpeg запустить, чтобы на даче с камеры видео сжимать/править — скриптик написал из двух строк и все.
Ну, разработчики, тестировщики… я имел ввиду простых пользователей, а не айтишников.
Тот же ffmpeg запустить, чтобы на даче с камеры видео сжимать/править — скриптик написал из двух строк и все.Я не пробовал, но уверен, что на powershell будет примерно так же.
на линуксе?
Я думал мы не про операционные системы говорим. Ну пусть будет на Линуксе: github.com/PowerShell/PowerShell
Как раз наоборот: Bash оперирует теми же типом объектов, что и пользователь, то есть человек.
Белковые люди оперируют не строками, а папками, документами, фотографиями и т.п. Именно в эту сторону и развивалась стандартная оболочка Windows, т.е. explorer.
(Можете сами спросить свою бабушку, оперирует ли она строками.)
Клавиатура у компа создана для работы со строками.
В нутре это самой вашей виндовз — строки, много строк. Сравниваются, сортируются…
Имя любого файла/каталога — строка.
В нутре это самой вашей виндовз — строки, много строк. Сравниваются, сортируются…
Имя любого файла/каталога — строка.
Учитывая, что сейчас у меня в руках том формата А4 на 550 с хвостиком страниц со списками и таблицами, описывающими историю моих предков за больше чем 400 по материнской линии, видимо, всё-таки строками. Текстовый документ состоит из строк, если что. Обозвав директорию папкой, ни Вы, ни сочинители из Apple ничего не изменили. А вот путаницы двойная иерархия устроила много, потому что, как только возникает техническая задача, пользователь внезапно осознаёт, что всё строено иначе, чем показывает ему поделие MS. Потому что в реальном мире папка находится на столе, который стоит в кабинете и так далее, а стол является основой мироздания и вход в туалет, душ и архив, внезапно, находятся не на нём, а за дверью кабинета.
«Держа в руках книжку, человек оперирует строками, потому что текст состоит из строк» — примерно такая же демагогия, как «держа в руках книжку, человек оперирует глюкозными цепочками, потому что бумага состоит из глюкозных цепочек».
Это не демагогия, это факт. Но в Вашем варианте речь идёт об оперировании книгой как физическим объектом как набором объектов, его составляющих, а в моём — об оперировании текстовой информацией, составляющей содержания книги. Просто Ваш пример не имеет отношения к обсуждаемой теме.
Бумага, текст, вёрстка, иллюстрации — всё это в равной степени является содержанием книги. (Видели pop-up books? Скажите мне, что физическая составляющая в них второстепенна.) Почему именно текст, и именно в виде строк (а не, скажем, дерева) вы выносите вперёд всего?
мне интересно как Powershell с этим справится, и откуда в Powershell команда ls? minsys установлен?
с помощью bash и на ubuntu (там команды date, ls, awk, grep из коробки) это можно сделать вот так
YEAR=$(date +"%Y");ls --full-time | awk -F " " '{print $6}' | grep -E "^${YEAR}\-"
да, немного ключ пришлось изменить для ls, но мне лень вспоминать корректный синтаксис регулярного выражения для случая ключа -l команды ls. Из возможностей bash тут только присваивание переменной, разделение команд и пайпы. Если не ошибаюсь, это еще command.com из MS-DOS умеет. Не стоит возможности оболочки путать с внешними для оболочки командами. В Powershell наинтегрировали много всего, но удобней он от этого не стал. Да, там наконец реализовали возможности которые были в *nix давным давно, и наконец инегрировали возможности ОС и .Net туда, но в плане написания кода, для меня неудобней только perl (пользуюсь редко, синтаксис быстро забывается). Реально было удобней поставить minsys или cygwin для решения большинства задач.
с помощью bash и на ubuntu (там команды date, ls, awk, grep из коробки) это можно сделать вот так
YEAR=$(date +"%Y");ls --full-time | awk -F " " '{print $6}' | grep -E "^${YEAR}\-"
да, немного ключ пришлось изменить для ls, но мне лень вспоминать корректный синтаксис регулярного выражения для случая ключа -l команды ls. Из возможностей bash тут только присваивание переменной, разделение команд и пайпы. Если не ошибаюсь, это еще command.com из MS-DOS умеет. Не стоит возможности оболочки путать с внешними для оболочки командами. В Powershell наинтегрировали много всего, но удобней он от этого не стал. Да, там наконец реализовали возможности которые были в *nix давным давно, и наконец инегрировали возможности ОС и .Net туда, но в плане написания кода, для меня неудобней только perl (пользуюсь редко, синтаксис быстро забывается). Реально было удобней поставить minsys или cygwin для решения большинства задач.
«ls» в powershell — алиас к Get-ChildItem, многие команды имеют короткие алиасы.
Не везде --full-time существует:
И для точности «ls» к башу отношения не имеет. Кроме того, вы изменили задачу — я вам предлагал «ls -l», вы мне — «ls --full-time». Не надо так.
Я могу решить задачу найти файлы этого года кучей способов (в том числе, убрав из вашей строки grep и переменную), я хотел проиллюстрировать, что строки — отстой, так как они не имеют чётких полей.
Не везде --full-time существует:
$ ls --full-time
ls: illegal option -- -
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]И для точности «ls» к башу отношения не имеет. Кроме того, вы изменили задачу — я вам предлагал «ls -l», вы мне — «ls --full-time». Не надо так.
Я могу решить задачу найти файлы этого года кучей способов (в том числе, убрав из вашей строки grep и переменную), я хотел проиллюстрировать, что строки — отстой, так как они не имеют чётких полей.
Так смысл Bash не в том, чтобы уметь всё внутри себя, а в том, чтобы оперировать файлами, строками и внешними утилитами, которые уже сами что-то там делают. Инкапсуляция, однако.
Строки — это универсальный человекочитаемый формат. Содержимое строки можно проконтролировать глазами. Функция Bash — не администрирование отдельно взятого семейства ОС, а «клей» для организации взаимодействия между специализированными инструментами и общения пользователя с этими инструментами.
Строки — это универсальный человекочитаемый формат. Содержимое строки можно проконтролировать глазами. Функция Bash — не администрирование отдельно взятого семейства ОС, а «клей» для организации взаимодействия между специализированными инструментами и общения пользователя с этими инструментами.
Вы хоть посмотрите-ка как выглядит неперенаправленный никуда вывод в powershell, визуально там табличка. Так что смотрите глазами, кто мешает-то?
Я понимаю идеологию баша, я за консолью линуксов больше 20 лет.
Я понимаю идеологию баша, я за консолью линуксов больше 20 лет.
Простите, но зачем тогда сравнивать теплое с мягким? Вы пытаетесь сравнивать shell ОС (bash) и shell .Net платформы (PowerShell) по большому счету. В таком разрезе нужно сравнивать PowerShell с groovysh. bash удобен тем, что он связывает сущности ОС(потоки) между собой, и делает это хорошо. PowerShell и groovysh работают с сущностями собственных платформ, и тоже делают это. Но мне кажется тут никто даже не понял, что это была попытка сравнения удобства работы с .Net платформой из bash и из PowerShell (судя по упоминанию объектов). bash как оболочка также не подходит для специфических математических операций, в то-же время matlab не очень подходит для операций с доменом ОС. В PowerShell попытались сделать гибрид из ОС shell и .Net shell — как их интеграция он может и лучше чем bash(можно работать с .Net прямо из командной строки), но в случае bash — это делегируется в инструмент, предназначенный для этого, а не интегрируется в bash. Я подозреваю что с такой точки зрения для математиков PowerShell сильно будет проигрывать Matlab'у. Но такое сравнение очевидно некорректное.
Я утверждаю, что PowerShell лучше баша именно как оболочка командной строки. С groovysh я не знаком.
Вот это Powershell (на баше тоже будет работать, но «cat» будет лишним):
и это PowerShell:
А groovysh как выглядит?
Вот это Powershell (на баше тоже будет работать, но «cat» будет лишним):
cat user-agents.log | sort -u
и это PowerShell:
ls | where {!$_.length} | %{rm $_}
А groovysh как выглядит?
ls | where {!$_.length} | %{rm $_}
Я так понимаю, это заклинание на удаление пустых файлов. В проводнике это делается, например, так:
клик мышкой в заголовок поля с размером
промотать список до конца
клик с шифтом
промотать до первого непустого файла
клик с шифтом
del
Проводник проще и быстрее, чем bash вместе с powershell ;)
Откуда тут проводник взялся? Тут был версус PS и баша. Если уж впутывать проводник, представьте, что теперь надо и вложенные папки обработать. В данной строке изменений будет на копейку.
Проводник проще и быстрее, чем bash вместе с powershell ;)
Вы забываете, что ЛЮБАЯ команда в консоли — легко превращается в скрипт, а скрипт легко вызывать например по расписанию.
Нельзя сравнивать GUI и CLI интерфейсы без контекста использования.
Можно сравнивать разные оболочки одного типа, например powershell и bash.
А Вы, со своим проводником, просто видимо никогда не встречаетесь с задачами чуть сложнее чем запустить ярлык.
Например: 10 тысяч файлов в папке. Сколько будете мотать список в вашем проводнике до первого непустого, если он будет например трехтысячным?
Нельзя сравнивать GUI и CLI интерфейсы без контекста использования.
Да. Проводинк, nc, FAR — менеджеры файлов. В каждом из них задача «удалить пустые файлы» решается в несколько щелчков мыши. Это как правило быстрее, чем вспоминать/гуглить/придумывать заклинание для PS/bash.
На shell можно все, и даже больше, да. Но иногда проще не писать однострочник, а взять более подходящий инструмент.
Вы забываете, что ЛЮБАЯ команда в консоли — легко превращается в скрипт
Верно. Но кому, кроме некоторой части профессиональных ИТшников, это может быть нужно? 99.99% кейсов использования любой командной оболочки — это как раз что-то запустить, реже переименовать, удалить, скопировать. Причем не по повторяющемуся шаблону, а однократно. И зачастую с необходимостью предпросмотра содержимого. Так что кроме узкого специального круга задач Проводник действительно проще и быстрее.
Главное преимущество Bash (shl, csh, tcsh, ksh etc) в том, что это именно оболочка, команды которой можно «сложить» в файл и получится новая команда. Причём, сами команды легко читаются и понимаются «без перевода». Проблема command.com и его наследника cmd.exe в том, что вторая часть там реализована плохо: код, написанный на их программном языке читается с трудом, у них куча невразумительных конструкций, которые простым прочтением мануала не проясняются — надо ещё долго укладывать в голове какие-то странные многожтажные условные обозначения. Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас. А PowerShell во многом его унаследовал, так что стройного языка не получилось.Какой этот синтаксис сейчас, я не знаю, но тогда, когда я пытался писать скрипты заказчикам, это был тихий ужас.
Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.
Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.
Для чего этот исторический экскурс? Я говорил про PowerShell. PowerShell именно что стройный язык, в отличие от bash. Не знаю в чём там заключался тихий ужас.
«Ужас» в том, что синтаксис PowerShell не особо предназначен для работы с ним человека без специальной подготовки, а потому он никогда не был оболочкой. И не будет. Это специальный язык программирования для администрирования системы.
У баша столько особенностей, что у меня просто волосы на голове шевелятся, когда я смотрю как многие на нём пишут. Первый же пробел в имени файла развалит всё.
Вы, вероятно, удивитесь, но ничего не разваливается. Можно использовать кавычки, можно выставить набор разделителей. Я постоянно работаю с кучей разных файлов. Недавно закончил проект, в котором приходилось работать с массивом файлов и там в именах директорий были пробелы. Почему-то ничего не развалилось. Что я делал не так? У меня всё собралось и залилось в базу под MariDB.
Особенности есть у всего. Не нравится Bash? Используйте csh, tcsh или любую другую оболочку из кучи имеющихся в репозиториях разных ОС и дистрибутивов.
Особенности есть у всего. Не нравится Bash? Используйте csh, tcsh или любую другую оболочку из кучи имеющихся в репозиториях разных ОС и дистрибутивов.
Вы, вероятно, удивитесь, но ничего не разваливается. Можно использовать кавычки, можно выставить набор разделителей.Я вам рассказываю как пишут, а не как можно сделать. Вы же мне сами пишете про «человека без специальной подготовки».
И мне не нравится не баш, мне не нравится, когда люди незаслуженно ругают powershell и говорят, что баш лучше. Он не лучше, он хуже.
Он не хуже, потому что он для другого. Ещё раз, Bash — пользовательский интерфейс командной строки, PowerShell — инструмент для админа. На момент моего с ним знакомства, они был совершенно непригоден в качестве пользовательского интерфейса. А изучать ещё один язык для написания того, что я могу написать на основном языке проекта, было как-то не очень интересно. Если бы его синтаксис позволял проделать то, что легко делается в Bash, я бы написал скрипт и успокоился, но на тот момент это было невозможно.
Хуже, конечно. Я каждый день пишу на баше и как-то один год писал на powershell'e. Могу сравнивать. Синтаксис powershell легко позволял проделывать всё, что можно в баше.
Ваше же позиционирование этих языков — это просто ваше мнение, у меня оно другое. А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?
Ваше же позиционирование этих языков — это просто ваше мнение, у меня оно другое. А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?
А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?
Вопрос был в том, что вот у меня уже сделанная программа и её надо сдавать. И у меня есть программа на Bash, которая отлично работает, а заказчик внезапно хочет всё запускать на винде. То есть мне надо разгрестись с новым языком чтобы написать одну программу, которая у меня уже есть на языке оболочки.
Я понимаю, что можно сделать всё то же, что и на Bash, вопрос в синтаксисе. Мне он показался ничуть не более понятным, чем у cmd.exe, с которым я работал довольно много.
Странно почему. Он определёно куда более понятный и логичный.
Чем что? Чем язык cmd.exe? Ну… есть немного, если не требуется работать с файлами в режиме оболочки. Синтаксис такой, что проще написать дополнительную программу на основном языке проекта. Если не требуется управлять ОС Windows. А мне надо было всего лишь сделать перебор файлов определённым способом.
Такое ощущение как будто мы о разных языках говорим.
Я вот только что смотрел синтаксис PS. Сложность написания соответствующего кода примерно на уровне такового на Java. А в Bash всё делается в 3-4 сроки, потому что там язык заточен именно под оперирование файлами и строками.
Мы действительно какие-то разные языки имеем ввиду. Я 20 лет за консолью Линукса, из них большую часть этого срока у меня bash (когда-то были tcsh и zsh). Около года программировал на PowerShell и умею читать Java (программировал мало).
Уж никак не сравнить PS и Java. Тем более простые однострочники на PS иногда неотличимы от bash.
Уж никак не сравнить PS и Java. Тем более простые однострочники на PS иногда неотличимы от bash.
И у меня есть программа на Bash, которая отлично работает, а заказчик внезапно хочет всё запускать на винде
В windows 10 баш уже есть в винде.
В любую другую адекватную версию windows баш ставится на раз-два.
В чем проблема то?
Та история, с которой начался спор, происходила тогда, когда даже Win8 ещё даже в проекте не была, а что касается установки Bash, то тут три причины и я их описывал:
1. Эта программа требует файлов конфигурации и, если не делать специальную сборку, придётся создавать песочницу, которая сильно всё попортит. Ну и не забываем, что сам по себе Bash — это просто «клей» или менеджер потоков, то есть понадобится установить ещё кучу всего.
2. Установка ЕЩЁ одной программы, а по факту — нескольких. И имена некоторых из них конфликтуют с уже имеющимися в системе. Например, юниксовый find внезапно называется так же, как убогий досовый, который доступен по умолчанию. Поскольку даже это убожество кем-то используется в пакетных файлах (потому что нормального по умолчанию нет), я не могу просто взять и переписать его. Собственно, отсюда и причина для морока с песочницей.
3. Пользователю часто и так тяжко поставить одну программу, которая ставится, по сути, сама. Я имею в виду интерпретатор Python. А Вы предлагаете ставить целый ворох непонятно чего, которое потом ещё и настраивать надо. Не, я лучше ещё один скрипт на питоне напишу: это будет быстрее, чем возиться с установкой Bash и компании ради перебора файлов. Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.
Про скрипты под виндой. 15 лет назад я пришёл в одну контору. Писали могучую систему для технических писателей. Писали на Java, но, по факту, всё было заточено под винду. Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin. Перетаскивание под *nix началось только через три года, когда пришёл запрос от Sun Microsystems.
1. Эта программа требует файлов конфигурации и, если не делать специальную сборку, придётся создавать песочницу, которая сильно всё попортит. Ну и не забываем, что сам по себе Bash — это просто «клей» или менеджер потоков, то есть понадобится установить ещё кучу всего.
2. Установка ЕЩЁ одной программы, а по факту — нескольких. И имена некоторых из них конфликтуют с уже имеющимися в системе. Например, юниксовый find внезапно называется так же, как убогий досовый, который доступен по умолчанию. Поскольку даже это убожество кем-то используется в пакетных файлах (потому что нормального по умолчанию нет), я не могу просто взять и переписать его. Собственно, отсюда и причина для морока с песочницей.
3. Пользователю часто и так тяжко поставить одну программу, которая ставится, по сути, сама. Я имею в виду интерпретатор Python. А Вы предлагаете ставить целый ворох непонятно чего, которое потом ещё и настраивать надо. Не, я лучше ещё один скрипт на питоне напишу: это будет быстрее, чем возиться с установкой Bash и компании ради перебора файлов. Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.
Про скрипты под виндой. 15 лет назад я пришёл в одну контору. Писали могучую систему для технических писателей. Писали на Java, но, по факту, всё было заточено под винду. Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin. Перетаскивание под *nix началось только через три года, когда пришёл запрос от Sun Microsystems.
Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.
Вопрос привычки. Кто десять лет писал батники и впервые увидел баш, тому башевские циклы с ветвлениями покажутся кошмаром и адом, и наоборот.
Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin.
Скорее всего, причина чисто историческая — кому-то, стоявшему у истоков проекта, ближе всего были Bash и Perl.
А то я работал было в одной конторе, где админские скрипты были написаны на PHP (!), просто потому, что предыдущий админ не знал ни Bash, ни Perl, ни PowerShell, но знал и любил PHP.
Сейчас очень удобно ставить git, который с собой несет все необходимое для подавляющего большинства случаев с bash под windows.
Мне — удобно. Я постоянно использую git. Но мне и ставить его под винду не надо — у меня линукс. А заказчику… Вы думаете, человек, который заказал парсер, а я именно на них специализируюсь, будет заинтересован в установке очередной неведомой херни? Зачем ему такое? Ему, зачастую, сложно объяснить, что такое интерпретатор и зачем его надо ставить. Нет уж, лучше я допишу ещё один скрипт на Python, интерпретатор которого я уже уговорил поставить и который, интерпретатор, ставится сам, без участия пользователя.
Простите, сколько нужно лет для вашей «специальной подготовки», чтобы сказать человеку «пользуйся кавычками, Люк» и наконец закрыть вопрос с пробелами в файлах?
Что все с этими пробелами прицепились.
Вы лучше скажите, почему я могу сделать под Линуксом
echo «hello» > my:file
А на винде ругнется даже в повершеле. Повершел такой убогий, что не умеет двоеточие экранировать? ;)
Что все с этими пробелами прицепились.
Вы лучше скажите, почему я могу сделать под Линуксом
echo «hello» > my:file
А на винде ругнется даже в повершеле. Повершел такой убогий, что не умеет двоеточие экранировать? ;)
В PS суть большинства командлетов интуитивно понятна же.
Get-AdUser, Set-NetIPAddress, Set-WsusServerSynchronization, всё английским по белому.
Get-AdUser, Set-NetIPAddress, Set-WsusServerSynchronization, всё английским по белому.
Это всё аналоги программ, запускаемых из Bash. А вот синтаксис самого языка оказался настолько же невразумительным, как и у cmd.exe. И когда мне понадобился маленький довесок к уже сделанной работе, чтобы уже окончательно передать её заказчику, пришлось потратить дополнительное время и написать всё руками в Python. Хотя у меня такой довесок в Bash написался без проблем и был совершенно человекочитаемым.
Возможно я просто больше пользуюсь PS поэтому мне синтаксис привычен. Но у меня очень мало опыта с другими ЯП, так что, возможно, вы правы.
В целом, синтаксис командлетов в PS достаточно однообразен. Например в bash, как подсказывают коллеги, мы пишем «ip a», но «ifconfig -a», то есть параметры для разных команд обозначаются по разному.
В целом, синтаксис командлетов в PS достаточно однообразен. Например в bash, как подсказывают коллеги, мы пишем «ip a», но «ifconfig -a», то есть параметры для разных команд обозначаются по разному.
В обоих случаях это внешняя утилита и тут уже вопрос в том, как принято в конкретной ОС обозначать ключи. В DOS и Windows ключи идут после "/", а в *nix — после "-" (короткие) и после "--" (полная форма).
Стоп, я сейчас конкретно привел пример из Nix, где для разных внешних утилит (аналогов командлетов PowerShell) ключи указываются по-разному.
Cmd тоже этим страдает с внешними утилитами. Например «ping -t», но «shutdown -s».
А вот в Powershell, на сколько я помню, всё более менее единообразно.
Cmd тоже этим страдает с внешними утилитами. Например «ping -t», но «shutdown -s».
А вот в Powershell, на сколько я помню, всё более менее единообразно.
Надо же! Я с утилитой ip не работал — надобности не было. Но тут стоит помнить, что PowerShell и его обвязку писала одна команда, а в *nix у каждой утилиты свои авторы и у многих синтаксис ключей тянется из древних времён, когда getopt ещё не приняли в качестве стандарта. Поверхностный поиск даёт дату принятия в районе 1985, а многие утилиты гораздо старше.
Чёрт, выше накосячил в примере из винды. «Shutdown /s», но «ping -r».
Вообще, я не пытаюсь доказать, что PS круче bash или что-то подобное, просто всё началось с того, что вы сказали, что вам синтаксис PS показался невразумительным и я искренне пытаюсь понять, что именно это значит. Вот сейчас на мой пример с параметрами, вы отвечаете «ну да, это же одни люди делали и буквально вчера, еще бы там были такие проблемы».
Вообще, я не пытаюсь доказать, что PS круче bash или что-то подобное, просто всё началось с того, что вы сказали, что вам синтаксис PS показался невразумительным и я искренне пытаюсь понять, что именно это значит. Вот сейчас на мой пример с параметрами, вы отвечаете «ну да, это же одни люди делали и буквально вчера, еще бы там были такие проблемы».
Параметры к синтаксису языка отношения не имеют, потому что это синтаксис параметров внешних, по отношению к оболочке, программ. Позже посмотрел синтаксис PowerShell — классический язык программирования с возможностью интерактивного использования. У питона такой есть, если просто запустить интерпретатор. В целом, где-то тут уже был комментарий с хорошим подведением итогов всего этого спора: Bash — интерфейс ОС, управляющий файлами и потоками, поэтому сравнивать его надо с cmd.exe, а PowerShell — интерфейс платформы .NET, поэтому сравнивать его надо с соответствующими утилитами.
Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас.
А ничего, что юниксовый sh был написан в 1971 для компьютера с 64 КБ памяти на магнитных сердечниках, но тот же синтаксис остаётся и сейчас?
Магнитные сердечники в 70-х? Вы не ошиблись? В 1966-1969 годах было принято решение о копировании IBM s/360, уже морально устаревавшей к тому моменту. Именно она стала основой ЕС ЭВМ, которая по-настоящему пошла в серию где-то в 1974 году. Магнитные сердечники — это несколько более ранняя технология. Первый вариант UNIX писался под DEC PDP-7, а стандартный Shell попал в состав UNIX только в 1977.
Магнитные сердечники в 70-х? Вы не ошиблись?
Magnetic-core memory was the predominant form of random-access computer memory for 20 years between about 1955 and 1975.
Первый вариант UNIX писался под DEC PDP-7, а стандартный Shell попал в состав UNIX только в 1977.
The first Unix shell was the Thompson shell, sh, written by Ken Thompson at Bell Labs and distributed with Versions 1 through 6 of Unix, from 1971 to 1975.[2] Though rudimentary by modern standards, it introduced many of the basic features common to all later Unix shells, including piping, simple control structures using if and goto, and filename wildcarding.
пока именно он не начнёт запускаться при запуске «Командной строки»
Он никогда не будет так запускаться. Потому что Командная строка в Win — это cmd.exe
Но в Win+X менюшке уже пару релизов как по умолчанию живёт пошик.
Вот это и называется тайненьким знаньицем: вместо того, чтобы вывесить программу в основное меню, её закопали в какое-то отдельное меню, запускаемое отдельной комбинацией клавиш. Как бы крут ни был этот инструмент, пока пользователи его не видят, он бесполезен. Даже я, вынужденный периодически заниматься настройкой компьютеров с виндой, не знал этого. Что уж говорить об обычных пользователя?
Как бы крут ни был этот инструмент, пока пользователи его не видят, он бесполезен. Даже я, вынужденный периодически заниматься настройкой компьютеров с виндой, не знал этого. Что уж говорить об обычных пользователя?
Совершенно естественно, что инструмент, нужный 0.1% пользователей Windows, спрятан как можно дальше, чтобы обычные пользователи его случайно не запустили и что-нибудь при помощи него не повредили.
И вот так, не показывая пользователю, что есть какой-то инструмент (оболочка), мы потом жалуемся, что пользователь тупой и не знает, как работать с компьютером, которым он пользуется каждый день.
Вы когда-нибудь писали софт для живых пользователей? Пользователь не хочет осваивать никаких инструментов, он хочет одну кнопку «сделать зашибись» во весь экран.
Да вот как-то постоянно пишу. Для живых пользователей. А те, кто хочет просто кнопку «Сделать зашибись», получают такую кнопку. Только всё, что она делает, сообщает, что «Теперь всё зашибись». А кто хочет выполнения некоторой реальной работы, формулируют задание и обучаются использованию полученным инструментом. Подавляющее большинство клиентом очень довольно.
А что вы подразумеваете под «обычным меню»? Пуск? Так кто его оттуда запускает? Win+X — это не отдельное секретное меню, это не просто хоткей для «ПКМ по Пуску».
А обычным пользователям винды не нужен ни пошик ни cmd.
А обычным пользователям винды не нужен ни пошик ни cmd.
Надо же! Всегда вызывал это меню просто кнопкой Win. А командная строка пользователям нужна, если в ней есть нормальная оболочка. Потому что удобно. Понятно, что о чём не знаешь, в том не нуждаешься. Но вот стоит такому «просто пользователю» показать удобства командной строки, как он начинает ею пользоваться. Может, не так активно, как я, но всё-таки.
Powershell стал удобоварим с 3ей версии. Количество использований WinApi резко упало и во многих случаях было замененно нативными командлетами.Насчет «ставить заказчику» — 2я версия по умолчанию уже стоит начиная с win7.
В WinXP его надо было ставить руками, насколько я помню. Если всё равно что-то ставить, то я предпочитаю интерпретатор нормального языка программирования. Опять же, как Вы сами указали, удобоваримым он стал с третьей версии, а я успел от него отказаться, ещё когда он, видимо, ещё из первой не вырос.
А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.
А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.
Powershell и не пытается быть универсальным. Это язык виндового админа, не программиста даже. Он довольно простой, понятный и логичный. Ну, на мой взгляд. Если вам надо рулить виндовыми ролями, то на каком-нибудь пайтоне это будет не тривиально, если вообще возможно. А тут, например, любые действия с AD нативными командлетами.
XP это отдельный разговор много по какому поводу. Но в современных OS Windows PS уже есть и при выборе между батником и ps скриптом я сейчас почти всегда выбираю второе.
VB, как мне кажется, как скриптовый язык в винде сейчас полностью заменен PS. Раньше его использовали просто потому, что он мог гораздо больше, чем cmd, и работал на любой виндовой системе, сейчас же эту роль выполняет PS, причем у него гораздо ниже порог вхождения и, на мой взгляд, он гораздо удобнее VB, хотя бы по тому, что в VB надо работать напрямую с WinApi, а не с удобными командлетами.
XP это отдельный разговор много по какому поводу. Но в современных OS Windows PS уже есть и при выборе между батником и ps скриптом я сейчас почти всегда выбираю второе.
VB, как мне кажется, как скриптовый язык в винде сейчас полностью заменен PS. Раньше его использовали просто потому, что он мог гораздо больше, чем cmd, и работал на любой виндовой системе, сейчас же эту роль выполняет PS, причем у него гораздо ниже порог вхождения и, на мой взгляд, он гораздо удобнее VB, хотя бы по тому, что в VB надо работать напрямую с WinApi, а не с удобными командлетами.
Понял. Значит, сравнивать его с Bash и прочими «нормальными» оболочками некорректно, потому что это узкоспециализированный инструмент администратора, тогда как Bash — именно что пользовательская оболочка. Иначе бы он уже запускался именно в качестве общей оболочки, но даже в десятке этого нет — там по-прежнему в качестве оболочки командной строки используется cmd.exe.
Я думаю, это больше вопрос совместимости. В PS выполняются все команды cmd, какие-то напрямую, какие-то являются алиасами для командлетов Powershell (например, когда пишешь dir на самом деле выполняется get-childitem).
Специализация на администрировании это фича PS, но это не единственное, что он умеет. То есть там просто есть еще и нативные модули для AD, hyper-v, sql и так далее. Я не специалист по пайтону, но не представляю сходу, что такого, можно сделать на пайтоне, чего нельзя сделать в PS.
Специализация на администрировании это фича PS, но это не единственное, что он умеет. То есть там просто есть еще и нативные модули для AD, hyper-v, sql и так далее. Я не специалист по пайтону, но не представляю сходу, что такого, можно сделать на пайтоне, чего нельзя сделать в PS.
в powershell можно сделать вообще всё с виндовыми службами (намного больше, чем в GUI), а причина одна — сам GUI (Server Manager, AD administrative tools) под капотом запускает тот же самый Powershell
Начиная с 2012 — да. Не уверен, насчёт прям всё, но server manager точно генерит внутри себя PS команды. Какой-нибудь Computer Management думаю работает «по старинке».
Я скорее про то, что не виндовыми службами едиными.
Я скорее про то, что не виндовыми службами едиными.
В баш принято отделять мухи от котлет, и в самом баше вызывать консольные утилиты, которые могут сделать все с виндовыми или линуксовыми службами.
Именно этот подход кажется более удобным и устойчивым к изменениями — собственно поэтому шелл-программинг живет так долго практически не теряя обратной совместимости, при этом оставаясь удобным инструментом с минимум устаревшего подхода.
Сейчас активно пишу шелл скрипты, которые работают и под вин и под линукс и радуюсь.
Именно этот подход кажется более удобным и устойчивым к изменениями — собственно поэтому шелл-программинг живет так долго практически не теряя обратной совместимости, при этом оставаясь удобным инструментом с минимум устаревшего подхода.
Сейчас активно пишу шелл скрипты, которые работают и под вин и под линукс и радуюсь.
На Python можно, например, написать программу, не задумываясь о структуре конкретной ОС. Даже той, на которой пишешь эту программу. И она будет работать без явного привлечения системных библиотек. И даже будет работать на другой ОС. В частности, у меня таких случаев в практике, наверное, половина: пишу под Linux, потом всё работает под MacOS X или Windows. Но! Для того, чтобы что-то писать на Python или Bash, мне не нужно знать подноготную ОС, я просто запускаю внешние утилиты и передаю результат работы дальше по конвейеру. Ну и кое-какие инструменты по работе со строками доступны. А в PS надо прямо в недра системы лезть. Для чего он, собственно, и делался.
То, что ПШ ограничен виндой это понятно. А в этих рамках?
Я через него могу общаться с ОС «человеческим» языком, используя как просто оболочку для повседневной работы? Вряд ли. Как мне только что сообщили, для вызова консоли с этим инструментом, надо нажать хитрую комбинацию клавиш, о которой я не знал, хотя регулярно вынужден кому-то что-то настраивать в винде, получить какую-то менюшку и в ней выбрать нужный пункт.
Второй момент — синтаксис. Не как отдельного языка программирования, а как оболочки, чей язык может быть прозрачно использован в качестве языка программирования. Если я правильно помню, синтаксис команд ветвления и циклов там такой же, как в cmd.exe, то есть довольно страшненький.
Второй момент — синтаксис. Не как отдельного языка программирования, а как оболочки, чей язык может быть прозрачно использован в качестве языка программирования. Если я правильно помню, синтаксис команд ветвления и циклов там такой же, как в cmd.exe, то есть довольно страшненький.
Можете, конечно. Я может быть не помню какой-то фундоментальный шорткарт, но cmd я на уровен мышечной памяти вызываю комбинацией win+r -> cmd -> enter. Вместо этого можно просто делать win+r -> powershell -> enter. Или сделать себе алиас ps.
Синтаксис циклов (на примере for) на мой взгляд не особо отличается от питона. Зато наличие объектов позволяет очень удобно работать с массивами в цикле. Банальный пример, взяли нужные компьютеры из AD по имени и тут же вывели любой их параметр или любое сочетание параметров.
Синтаксис циклов (на примере for) на мой взгляд не особо отличается от питона. Зато наличие объектов позволяет очень удобно работать с массивами в цикле. Банальный пример, взяли нужные компьютеры из AD по имени и тут же вывели любой их параметр или любое сочетание параметров.
Ну вот не нужны мне объекты, мне нужны имена файлов и их содержимое в виде текста. Потому что, если нужно что-то более сложное, я использую Python или другой язык программирования. PS — удобное средство для администрирования именно Windows. Оболочка для работы с объектами, интерфейс для платформы .NET, а не для ОС. Вчера кто-то разницу очень чётко расписал: Bash — интерфейс для ОС, для управления файлами и потоками, а PowerShell — интерфейс для платформы .NET и сравнивать его надо с другой утилитой.
Так не нужны объекты — не пользуйтесь. Берите только имена файлов и их содержимое в виде текста (строки).
«Интерфейс для платформы .NET, а не для ОС» — простите, я не понимаю эту фразу.
Есть примеры Core версии Windows Server, где powershell это единственный интерфейс который у вас есть. И в этом случае это как раз «интерфейс для ОС, для управления файлами и потоками».
«Интерфейс для платформы .NET, а не для ОС» — простите, я не понимаю эту фразу.
Есть примеры Core версии Windows Server, где powershell это единственный интерфейс который у вас есть. И в этом случае это как раз «интерфейс для ОС, для управления файлами и потоками».
Пожалуйста, не надо путать VB и VBScript. Между ними не больше общего, чем между Java и JavaScript.
установка bash еще больше расширила возможности FAR.
FAR всегда дружелюбно относился к CLI, и являлся отличным дополнением. Особенно в связке с ConEMU.
А такие команды как:
edit:<grep -P «myregexp» *.txt
А встроенные макросы, которые могут работать не только внутри редактора но и непосредственно в панелях?
FAR всегда дружелюбно относился к CLI, и являлся отличным дополнением. Особенно в связке с ConEMU.
А такие команды как:
edit:<grep -P «myregexp» *.txt
А встроенные макросы, которые могут работать не только внутри редактора но и непосредственно в панелях?
Я ставлю GNU Utilities и наслаждаюсь ls/grep/awk/find/… под виндой внутри cmd
Я тоже так делаю, когда приходится иметь дело с этой ОС на хоть сколько-то постоянной основе. Но эти утилиты работаю… не очень хорошо, потому что установка по умолчанию настраивает пути так, что они рассчитаны на работу в своей песочнице и вывести их на «просторы» основной файловой системы очень сложно. К тому же, у Windows отстойно реализованы конвейеры. Я полтора года назад работал в одной странной конторе, где на все машины была установлена винда и работать приходилось в ней, хотя всё, что я писал, должно было работать в Linux. В итоге, у меня была возможность сравнить работу этих утилит одновременно и в винде, и в Linux. Увы, даже на куда более мощной машине с Windows они работали гораздо медленнее, чем на слабенькой виртуалке и древнем нетбуке (моём личном).
Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.
Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.
Вы не с Cygwin путаете? Это у неё песочница, а gnuwin32 работает родными для Windows способами.
Пробовал работать с Cygwin и MSys2. В обоих случаях создаётся песочница, корневая директория, в которой всё и работает. Выход за её пределы возможен и сделать это не особо сложно, но всё равно это именно песочница. И все прелести такой организации прилагаются: дополнительные действия по перемещению корня куда-то, выход на корневые директории дисков Windows через какие-то странные структуры и так далее. Примерно такой же геморрой, как и при работе с WINE под Linux. Если мне нужны какие-то программы, у которых есть нормальные сборки под Windows, я не могу их использовать — система пытается установить то, что есть у неё в репозиториях, а это, зачастую, устаревшие на несколько лет версии. При этом, тянется, к примеру, собственная версия GTK, даже если у меня в системе уже есть программы, для которых установлена эта библиотека. То есть такая вот изолированная область с софтом в стиле *nix.
С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.
С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.
Какие ещё настроечные файлы у софта типа grep? Там просто набор скомпилированных под винду бинарников, вероятно с исправленным кодом в тех местах где используются unix-специфичные функции. unxutils.sourceforge.net
Не совсем вас понимаю, что вы подразумеваете под «полноценной консолью»? В Тотале есть консоль.
Насколько удобно с ней работать в тотале?
Насколько удобно перемещать данные из консоли в редактор и обратно, видеть результат консоли например вместо одной из панелей?
Насколько удобно перемещать данные из консоли в редактор и обратно, видеть результат консоли например вместо одной из панелей?
У меня не было кейсов, которые бы заставили меня пользоваться КС в FAR или TC, но я изучил на досуге вопрос, потому что меня заинтересовало верхнее сообщение.
Не настолько удобно, как в FAR. Невозможно ни вместо одной из панелей, ни скрывать окно менеджера, оставляя окно командной строки. Если же написать ping 8.8.8.8, то он просто откроет отдельное окно командной строки, как указал AndreyHenneberg ниже. Но можно пользоваться чем-нибудь типа cd %$APPDATA%
Не настолько удобно, как в FAR. Невозможно ни вместо одной из панелей, ни скрывать окно менеджера, оставляя окно командной строки. Если же написать ping 8.8.8.8, то он просто откроет отдельное окно командной строки, как указал AndreyHenneberg ниже. Но можно пользоваться чем-нибудь типа cd %$APPDATA%
То есть, по сути, консоли у него нет. Потому что открыть КС для текущей директории можно и в Проводнике, чем я иногда пользуюсь. Просто TC — чисто GUI-шная программа, тогда как FAR работает в текстовом режиме, в том же самом эмуляторе терминала, который использует КС, поэтому он просто передаёт уже запущенной оболочке ввод и отображает её вывод. Ну или как-то так: я не знаю, как именно это реализовано, потому что в исходниках не копался, хотя они и доступны.
Увы, не припомню такой. Разве что запуск, по сути, отдельного приложения «Командная строка», но это не то. Консоль там открывается одной комбинацией в директории текущей панели, работает с файлами из этой панели (например, передаются выделенные в панели файлы)? Подробности, как это делается в FAR, я сейчас не вспомню, помню только, что как-то делается, а вот в Midnight Commander достаточно использовать placeholder %s и выделенные файлы будут вставлены в командную строку.
Подробности, как это делается в FAR, я сейчас не вспомню
Control+Enter вставляет имя текущего файла из панели в командную строку. Причем имена с пробелами обрамляет в кавычки.
Я не про это. В MC всё точно так же, за исключением того, что не Ctrl-Enter, а Alt-Enter и имена с пробелами не заключаются в кавычки, а эти пробелы экранируются. Я имел в виду возможность вытряхнуть выделенные имена в командную строку стразу пачкой. И да, я знаю, что именно в FAR это есть, разве что не помню, как именно это делается, и сам им с удовольствием пользуюсь, когда надо разгребать горы файлов под виндой: на мой взгляд, ничего лучше под винду ещё не написали. А вот сборки MC под винду настолько убоги, что вызывают желание плакать и биться головой о клавиатуру, при том, что в родной среде он FAR-у не уступает, разве что нельзя туда прикрутить почтовый агент, но это уже извращение для любителей тонких изврашений.
выделяете файлы, жмете Ctrl+Insert и имена копируются в буфер. Можно сразу вставить в строку стандартным Ctrl+V (Shift+Insert).
Можно вставить путь одной из панель через Ctrl + [ или ]
Можно подвинуть панели вверх, чтобы видеть пару строк консоли и соответственно видеть результат выполнения.
Можно вообще много чего делать. Например через Netbox подключится к удаленной sftp сессии на линукс, и не только ходить там по файловой системе и копировать файлы, но и сразу выполнять обычные линукс команды на удаленной системе.
В общем если с винды часто лазите на линукс-машины, и часто работаете со скриптовыми языками (баш, питон, cmd, etc) то FAR становится мега-удобным.
Можно вставить путь одной из панель через Ctrl + [ или ]
Можно подвинуть панели вверх, чтобы видеть пару строк консоли и соответственно видеть результат выполнения.
Можно вообще много чего делать. Например через Netbox подключится к удаленной sftp сессии на линукс, и не только ходить там по файловой системе и копировать файлы, но и сразу выполнять обычные линукс команды на удаленной системе.
В общем если с винды часто лазите на линукс-машины, и часто работаете со скриптовыми языками (баш, питон, cmd, etc) то FAR становится мега-удобным.
Total Commander ничем не хуже. Вкусовщина конечно.
Есть одна проблема — он платный и только под windows. А щелканье по цифрам во время запуска не освобождает от ответственности. Давно перешел на открытый double commnader, который поддерживает плагины от TC.
FAR manager он только под Windows, и бесплатный для жителей exUSSR. 1:1 ;)
Ваши сведения устарели на восемь лет.
Тотал платный же для коммерческого юзанья :-(
У меня FAR долго запускается. Пробовал голый FAR — без плагинов, на XP, на Win 7 — запуск дольше чем Total Commander, и память кушает больше, чем Total Commander. Предпочел Toatal. Хотя сам вспоминаю времена Norton Commander… Еще минус FAR — консоль Windows, шрифты. Midnight Commander более приспособлен к изменению размера консоли и изменению шрифтов.
У меня запускается за, кажется, меньше 0.1 сек (просто мгновенно появляется окно с панелями). Что вам с консолью не нравится тоже непонятно — во-первых, это не чаcть FAR'а (так же как и не часть Midnight Commander'а, её и там и там рисует системная графическая оболочка, либо текстовый режим видеокарты с опять же системными шрифтами), а во-вторых она настраивается как угодно.
У меня запускается мгновенно, как и у firk.
Такое бывает, если в Винде как-то криво настроена сеть — Far может долго тупить на чтении неотвечающих сетевых шар.
В обычных условиях Far запускается полсекунды.
В обычных условиях Far запускается полсекунды.
У меня FAR долго запускается.
Доли секунды. Ну и можно вообще не закрывать месяцами — утечек не вижу.
память кушает больше, чем Total Commander
Простите, что? сколько килобайт, ну ладно мегабайт там разницы? Это же не браузеры, у которых сотня мегабайт туда-сюда.
Еще минус FAR — консоль Windows, шрифты
Использование консоли — это не минус, это особенность, из-за которой большинство пользователей ФАР-а и сидят на ФАРе-.
А если вам не нравится шрифт — в 2018 году сидеть на FAR-е без ConEmu, который решает все вопросы с шрифтами, ресайзом и выделением текста — показатель, что вы в принципе не активный пользователей панельного менеджера.
в 2018 году сидеть на FAR-е без ConEmu, который решает все вопросы с шрифтами, ресайзом и выделением текста — показатель, что вы в принципе не активный пользователей панельного менеджера.
Никаких ConEmu не знаю, и ничего похожего на перечисленные проблемы в FAR в консоли win7 не замечал. Пользуюсь активно. Причём тут номер года, вообще непонятно.
А попробуйте быстро выделить кусок текста в консольном экране?
Как вы это делаете в стандартной win7 консоли?
Как вы это делаете в стандартной win7 консоли?
right click — mark — выделяю — enter
А я просто выделяю. как в putty.
А с ALT могу выделить блоком.
p.s. вдобавок, подозреваю, что у вас не стандартная консоль, ибо в стандартной win7 консоли нужно сперва leftclick на меню слева-сверху, а уже там mark
А с ALT могу выделить блоком.
p.s. вдобавок, подозреваю, что у вас не стандартная консоль, ибо в стандартной win7 консоли нужно сперва leftclick на меню слева-сверху, а уже там mark
А да, оказывается right click не работает если запущена программа, использующая мышь. Но копировать текст прямо из панелей таким образом ни разу не приходилось, да и не знаю зачем это. Запустите cmd или что-нить похожее — right click будет. Ну да, в putty чуть поудобнее, но лишь чуть. У фара хоткей Alt-Ins для консольного копирования.
А даблклик у вас тоже не работает и не выделяет ничего?
Как зачем? Именно в этом и заключается основной момент — чем вы занимаетесь. Для тех, кот активно работает со скриптами, с управлением файлов и конфигурациями, очень удобно копировать что-то с экрана и сразу вставлять в консоль.
В FAR+conemu я могу это делать так, как в gui-шных putty например — то есть просто выделение мышкой, выделение дабл-кликом слова, выделением трипл-кликом всей строки. Быстро и удобно.
Я как бы подозреваю, что админов и продвинутых пользователей консолей не так много, но именно для них подобные инструменты будут удобнее любых других. К хорошему быстро привыкаешь.
Как зачем? Именно в этом и заключается основной момент — чем вы занимаетесь. Для тех, кот активно работает со скриптами, с управлением файлов и конфигурациями, очень удобно копировать что-то с экрана и сразу вставлять в консоль.
В FAR+conemu я могу это делать так, как в gui-шных putty например — то есть просто выделение мышкой, выделение дабл-кликом слова, выделением трипл-кликом всей строки. Быстро и удобно.
Я как бы подозреваю, что админов и продвинутых пользователей консолей не так много, но именно для них подобные инструменты будут удобнее любых других. К хорошему быстро привыкаешь.
p.s. вдобавок, подозреваю, что у вас не стандартная консоль, ибо в стандартной win7 консоли нужно сперва leftclick на меню слева-сверху, а уже там mark
Либо Alt+Space, что быстрее.
Внезапно, Ctrl+M
Нет
У меня нет под руками Win7, чтобы проверить. На моём Win10 работает.
В любом случае, Alt+Space — E — K должно работать, притом быстрее, чем манипуляции мышкой.
В любом случае, Alt+Space — E — K должно работать, притом быстрее, чем манипуляции мышкой.
Директори опус, дорого, не крякается, но стоит того
НЛО прилетело и опубликовало эту надпись здесь
Какой-то некроэксгибиционизм. Какую ценность сейчас представляет этот код? Разве в какой-нибудь музей окаменелостей программного кода )
Что за набор дезинформации. Кроме того, что как уже выше сказали, File Manager никогда не становился заменой нормальным альтернативам — Norton Commander и его клонам
Поддержки длинных имён файлов не было, как и поддержки пробелов в именах. Если Диспетчеру приходилось отображать длинные файлы, то он показывал первые шесть символов, затем символ тильды "~" и число, обычно единицу.
Это не диспетчер, это старое file api операционной системы. Про пробелы — отдельное враньё, их поддерживал и DOS с давних времён.
вы оцените потрясающую обратную совместимость программ под Windows, ведь софт 28-летней давности почти без модификаций работает на последней ОС
Это не достижение, это норма. Причём по-хорошему он должен работать не "почти без модификаций" а вообще без модификаций.
Специально для установки Windows 3.0 приходилось докупать несколько мегабайт оперативной памяти, а иногда и апгрейдить процессор, например, с 20 МГц до 40 МГц.
3.1 (и тем более 3.0) нормально работал и на около-10МГц
Апгрейд до 40 это скорее про Win95.
Это не достижение, это норма. Причём по-хорошему он должен работать не «почти без модификаций» а вообще без модификаций.
А потом окошки ругают за тормознутость из-за обратной совместимости, когда в каждой версии необходимо поддерживать и эмулировать все предыдущие, включая баги.
Про пробелы — отдельное враньё, их поддерживал и DOS с давних времён.Нет, пробелы не поддерживались. Нажмите Ctrl+N в фаре, чтобы посмотреть, как выглядели имена в DOS.
Нет, пробелы поддерживались. en.wikipedia.org/wiki/8.3_filename#Directory_table
Окей, передо мной консоль MS DOS 6.22. Какие команды мне надо набрать, чтобы убедиться в верности ваших слов?
Ой, про qbasic могли бы и не стараться, это первое, что в гугле находится)
Раз пользоваться гуглом вы умеете сами, тогда в чём состоял ваш вопрос?
Вопрос состоял в том, поддерживает ли дисковая операционная система имена без пробелов, или нет. Выяснилось, что FAT и API операционной системы такие имена поддерживают, а сама DOS (в виде своих команд) — нет. Я правильно подвёл итог?
у вас PC DOS, а MS? (я ответа не знаю, просто интересно)
PC-DOS от MS-DOS отличатся только копирайтом; программно они идентичны. PC-DOS поставлялась вместе с новыми компьютерами, MS-DOS — как отдельный продукт.
разве?
в pcdos и системные файлы по другому назывались и набор утилит был другой в поставке
в pcdos и системные файлы по другому назывались и набор утилит был другой в поставке
Я подумал было, вы спрашивали про саму ОС, а не про набор поставляемых утилит?
Очевидно же, что поддержка пробела в именах не зависит ни от набора поставляемых утилит, ни от имён системных файлов.
В любом случае, вы можете сами зайти на www.pcjs.org и там поэкспериментировать с различными досами.
Очевидно же, что поддержка пробела в именах не зависит ни от набора поставляемых утилит, ни от имён системных файлов.
В любом случае, вы можете сами зайти на www.pcjs.org и там поэкспериментировать с различными досами.
Поясните пожалуйста, что вы хотели сказать вашей картинкой?
1) В именах поддерживаются знаки вопроса
2) В именах поддерживаются пробелы
3) В именах поддерживаются пробелы и знаки вопроса
4) В именах не поддерживаются ни пробелы, ни знаки вопроса
1) В именах поддерживаются знаки вопроса
2) В именах поддерживаются пробелы
3) В именах поддерживаются пробелы и знаки вопроса
4) В именах не поддерживаются ни пробелы, ни знаки вопроса
Древнее проснулось зло ;)
5. Походу магия PC DOS умеет превращать знак вопроса (недопустимый символ для FAT) в пробел (допустимый).
5. Походу магия PC DOS умеет превращать знак вопроса (недопустимый символ для FAT) в пробел (допустимый).
Вы так говорите, как будто впервые видите знак вопроса в качестве wildcard character. Он означает «оставить в этом месте тот символ, который уже стоял»; например,
ren magic look?at.me переименует файл magic в lookсat.me. Осталось добавить, что имена в FAT дополняются до 8.3 пробелами — вот и объяснение, почему команда на моём скриншоте оставила внутри имени пробел.В именах поддерживаются пробелы и не поддерживаются знаки вопроса.
Здрасьте, какой же это QBASIC? Это BASICA. Работает только на оригинальных матерях IBM. Кто вспомнит, почему?
Это имена с пробелами, созданные через новый интерфейс. Если же создать имя с пробелом через старый (дос или его эмулятор в win9x, насчёт эмулятора в новых виндах и ntfs не проверял) — они будут показываться нормально везде.
Специально для установки Windows 3.0 приходилось докупать несколько мегабайт оперативной памяти, а иногда и апгрейдить процессор
Windows 3.0 вполне сносно работала на 5МГц процессоре с 640 Кб ОЗУ, и с CGA-дисплеем. Вот 3.1 уже была попрожорливее, и требовала как минимум процессора с поддержкой защищенного режима.
Если Диспетчеру приходилось отображать длинные файлы, то он показывал первые шесть символов, затем символ тильды "~" и число, обычно единицу. Если папка содержала несколько файлов с одинаковыми первыми шестью символами в названии, то им присваивались цифры 2, 3 и так далее.
Это не он «показывал», это формат записи длинных имен в FAT в стандартную запись о файле — поскольку в файловой системе просто не было предусмотрено места для длинных имен. Я уж не помню как там хранились длинные имена, но как-то через Ж. Так что диспетчер не то чтобы специально показывал тильду и число, он просто показывал то, что записано в поле с именем файла в файловой системе, и не умел читать длинные имена.
Я уж не помню как там хранились длинные имена, но как-то через Ж
Через несколько связанных записей, ЕМНИП.
НЛО прилетело и опубликовало эту надпись здесь
Да, что-то такое, я уже точно не помню. По-моему там еще в каждой записи кроме номера текущего куска указывалось и общее количество записей.
Когда-то давным-давно делал на микроконтроллере CD/MP3-плеер, работающий с CD-приводами и жесткими дисками, разбирал FAT16 и FAT32. Распространенных библиотек для контроллеров тогда еще не было, все приходилось делать самому :)
«Эндрю Шульман — Неофициальная Windows 95»
Весьма занимательное чтиво по этому поводу.
Весьма занимательное чтиво по этому поводу.
Где-то лежат несколько установочных дисков Hyundai MS Windows 3.0 (честно купил в книжном магазине коробку), 720КБ 3,5" дискеты, штук 5, кажется.
3.0 имела 3 режима работы:
И 1МБ SIMM во времена 3.1, которой нужно было минимум 2МБ (как раз минимум на 386SX, 4х1МБ получалось 386DX) стоил порядка $100. На 4МБ вполне «многозадачно» уже было — winrar пакует в фоне+winword что-то можно делать. В проц сама винда не упиралась — 386SX16MHz — люди вполне работали. И главное — скорость своппинга тогда в относительніх величинах была намного выше, чем сейчас и своппинг реально спасал ситуацию. Линейная скорость дисков не выросла пропорционально их объёмам и росту объёмов ОЗУ в ПК — как итог с «своп в 3 раза больше ОЗУ» формула уехала в сторону «своп лучше выключить, совсем».
3.0 имела 3 режима работы:
- На 8086 — «640КБ хватит на всех», кажется умело также EMS использовать (это такие железные платки с памятью в ISA) — можно было жить на этих самых 8086/8088, но софта я уже не встречал
- 80286 «standard mode» — 1-16MB RAM
- 80386 «Enhanced mode» — 2MB+ RAM
И 1МБ SIMM во времена 3.1, которой нужно было минимум 2МБ (как раз минимум на 386SX, 4х1МБ получалось 386DX) стоил порядка $100. На 4МБ вполне «многозадачно» уже было — winrar пакует в фоне+winword что-то можно делать. В проц сама винда не упиралась — 386SX16MHz — люди вполне работали. И главное — скорость своппинга тогда в относительніх величинах была намного выше, чем сейчас и своппинг реально спасал ситуацию. Линейная скорость дисков не выросла пропорционально их объёмам и росту объёмов ОЗУ в ПК — как итог с «своп в 3 раза больше ОЗУ» формула уехала в сторону «своп лучше выключить, совсем».
Я запускал когда-то софт Win 3.1 под 80286 1 Mb. Это был конечно, еще тот номер — во первых, даже выкраивая из памяти каждый байт, работали далеко не все программы, кроме стандартной поставки. Но если что-то работало — по воспоминаниям СУБД порождала свопинг минут на 15 буквально после каждой элементарной операции.
smartdrv.exe?
smartdrv.exe сам памяти хочет под кэш, и чем больше — тем лучше, а на машине с 1МБ памяти — лишней памяти и тогда не было. Так что увы, он в такой ситуации не очень поможет, еще и собой память займет.
На мегабайте ОЗУ?! Достаточно бессмысленная затея, хотя чистые DOS-приложения теоретически можно было ускорить. Но для Windows 3.1 это только приведет к растрате драгоценной памяти. Вот с 2 мегабайтами теоретически что-то можно было попытаться.
особо было прикольно, например через NC скопировать папку Мои документы с кучей новомодных файлов и названий папок на русском языке, с пробелами и длинными именами на внешний диск, а потом осознать что все это превратилось в мешанину из filen~12 filen~13 и пипец ;))
winegcc его собирает?
M$ в своем репертуаре — кидает гнилые кости в толпу, стараясь показать свою неописуемую щедрость=))
НЛО прилетело и опубликовало эту надпись здесь
Да, было реально. На работе, помню, докупили и вставили в 386 4 МБ (насколько я помню) оперативки, так два из них сразу пустили под виртуальный диск для оперативных задач :)
НЛО прилетело и опубликовало эту надпись здесь
Пиновые — это не SIMM, а SIPP, использовались в основном на 286. На 386 они уже выходили из употребления (устарели по причине механической ненадёжности штырьковых контактов), в пользу SIMM.
Даже на i286 (не всех, в основном последних поколений, в ранних преимущественно SIPP были) уже были сменные SIMM модули.
У меня как раз такой самый первый из х86 компьютеров был: брендовый(купленный б/у на знаменитой «Юноне») Siemens на Am286-12 и 2 МБ памяти в виде 1x2 МБ 30p SIMM
Потом эти 2 SIMM модуля при модернизации переехали в новый уже собственноручно собранный компьютер на базе 386DX-40 и я помнится не мог почему оно не работает. И только с большим опозданием дошло что 386DX это 32 бит процессор не только в плане вычислений, но и шины памяти в отличии от 16 бит 286го и поэтому согласен кушать 8 битные 30p SIMM модули только порциями по 4 штуки за раз (а всего разъемов под них 8 шт было, которые почти четверть материнской платы занимали).
Пришлось еще срочно незапланированно добывать деньги еще на 2 SIMM модуля, которые изначально планировались к покупке когда-нибудь позже.
kloppspb
У меня как раз такой самый первый из х86 компьютеров был: брендовый(купленный б/у на знаменитой «Юноне») Siemens на Am286-12 и 2 МБ памяти в виде 1x2 МБ 30p SIMM
Потом эти 2 SIMM модуля при модернизации переехали в новый уже собственноручно собранный компьютер на базе 386DX-40 и я помнится не мог почему оно не работает. И только с большим опозданием дошло что 386DX это 32 бит процессор не только в плане вычислений, но и шины памяти в отличии от 16 бит 286го и поэтому согласен кушать 8 битные 30p SIMM модули только порциями по 4 штуки за раз (а всего разъемов под них 8 шт было, которые почти четверть материнской платы занимали).
Пришлось еще срочно незапланированно добывать деньги еще на 2 SIMM модуля, которые изначально планировались к покупке когда-нибудь позже.
kloppspb
Диспетчер файлов из Windows быстро вышел на первую строчку в списке самых популярных репозиториев GitHub за сутки.Это не удивительно — я, например, даже не дочитав статью, собрал этот проект чтобы вспомнить замечательное время простых интерфейсов.
25 лет прошло, а Эксплорер-Проводник как не умел делать «умную» ширину столбцов, так и не умеет.
Интересно, в ReactOS его теперь включат?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft открыла исходный код Диспетчера файлов