Windows File Manager из Windows 3.0
6 апреля 2018 года компания Microsoft выложила на GitHub исходный код оригинальной версии Windows File Manager, который поставлялся в составе операционной системы Windows в 90-е годы, а также доработанную и улучшенную версию Диспетчера файлов. В своё время эта программа стала первым графическим менеджером файлов от Microsoft. Она позволяла копировать, перемещать и удалять файлы, выделяя их мышью. Программа пришла на смену управлению файлами в MS-DOS и стала заменой многочисленным файловым оболочкам вроде Norton Commander, хотя многие пользователи по привычке ещё долгие годы пользовались и до сих пор пользуются NC, FAR и Windows-версией Total Commander.
Теперь любой желающий может скомпилировать исходный код — и запустить старый Windows File Manager в современной операционной системе. Диспетчер файлов из Windows быстро вышел на первую строчку в списке самых популярных репозиториев GitHub за сутки.
Самая первая 16-битная версия Windows File Manager поддерживала только имена файлов в формате 8.3. Поддержки длинных имён файлов не было, как и поддержки пробелов в именах. Если Диспетчеру приходилось отображать длинные файлы, то он показывал первые шесть символов, затем символ тильды "~" и число, обычно единицу. Если папка содержала несколько файлов с одинаковыми первыми шестью символами в названии, то им присваивались цифры 2, 3 и так далее.
Затем программу переписали под 32 бита для Windows NT. Она уже могла отображать длинные имена файлов и поддерживала файловую систему NTFS.
В 1990-1999 годы Диспетчер файлов оставался стандартным компонентом Windows и поставлялся в составе операционной системы. Он до сих пор доступен для скачивания как опциональный менеджер файлов, даже в версии Windows 10, хотя в стандартной поставке его давно заменил Проводник Windows (Windows Explorer).
Последняя версия файла WINFILE.EXE build 4.0.1381.318 поставлялась в составе Windows NT 4.0 Service Pack 6a (SP6a). Последняя 16-битная версия WINFILE.EXE build 4.90.3000 — в составе операционной системы Windows Me.
Как указано в описании на GitHub, представленный исходный код скопирован из ветки Windows NT 4 в ноябре 2007 года. Он содержит некоторые изменения по сравнению с оригинальной версией WinFile.exe. Эти изменения нужны главным образом для того, чтобы программа нормально работала на современных версиях Windows, в том числе на 64-битных версиях и на базе Visual Studio 2015 и 2017.
Код опубликован под лицензией MIT. Мейнтейнером назначен ветеран компании Microsoft Крейг Виттенберг (Craig Wittenberg). Он занимался поддержкой этого кода последние десять лет, после того как скопировал его из ветки Windows NT 4.
Отличительная особенность Windows File Manager — поддержка многодокументного интерфейса Multiple Document Interface (MDI). Это такой способ организации графического интерфейса, в котором большинство окон расположены внутри одного общего окна. Этим он и отличается от распростарнённого сейчас однодокументного интерфейса (SDI), где окна располагаются независимо друг от друга.
Скомпилировав и запустив этот артефакт на современной машине, вы оцените потрясающую обратную совместимость программ под Windows, ведь софт 28-летней давности почти без модификаций работает на последней ОС. Если вы не работали на первых версиях Windows, то можете оценить, какими программами приходилось тогда пользоваться. Только учтите, что в начале 90-х и сама Windows 3.0, и этот Диспетчер файлов заметно тормозили на многих персональных компьютерах. Специально для установки Windows 3.0 приходилось докупать несколько мегабайт оперативной памяти, а иногда и апгрейдить процессор, например, с 20 МГц до 40 МГц. Но в награду пользователь получал текстовый редактор Word под Windows с поддержкой множества кириллических шрифтов и форматированием WYSIWYG — вместо убогого однообразия «Лексикона» или Word под DOS.
В репозитории Microsoft на самом деле находится две версии Windows File Manager: оригинальная версия и слегка расширенная, с дополнительным функционалом, который за годы работы внёс Крейг Виттенберг. Это поддержка копирования, вырезания и вставки клавишами Ctrl+C, Ctrl+X и Ctrl+V, поддержка драг-н-дропа OLE, поддержка контекстных меню в обеих панелях и т. д.
В доработанной версии сохранились и полезные функции старого Диспетчера файлов, такие как «Копирование дискеты».
Комментарии (265)
Andy_Big
10.04.2018 15:38хотя многие пользователи по привычке ещё долгие годы пользовались NC и Windows-версией Total Commander
До сих пор для меня Far — основной файловый менеджер :) Перешел на него с Norton Commander, Total мне не пошел.
Alex023
10.04.2018 21:25+2Volkov Commander forever!!!
kloppspb
10.04.2018 21:34+1DOS Navigator всех круче. Очень сейчас не хватает. И если FAR хоть как-то портировали под Linux (простите, фанаты mc), то с DN всё плохо.
P.S. ещё можно вспомнить Connect AKA IBM Handshaker, очень перспективный проект был, жаль что так и не всплыл.
elmm
11.04.2018 13:36+1Far под linux/macos — неожиданная новость. Надеюсь допилят от альфы, до чего-то вменяемого.
elmm
11.04.2018 13:46It's alive! После танцев с бубном собрал мод Mac и он даже запускается и работает! Прям бальзам на душу.
FlamyXD
10.04.2018 23:55Far? Да ты шутишь. Или ты про CLI?
Andy_Big
11.04.2018 07:19Не, я серьезен. Far 2.0.1420 :)
FlamyXD
11.04.2018 07:23Хорошо, но на какой системе? Я о том, что пользоваться этим на какой нибудь винде (тоесть с GUI) было бы странно.
Andy_Big
11.04.2018 07:37Я только в винде и работаю. С линуксом я очень сильно на "Вы", могу только раз в пару месяцев подправить или обновить что-то на удаленном сервере хостинга :)
dom1n1k
11.04.2018 10:26А чем пользоваться-то? Проводником, прости господи?
Сидел на Far в любых версиях винды, от 98 до 10 включительно и никуда слазить не собираюсь.
iig
11.04.2018 10:30+1Особенно удобен FAR при разгребании коллекций фоток, ага.
Каждый инструмент в чем-то удобен, в чем-то нет.dom1n1k
11.04.2018 11:01Для файлового менеджера фотки — это один из сотни возможных сценариев, частность. Для фотоколлекций абсолютно любой файловый менеджер будет не самым удачным выбором и лучше воспользоваться специализированными программами.
Но кстати сказать, картинки просматривать Far умеет, есть соотвествующий плагин, пользуюсь регулярно.
saboteur_kiev
11.04.2018 12:31Вообще-то фар очень удобен при разгребании коллекций фоток, если пользоваться встроенным просмотрщиком. Можно при просмотре фотки ее сразу выделять, а затем нужнаяоперация выделенные файлы
river-fall
11.04.2018 14:05+1Активно использую mc на макбуке, очень удобно. Не мышкой же файлы выделять, право дело.
Gutt
11.04.2018 10:32FAR всё ещё весьма популярен на Windows. Я-то подсел в начале 2000-х сразу на Total Commander, но многие мои знакомые продолжают до сих пор пользоваться FAR'ом. На самом деле отличия не принципиальны, плагинов полно везде. Не путайте интерфейс с функциональностью, с ней у FAR всё в порядке, и это полноценное win32-приложение, в отличие от DN.
F0iL
11.04.2018 21:04у DN тоже есть (точнее, была, сейчас проект по сути дела мертв) полноценная 32-битная версия с поддержкой длинных имен файлов и других фишек.
fedorro
10.04.2018 15:39+4Лучше бы Explorer выложили, раз сами не могут сделать в нем поддержку длинных путей.
dartraiden
10.04.2018 16:41Включение в политиках не помогает?
Даже в документации MS этот вопрос до конца не прояснён: в одном месте написано, что этого достаточно, а в другом — что ещё и у конкретного приложения в манифесте должны быть разрешены длинные пути.
AndreyHenneberg
10.04.2018 19:26О, ещё одно тайненькое знаньице для решение проблемы, которой могло просто не быть, и решение которой тривиально.
Ziptar
11.04.2018 12:45+1Во-первых, для проводника не помогает.
Во-вторых, для прочих приложений, просто не требуется, если они нормально написаны. Тотал коммандер, например.
AndreyHenneberg
10.04.2018 18:22О, да! Как-то помогал бабушке выяснять, почему у неё не открываются документы. Она пишет историю семьи, раскопала всякого больше чем на 400 лет назад, так что вложенность директорий впечатляющая, а названия — как у средневековых рыцарских романов. Выяснилось, что вот именно из-за них и проблемы: не ест винда (или Проводник) имена длиннее 255 символов. Кстати, из DOS ограничение-то. Но тогда полная длина имени была не более 12 символов (8 — имя, точка и 3 — расширение) и чтобы выбрать лимит надо было собрать путь их 20 компонентов в глубину при максимальной длине имени. Мне даже в голову не сразу пришло, что в 21 веке в современной ОС могут быть такие косяки.
tyomitch
10.04.2018 18:31Не 255, а 260: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
AndreyHenneberg
10.04.2018 19:38Может быть. Когда я выяснял, в чём разница между двумя файлами, то у одного путь был короче 255 символов, а у другого длиннее. Вполне возможно, что длина была больше 260: я этот момент не запомнил, меня поразил сам факт наличия ограничения, причём, настолько жёсткого.
Решил проверить и наткнулся на вот эту статью: Сравнение файловых систем/Ограничения. Дошло, что длина имени файла и длина пути в NTFS совпадают. В очередной раз выпал в осадок.
Кстати, не 260 тогда, а 259, потому что NULL — завершение строки вообще и к пути, как таковому, отношения не имеет.rg_software
10.04.2018 19:43А чего удивительного? Есть over 9000 существующих программ с кодом вида
char path[260];
(ну и далее там хранится какой-то путь). Если ограничения снять, эта программа перестанет работать.
AndreyHenneberg
10.04.2018 20:04Они, собственно, и сейчас не работают: если использовать относительный путь, то, как я понял из экспериментов, без разницы, какой длины полный, а вот если отдавать полный, программа давится и умирает. Поэтому ничего не изменится, кроме того, что новые программы уже будут писать правильно.
quwy
10.04.2018 21:59А чего удивительного? Есть over 9000 существующих программ с кодом вида
char path[260];
Тут проблема в том, что у самой MS в примерах кода везде этот char path[MAX_PATH]. Так что проблема легкого решения не имеет, и если просто увеличить этот MAX_PATH, начнется ад. Нужно что-то типа версионности WinAPI делать, чтобы совместимость не угробить.
sumanai
10.04.2018 22:07Нужно что-то типа версионности WinAPI делать, чтобы совместимость не угробить.
MinWin с его бесконечными api-ms-win-core-console-l1-1-0.dll как раз оно и есть.
KVL01
11.04.2018 09:14Maximum 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".tyomitch
11.04.2018 12:04Вы таки не поверите, но выше в этой ветке комментариев я запостил ту же самую ссылку.
sergik718
10.04.2018 18:50Причем в 10-ке только с 1607 есть поддержка длинных путей, но спасают UNC пути в тот же Explorer. Только так и пользуемся в таких ситуациях.
rezdm
10.04.2018 15:49+1Только FAR, только хардкор. Надо мной коллеги посмеиваются, дескать, что это за нортон коммандер в 2018-ом, но я не представляю, как работать в этом винфайле, в эксплорере. Я начинал работать разрабом в 98-99 году, WinNT (захватил 3.51 только дома, на работе уже 4-ка была; под юнихами как-то прикипел к deco за простоту, но он уж совсем-совсем простой), был тогда дос навигатор виндовый, нортон коммандер заточенный под винду/фат32, потом фар. И всё.
DMGarikk
10.04.2018 17:00а что еще использовать в 2018-м?
я в нескольких разных полу-ИТ конторах работал с количеством сотрудников от 50 до 500 человек, везде очень активно использовался FAR, даже среди менеджмента и рядовых сотрудниковiig
10.04.2018 17:31а что еще использовать в 2018-м?
Total Commander ничем не хуже. Вкусовщина конечно.DMGarikk
10.04.2018 17:39Мне total никогда не нравился как раз тем что он очень похож на обсуждаемый WinFile ;)
а про 2018 год… так тотал старше фара и интерфейс у обоих «устаревший для 18 года», только у фара он так и остался в привычной среде, а тотал казался чуждым уже в 95 винде не говоря уже о современных версиях (P.S. сугубое imho, знаю что ярых поклонников тотала великое множество и меня заминусят)iig
10.04.2018 17:54Вся сила обоих программ — в плугинах, а их великое множество. И в 2 панельном интерфейсе, конечно. А так — дело вкуса.
LAutour
10.04.2018 18:51И базовая гибкая работа с группами файлов. Сколько лет ушло у микрософта на добавление кнопки «пропустить» в проводнике, когда он застревает на каком либо файле при групповой операции?
MonkAlex
10.04.2018 17:53В тотале есть возможность чтения файлов и поиска по содержимому, в том числе с просмотром? Не нашел сразу и копаться лень стало.
iig
10.04.2018 18:00В 2018 году, в популярной и активно поддерживаемой программе, должно быть всё, что нужно.
ru1z
10.04.2018 18:02Вроде все есть, стандартно, если правильно понял. А есть пример, как это в фаре реализовано, чтобы сравнить?
AndreyHenneberg
10.04.2018 19:44FAR предоставляет полноценную консоль, как, в своё время NC и VC. У Total Commander консоли нет, что часто бывает крайне неудобно. Но да, вкусовщина.
Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами. Но даже без неё работать в винде очень сложно.sumanai
10.04.2018 20:09+1Впрочем, убогость виндовой, а по факту — всё ещё DOS-овой, консоли признали даже в MS, организовав установку Bash штатными средствами.
Баш никак не соотносится с консолью, хотя и позволяет, с последних версий, запускать виндовые программы.
«Заменой» консоли можно было бы назвать PowerShell, но его концепция резко расходится с обычной консолью, хотя и мощная, можно сказать, это отдельный скриптовой ЯП.AndreyHenneberg
10.04.2018 20:35Я когда-то пытался разобраться с PowerShell, но его надо было ставить отдельно, это было маятно и всё равно пришлось бы ставить заказчику на машину руками. В общем, по моим ощущениям, он мало чем отличался от стандартной досовой оболочки. Возможно, я уже неправильно помню. Собственно, в винде главныая проблемв в плане консоли и того, как её привыкли видеть в более нормальных ОС — нет встроенного интерпретатора для написания скриптов. JScript и VB не в счёт, потому что там, насколько я помню, отсутствуют встроенные средства для работы с чем-либо вообще: каждый раз приходится задействовать шаманства, подгружая какие-то внешние библиотеки. Внешние по отношению к языку. Это как в программе на Python или C запускать внешнюю программу. Только там это делается для ненаписания своих велосипедов или чтобы использовать какие-то тяжеловесные инструменты, вроде Tesseract для распознавания текста с изображения или mencoder для перекодирования видео, а тут — по любому поводу. То есть не получается написать свою маленькую программку, не встревая в дебри WinAPI, тонкостей OLE, COM, DCOM и прочих ActiveX. А отсутствие возможности вот так, «на коленке», написать мелкую программку убивает саму идею отсутствия чёткой границы между использование программы и её написанием, а следом и консоль, потому что программирование это только для программистов. И завтрак должны готовить только профессиональные повара.
bolk
10.04.2018 22:14Даже самая первая версия PowerShell очень сильно отличалась от стандартной досовой оболочки и даже от bash (в лучшую сторону).
river-fall
11.04.2018 14:10от баша в лучшую сторону? да банальный grep в том Powershell превращался в
%command%| Select-String -Pattern %regexPattern%
Очень удобноbolk
11.04.2018 14:24+1Вы уже мне про баш-то не зачёсывайте, я на нём часто пишу.
Давайте выберите мне из «ls -l» все файлы этого года.river-fall
11.04.2018 14:37+2Парсить ls настоятельно не рекомендуется
mywiki.wooledge.org/ParsingLs
find. -type f -newermt 2018-01-01
bolk
11.04.2018 15:00+1Спасибо, но я не это спрашивал.
PowerShell по конвееру пускает не строки, а объекты, в этом как раз его сила.
iig
11.04.2018 14:39все файлы этого года
Созданные в этом году? Модифицированные в этом году? man find?bolk
11.04.2018 15:01Я знаю что такое find. Речь совсем не об этом.
iig
11.04.2018 15:30Речь о файлменеджерах?
bolk
11.04.2018 15:35Речь о том, что в bash по конвееру идут строки, а в PowerShell — объекты.
iig
11.04.2018 16:14Это в некоторых случаях важно, спорить не буду. Просто напомню, что строка — это тоже обьект, только очень простой. А с простыми обьектами проще обращаться.
Вот, например, из кучи картинок выбрать картинки с определенными размерами. bash + imagemagick + awk — и за 2 минуты фильтр будет готов, а через 10 минут я про него забуду, за ненадобностью.
AndreyHenneberg
11.04.2018 14:49+1Вы сейчас спросили, как приготовить мороженое в натопленной бане :).
Потому что задали совершенно конкретный ключ, который влечёт за собой вывод списка файлов в совершенно конкретном формате, который совершенно не обязательно содержит год.
Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.bolk
11.04.2018 15:02+2Всё что угодно сделать можно. Проблема в том, что bash оперирует строками, а вот PowerShell — объектами. Отсюда и вот эти костылёчки, типа -print0. Так что сравнение bash и powershell не в пользу баша.
saboteur_kiev
11.04.2018 15:25единственное чем полезен powershell — это управление объектами .net
Не именами файлов, не выводом ls или dir, а возможностью обратиться к конкретной проперти юзера в AD, или даже ячейки excel без сторонних библиотек.
Под Linux, где вместо объектов .net есть /dev, /proc — powershell заметно проигрывает.
Также он заметно проигрывает башу в простоте конструкций и кроссплатформенности.bolk
11.04.2018 15:36По кроссплатформенности — пожалуй (хотя есть кривой posh), а по простоте конструкций всё же не критично. Зато там нет беды с экранированием пробелов в именах, например, и прочего обо что все спотыкаются постоянно.
AndreyHenneberg
11.04.2018 17:28Как раз наоборот: Bash оперирует теми же типом объектов, что и пользователь, то есть человек. Поэтому Bash — оболочка, а PowerShell — инструмент для администрирования, с которым обычный пользователь и не должен сталкиваться. Потому PowerShell не обязан быть удобным для ежедневного использования для чего-то отличного от управления объектами .NET, как написали выше.
bolk
11.04.2018 17:36+1Да кто сейчас в Линуксе сталкивается с башем, кроме админов-то?
AndreyHenneberg
11.04.2018 17:50Как ни странно, многие. Вот я ни разу не админ, а пользуюсь. Потому что удобно. И, Вы не поверите, но в MacOS X рядовые пользователи тоже используют консоль, в которой — вот неожиданность! — запускается всё тот же Bash. А всё потому, что удобно. Потому что Bash, как я уже написал, оперирует теми же типами объектов, что и пользователь. Потому что он изначально — именно пользовательская оболочка.
bolk
11.04.2018 17:59+1У меня другая статистика использования консоли на «Маках», у меня у самого «Мак» (но я не рядовой пользователей), а вокруг очень много менеджеров с ними же. Они вообще не знают, что такое консоль. Далеко не все даже спотлайтом-то пользуются.
AndreyHenneberg
11.04.2018 18:53Ну… Я видел инженеров, настраивающих связь у абонентов, которые консолью пользоваться не умели. То есть виндовой консолью ещё как-то пользовались, а вот с Bash управиться не могли и моя жена им на пальцах объяснял. Замечу, это профессионал, то есть человек, которому за такую работу деньги платят, и домохозяйка, которая в Linux только кино смотрела, документы в OpenOffice правила и по интернету лазила.
Это к тому, что у нас выборки разные и слишком маленькие, чтобы быть репрезентативными. Я писал про своих клиентов, которых не особо затруднял запуск скрипта из командной строки в MacOS X. Был только один случай, когда заказчик с этим не справился. А вот те, кто пользуется Windows не справляются регулярно. Вплоть до того, что они не знают, что такое файл и что такое директория, что обнаруживается уже на этапе приёмки работы. Вплоть до того, что один явно изъявил согласие на интерфейс командной строки, не зная, что это такое.
saboteur_kiev
12.04.2018 00:02Разработчики, тестировщики.
Пользователи консольных утилит. В отличие от powershell, основы баша невероятно просты.
Тот же ffmpeg запустить, чтобы на даче с камеры видео сжимать/править — скриптик написал из двух строк и все.bolk
12.04.2018 07:15Ну, разработчики, тестировщики… я имел ввиду простых пользователей, а не айтишников.
Тот же ffmpeg запустить, чтобы на даче с камеры видео сжимать/править — скриптик написал из двух строк и все.
Я не пробовал, но уверен, что на powershell будет примерно так же.saboteur_kiev
12.04.2018 11:02на линуксе?
bolk
12.04.2018 11:04Я думал мы не про операционные системы говорим. Ну пусть будет на Линуксе: github.com/PowerShell/PowerShell
tyomitch
11.04.2018 18:19Как раз наоборот: Bash оперирует теми же типом объектов, что и пользователь, то есть человек.
Белковые люди оперируют не строками, а папками, документами, фотографиями и т.п. Именно в эту сторону и развивалась стандартная оболочка Windows, т.е. explorer.
(Можете сами спросить свою бабушку, оперирует ли она строками.)AndreyHenneberg
11.04.2018 20:26Учитывая, что сейчас у меня в руках том формата А4 на 550 с хвостиком страниц со списками и таблицами, описывающими историю моих предков за больше чем 400 по материнской линии, видимо, всё-таки строками. Текстовый документ состоит из строк, если что. Обозвав директорию папкой, ни Вы, ни сочинители из Apple ничего не изменили. А вот путаницы двойная иерархия устроила много, потому что, как только возникает техническая задача, пользователь внезапно осознаёт, что всё строено иначе, чем показывает ему поделие MS. Потому что в реальном мире папка находится на столе, который стоит в кабинете и так далее, а стол является основой мироздания и вход в туалет, душ и архив, внезапно, находятся не на нём, а за дверью кабинета.
tyomitch
11.04.2018 20:59«Держа в руках книжку, человек оперирует строками, потому что текст состоит из строк» — примерно такая же демагогия, как «держа в руках книжку, человек оперирует глюкозными цепочками, потому что бумага состоит из глюкозных цепочек».
AndreyHenneberg
11.04.2018 21:23Это не демагогия, это факт. Но в Вашем варианте речь идёт об оперировании книгой как физическим объектом как набором объектов, его составляющих, а в моём — об оперировании текстовой информацией, составляющей содержания книги. Просто Ваш пример не имеет отношения к обсуждаемой теме.
tyomitch
11.04.2018 21:33Бумага, текст, вёрстка, иллюстрации — всё это в равной степени является содержанием книги. (Видели pop-up books? Скажите мне, что физическая составляющая в них второстепенна.) Почему именно текст, и именно в виде строк (а не, скажем, дерева) вы выносите вперёд всего?
eshkel
11.04.2018 17:38мне интересно как 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 для решения большинства задач.bolk
11.04.2018 17:46«ls» в powershell — алиас к Get-ChildItem, многие команды имеют короткие алиасы.
Не везде --full-time существует:
$ ls --full-time ls: illegal option -- - usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
И для точности «ls» к башу отношения не имеет. Кроме того, вы изменили задачу — я вам предлагал «ls -l», вы мне — «ls --full-time». Не надо так.
Я могу решить задачу найти файлы этого года кучей способов (в том числе, убрав из вашей строки grep и переменную), я хотел проиллюстрировать, что строки — отстой, так как они не имеют чётких полей.AndreyHenneberg
11.04.2018 17:56Так смысл Bash не в том, чтобы уметь всё внутри себя, а в том, чтобы оперировать файлами, строками и внешними утилитами, которые уже сами что-то там делают. Инкапсуляция, однако.
Строки — это универсальный человекочитаемый формат. Содержимое строки можно проконтролировать глазами. Функция Bash — не администрирование отдельно взятого семейства ОС, а «клей» для организации взаимодействия между специализированными инструментами и общения пользователя с этими инструментами.bolk
11.04.2018 18:00+1Вы хоть посмотрите-ка как выглядит неперенаправленный никуда вывод в powershell, визуально там табличка. Так что смотрите глазами, кто мешает-то?
Я понимаю идеологию баша, я за консолью линуксов больше 20 лет.eshkel
11.04.2018 18:42+1Простите, но зачем тогда сравнивать теплое с мягким? Вы пытаетесь сравнивать 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'у. Но такое сравнение очевидно некорректное.
bolk
11.04.2018 19:49Я утверждаю, что PowerShell лучше баша именно как оболочка командной строки. С groovysh я не знаком.
Вот это Powershell (на баше тоже будет работать, но «cat» будет лишним):
cat user-agents.log | sort -u
и это PowerShell:
ls | where {!$_.length} | %{rm $_}
А groovysh как выглядит?iig
12.04.2018 10:26ls | where {!$_.length} | %{rm $_}
Я так понимаю, это заклинание на удаление пустых файлов. В проводнике это делается, например, так:
клик мышкой в заголовок поля с размером
промотать список до конца
клик с шифтом
промотать до первого непустого файла
клик с шифтом
del
Проводник проще и быстрее, чем bash вместе с powershell ;)bolk
12.04.2018 10:37+1Откуда тут проводник взялся? Тут был версус PS и баша. Если уж впутывать проводник, представьте, что теперь надо и вложенные папки обработать. В данной строке изменений будет на копейку.
saboteur_kiev
12.04.2018 11:06Проводник проще и быстрее, чем bash вместе с powershell ;)
Вы забываете, что ЛЮБАЯ команда в консоли — легко превращается в скрипт, а скрипт легко вызывать например по расписанию.
Нельзя сравнивать GUI и CLI интерфейсы без контекста использования.
Можно сравнивать разные оболочки одного типа, например powershell и bash.
А Вы, со своим проводником, просто видимо никогда не встречаетесь с задачами чуть сложнее чем запустить ярлык.
Например: 10 тысяч файлов в папке. Сколько будете мотать список в вашем проводнике до первого непустого, если он будет например трехтысячным?iig
12.04.2018 11:33Нельзя сравнивать GUI и CLI интерфейсы без контекста использования.
Да. Проводинк, nc, FAR — менеджеры файлов. В каждом из них задача «удалить пустые файлы» решается в несколько щелчков мыши. Это как правило быстрее, чем вспоминать/гуглить/придумывать заклинание для PS/bash.
На shell можно все, и даже больше, да. Но иногда проще не писать однострочник, а взять более подходящий инструмент.saboteur_kiev
12.04.2018 11:49+1Да. Проводинк, nc, FAR — менеджеры файлов.
Особенность файловых менеджеров в том, что они представляют собой совмещенный панельный + CLI интерфейс.
То есть если пишешь в консоли, удобно писать не в консоли, а в каком-нить FAR-е.
DrPass
12.04.2018 23:16Вы забываете, что ЛЮБАЯ команда в консоли — легко превращается в скрипт
Верно. Но кому, кроме некоторой части профессиональных ИТшников, это может быть нужно? 99.99% кейсов использования любой командной оболочки — это как раз что-то запустить, реже переименовать, удалить, скопировать. Причем не по повторяющемуся шаблону, а однократно. И зачастую с необходимостью предпросмотра содержимого. Так что кроме узкого специального круга задач Проводник действительно проще и быстрее.
AndreyHenneberg
11.04.2018 14:35Главное преимущество Bash (shl, csh, tcsh, ksh etc) в том, что это именно оболочка, команды которой можно «сложить» в файл и получится новая команда. Причём, сами команды легко читаются и понимаются «без перевода». Проблема command.com и его наследника cmd.exe в том, что вторая часть там реализована плохо: код, написанный на их программном языке читается с трудом, у них куча невразумительных конструкций, которые простым прочтением мануала не проясняются — надо ещё долго укладывать в голове какие-то странные многожтажные условные обозначения. Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас. А PowerShell во многом его унаследовал, так что стройного языка не получилось.Какой этот синтаксис сейчас, я не знаю, но тогда, когда я пытался писать скрипты заказчикам, это был тихий ужас.
Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.bolk
11.04.2018 15:04Для чего этот исторический экскурс? Я говорил про PowerShell. PowerShell именно что стройный язык, в отличие от bash. Не знаю в чём там заключался тихий ужас.
AndreyHenneberg
11.04.2018 17:31+1«Ужас» в том, что синтаксис PowerShell не особо предназначен для работы с ним человека без специальной подготовки, а потому он никогда не был оболочкой. И не будет. Это специальный язык программирования для администрирования системы.
bolk
11.04.2018 17:36+1У баша столько особенностей, что у меня просто волосы на голове шевелятся, когда я смотрю как многие на нём пишут. Первый же пробел в имени файла развалит всё.
AndreyHenneberg
11.04.2018 18:00Вы, вероятно, удивитесь, но ничего не разваливается. Можно использовать кавычки, можно выставить набор разделителей. Я постоянно работаю с кучей разных файлов. Недавно закончил проект, в котором приходилось работать с массивом файлов и там в именах директорий были пробелы. Почему-то ничего не развалилось. Что я делал не так? У меня всё собралось и залилось в базу под MariDB.
Особенности есть у всего. Не нравится Bash? Используйте csh, tcsh или любую другую оболочку из кучи имеющихся в репозиториях разных ОС и дистрибутивов.bolk
11.04.2018 18:02+1Вы, вероятно, удивитесь, но ничего не разваливается. Можно использовать кавычки, можно выставить набор разделителей.
Я вам рассказываю как пишут, а не как можно сделать. Вы же мне сами пишете про «человека без специальной подготовки».
И мне не нравится не баш, мне не нравится, когда люди незаслуженно ругают powershell и говорят, что баш лучше. Он не лучше, он хуже.AndreyHenneberg
11.04.2018 18:07Он не хуже, потому что он для другого. Ещё раз, Bash — пользовательский интерфейс командной строки, PowerShell — инструмент для админа. На момент моего с ним знакомства, они был совершенно непригоден в качестве пользовательского интерфейса. А изучать ещё один язык для написания того, что я могу написать на основном языке проекта, было как-то не очень интересно. Если бы его синтаксис позволял проделать то, что легко делается в Bash, я бы написал скрипт и успокоился, но на тот момент это было невозможно.
bolk
11.04.2018 18:10Хуже, конечно. Я каждый день пишу на баше и как-то один год писал на powershell'e. Могу сравнивать. Синтаксис powershell легко позволял проделывать всё, что можно в баше.
Ваше же позиционирование этих языков — это просто ваше мнение, у меня оно другое. А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?AndreyHenneberg
11.04.2018 18:35А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?
Вопрос был в том, что вот у меня уже сделанная программа и её надо сдавать. И у меня есть программа на Bash, которая отлично работает, а заказчик внезапно хочет всё запускать на винде. То есть мне надо разгрестись с новым языком чтобы написать одну программу, которая у меня уже есть на языке оболочки.
Я понимаю, что можно сделать всё то же, что и на Bash, вопрос в синтаксисе. Мне он показался ничуть не более понятным, чем у cmd.exe, с которым я работал довольно много.bolk
11.04.2018 20:04Странно почему. Он определёно куда более понятный и логичный.
AndreyHenneberg
11.04.2018 20:45Чем что? Чем язык cmd.exe? Ну… есть немного, если не требуется работать с файлами в режиме оболочки. Синтаксис такой, что проще написать дополнительную программу на основном языке проекта. Если не требуется управлять ОС Windows. А мне надо было всего лишь сделать перебор файлов определённым способом.
bolk
11.04.2018 21:02Такое ощущение как будто мы о разных языках говорим.
AndreyHenneberg
11.04.2018 21:26Я вот только что смотрел синтаксис PS. Сложность написания соответствующего кода примерно на уровне такового на Java. А в Bash всё делается в 3-4 сроки, потому что там язык заточен именно под оперирование файлами и строками.
bolk
11.04.2018 21:43Мы действительно какие-то разные языки имеем ввиду. Я 20 лет за консолью Линукса, из них большую часть этого срока у меня bash (когда-то были tcsh и zsh). Около года программировал на PowerShell и умею читать Java (программировал мало).
Уж никак не сравнить PS и Java. Тем более простые однострочники на PS иногда неотличимы от bash.
saboteur_kiev
12.04.2018 00:07И у меня есть программа на Bash, которая отлично работает, а заказчик внезапно хочет всё запускать на винде
В windows 10 баш уже есть в винде.
В любую другую адекватную версию windows баш ставится на раз-два.
В чем проблема то?AndreyHenneberg
12.04.2018 08:54Та история, с которой начался спор, происходила тогда, когда даже Win8 ещё даже в проекте не была, а что касается установки Bash, то тут три причины и я их описывал:
1. Эта программа требует файлов конфигурации и, если не делать специальную сборку, придётся создавать песочницу, которая сильно всё попортит. Ну и не забываем, что сам по себе Bash — это просто «клей» или менеджер потоков, то есть понадобится установить ещё кучу всего.
2. Установка ЕЩЁ одной программы, а по факту — нескольких. И имена некоторых из них конфликтуют с уже имеющимися в системе. Например, юниксовый find внезапно называется так же, как убогий досовый, который доступен по умолчанию. Поскольку даже это убожество кем-то используется в пакетных файлах (потому что нормального по умолчанию нет), я не могу просто взять и переписать его. Собственно, отсюда и причина для морока с песочницей.
3. Пользователю часто и так тяжко поставить одну программу, которая ставится, по сути, сама. Я имею в виду интерпретатор Python. А Вы предлагаете ставить целый ворох непонятно чего, которое потом ещё и настраивать надо. Не, я лучше ещё один скрипт на питоне напишу: это будет быстрее, чем возиться с установкой Bash и компании ради перебора файлов. Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.
Про скрипты под виндой. 15 лет назад я пришёл в одну контору. Писали могучую систему для технических писателей. Писали на Java, но, по факту, всё было заточено под винду. Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin. Перетаскивание под *nix началось только через три года, когда пришёл запрос от Sun Microsystems.tyomitch
12.04.2018 10:04Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.
Вопрос привычки. Кто десять лет писал батники и впервые увидел баш, тому башевские циклы с ветвлениями покажутся кошмаром и адом, и наоборот.
Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin.
Скорее всего, причина чисто историческая — кому-то, стоявшему у истоков проекта, ближе всего были Bash и Perl.
А то я работал было в одной конторе, где админские скрипты были написаны на PHP (!), просто потому, что предыдущий админ не знал ни Bash, ни Perl, ни PowerShell, но знал и любил PHP.
saboteur_kiev
12.04.2018 11:07Сейчас очень удобно ставить git, который с собой несет все необходимое для подавляющего большинства случаев с bash под windows.
AndreyHenneberg
12.04.2018 11:19Мне — удобно. Я постоянно использую git. Но мне и ставить его под винду не надо — у меня линукс. А заказчику… Вы думаете, человек, который заказал парсер, а я именно на них специализируюсь, будет заинтересован в установке очередной неведомой херни? Зачем ему такое? Ему, зачастую, сложно объяснить, что такое интерпретатор и зачем его надо ставить. Нет уж, лучше я допишу ещё один скрипт на Python, интерпретатор которого я уже уговорил поставить и который, интерпретатор, ставится сам, без участия пользователя.
saboteur_kiev
12.04.2018 00:06Простите, сколько нужно лет для вашей «специальной подготовки», чтобы сказать человеку «пользуйся кавычками, Люк» и наконец закрыть вопрос с пробелами в файлах?
Что все с этими пробелами прицепились.
Вы лучше скажите, почему я могу сделать под Линуксом
echo «hello» > my:file
А на винде ругнется даже в повершеле. Повершел такой убогий, что не умеет двоеточие экранировать? ;)sumanai
12.04.2018 03:19А на винде ругнется даже в повершеле.
А чем ругается то? Только что выполнил на XP в CMD, файл создался, в альтернативном потоке содержится введённый текст, притом весь, вместе с кавычками и пробелом.
И зачем экранировать двоеточие, когда это разделитель для указания альтернативных файловых потоков?saboteur_kiev
12.04.2018 11:08Поток это содержимое, а не имя файла. Результат отличается от задумнного.
bolk
12.04.2018 07:22+1> Что все с этими пробелами прицепились.
Потому что её часто допускают и это самая понятная проблема и обсуждаемая проблема. Про остальные (типа «выставляй IFS») многие писатели на баше и не знают.
Про двоеточие не пишу, вам выше ответили уже.
darthslider
11.04.2018 17:59+1В PS суть большинства командлетов интуитивно понятна же.
Get-AdUser, Set-NetIPAddress, Set-WsusServerSynchronization, всё английским по белому.AndreyHenneberg
11.04.2018 18:03Это всё аналоги программ, запускаемых из Bash. А вот синтаксис самого языка оказался настолько же невразумительным, как и у cmd.exe. И когда мне понадобился маленький довесок к уже сделанной работе, чтобы уже окончательно передать её заказчику, пришлось потратить дополнительное время и написать всё руками в Python. Хотя у меня такой довесок в Bash написался без проблем и был совершенно человекочитаемым.
darthslider
11.04.2018 18:10Возможно я просто больше пользуюсь PS поэтому мне синтаксис привычен. Но у меня очень мало опыта с другими ЯП, так что, возможно, вы правы.
В целом, синтаксис командлетов в PS достаточно однообразен. Например в bash, как подсказывают коллеги, мы пишем «ip a», но «ifconfig -a», то есть параметры для разных команд обозначаются по разному.AndreyHenneberg
11.04.2018 18:38В обоих случаях это внешняя утилита и тут уже вопрос в том, как принято в конкретной ОС обозначать ключи. В DOS и Windows ключи идут после "/", а в *nix — после "-" (короткие) и после "--" (полная форма).
darthslider
12.04.2018 09:21Стоп, я сейчас конкретно привел пример из Nix, где для разных внешних утилит (аналогов командлетов PowerShell) ключи указываются по-разному.
Cmd тоже этим страдает с внешними утилитами. Например «ping -t», но «shutdown -s».
А вот в Powershell, на сколько я помню, всё более менее единообразно.AndreyHenneberg
12.04.2018 09:36+1Надо же! Я с утилитой ip не работал — надобности не было. Но тут стоит помнить, что PowerShell и его обвязку писала одна команда, а в *nix у каждой утилиты свои авторы и у многих синтаксис ключей тянется из древних времён, когда getopt ещё не приняли в качестве стандарта. Поверхностный поиск даёт дату принятия в районе 1985, а многие утилиты гораздо старше.
darthslider
12.04.2018 09:42Чёрт, выше накосячил в примере из винды. «Shutdown /s», но «ping -r».
Вообще, я не пытаюсь доказать, что PS круче bash или что-то подобное, просто всё началось с того, что вы сказали, что вам синтаксис PS показался невразумительным и я искренне пытаюсь понять, что именно это значит. Вот сейчас на мой пример с параметрами, вы отвечаете «ну да, это же одни люди делали и буквально вчера, еще бы там были такие проблемы».AndreyHenneberg
12.04.2018 10:50Параметры к синтаксису языка отношения не имеют, потому что это синтаксис параметров внешних, по отношению к оболочке, программ. Позже посмотрел синтаксис PowerShell — классический язык программирования с возможностью интерактивного использования. У питона такой есть, если просто запустить интерпретатор. В целом, где-то тут уже был комментарий с хорошим подведением итогов всего этого спора: Bash — интерфейс ОС, управляющий файлами и потоками, поэтому сравнивать его надо с cmd.exe, а PowerShell — интерфейс платформы .NET, поэтому сравнивать его надо с соответствующими утилитами.
tyomitch
11.04.2018 15:10Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас.
А ничего, что юниксовый sh был написан в 1971 для компьютера с 64 КБ памяти на магнитных сердечниках, но тот же синтаксис остаётся и сейчас?AndreyHenneberg
11.04.2018 17:48Магнитные сердечники в 70-х? Вы не ошиблись? В 1966-1969 годах было принято решение о копировании IBM s/360, уже морально устаревавшей к тому моменту. Именно она стала основой ЕС ЭВМ, которая по-настоящему пошла в серию где-то в 1974 году. Магнитные сердечники — это несколько более ранняя технология. Первый вариант UNIX писался под DEC PDP-7, а стандартный Shell попал в состав UNIX только в 1977.
tyomitch
11.04.2018 18:26Магнитные сердечники в 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.
AndreyHenneberg
11.04.2018 18:40Интересно. Надо будет как-нибудь повнимательнее разобраться с этой частью истории железа.
SandroSmith
11.04.2018 15:25пока именно он не начнёт запускаться при запуске «Командной строки»
Он никогда не будет так запускаться. Потому что Командная строка в Win — это cmd.exe
Но в Win+X менюшке уже пару релизов как по умолчанию живёт пошик.AndreyHenneberg
11.04.2018 18:10Вот это и называется тайненьким знаньицем: вместо того, чтобы вывесить программу в основное меню, её закопали в какое-то отдельное меню, запускаемое отдельной комбинацией клавиш. Как бы крут ни был этот инструмент, пока пользователи его не видят, он бесполезен. Даже я, вынужденный периодически заниматься настройкой компьютеров с виндой, не знал этого. Что уж говорить об обычных пользователя?
tyomitch
11.04.2018 18:32Как бы крут ни был этот инструмент, пока пользователи его не видят, он бесполезен. Даже я, вынужденный периодически заниматься настройкой компьютеров с виндой, не знал этого. Что уж говорить об обычных пользователя?
Совершенно естественно, что инструмент, нужный 0.1% пользователей Windows, спрятан как можно дальше, чтобы обычные пользователи его случайно не запустили и что-нибудь при помощи него не повредили.AndreyHenneberg
11.04.2018 20:46И вот так, не показывая пользователю, что есть какой-то инструмент (оболочка), мы потом жалуемся, что пользователь тупой и не знает, как работать с компьютером, которым он пользуется каждый день.
tyomitch
11.04.2018 20:53Вы когда-нибудь писали софт для живых пользователей? Пользователь не хочет осваивать никаких инструментов, он хочет одну кнопку «сделать зашибись» во весь экран.
AndreyHenneberg
11.04.2018 21:14Да вот как-то постоянно пишу. Для живых пользователей. А те, кто хочет просто кнопку «Сделать зашибись», получают такую кнопку. Только всё, что она делает, сообщает, что «Теперь всё зашибись». А кто хочет выполнения некоторой реальной работы, формулируют задание и обучаются использованию полученным инструментом. Подавляющее большинство клиентом очень довольно.
SandroSmith
11.04.2018 21:08+1А что вы подразумеваете под «обычным меню»? Пуск? Так кто его оттуда запускает? Win+X — это не отдельное секретное меню, это не просто хоткей для «ПКМ по Пуску».
А обычным пользователям винды не нужен ни пошик ни cmd.AndreyHenneberg
11.04.2018 21:18Надо же! Всегда вызывал это меню просто кнопкой Win. А командная строка пользователям нужна, если в ней есть нормальная оболочка. Потому что удобно. Понятно, что о чём не знаешь, в том не нуждаешься. Но вот стоит такому «просто пользователю» показать удобства командной строки, как он начинает ею пользоваться. Может, не так активно, как я, но всё-таки.
SandroSmith
11.04.2018 23:59Просто кнопкой Win вызывается просто Пуск.
Я же говорю про вот эту менюшку
darthslider
11.04.2018 11:23Powershell стал удобоварим с 3ей версии. Количество использований WinApi резко упало и во многих случаях было замененно нативными командлетами.Насчет «ставить заказчику» — 2я версия по умолчанию уже стоит начиная с win7.
AndreyHenneberg
11.04.2018 14:20В WinXP его надо было ставить руками, насколько я помню. Если всё равно что-то ставить, то я предпочитаю интерпретатор нормального языка программирования. Опять же, как Вы сами указали, удобоваримым он стал с третьей версии, а я успел от него отказаться, ещё когда он, видимо, ещё из первой не вырос.
А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.darthslider
11.04.2018 14:29+1Powershell и не пытается быть универсальным. Это язык виндового админа, не программиста даже. Он довольно простой, понятный и логичный. Ну, на мой взгляд. Если вам надо рулить виндовыми ролями, то на каком-нибудь пайтоне это будет не тривиально, если вообще возможно. А тут, например, любые действия с AD нативными командлетами.
XP это отдельный разговор много по какому поводу. Но в современных OS Windows PS уже есть и при выборе между батником и ps скриптом я сейчас почти всегда выбираю второе.
VB, как мне кажется, как скриптовый язык в винде сейчас полностью заменен PS. Раньше его использовали просто потому, что он мог гораздо больше, чем cmd, и работал на любой виндовой системе, сейчас же эту роль выполняет PS, причем у него гораздо ниже порог вхождения и, на мой взгляд, он гораздо удобнее VB, хотя бы по тому, что в VB надо работать напрямую с WinApi, а не с удобными командлетами.AndreyHenneberg
11.04.2018 14:58Понял. Значит, сравнивать его с Bash и прочими «нормальными» оболочками некорректно, потому что это узкоспециализированный инструмент администратора, тогда как Bash — именно что пользовательская оболочка. Иначе бы он уже запускался именно в качестве общей оболочки, но даже в десятке этого нет — там по-прежнему в качестве оболочки командной строки используется cmd.exe.
darthslider
11.04.2018 15:04+1Я думаю, это больше вопрос совместимости. В PS выполняются все команды cmd, какие-то напрямую, какие-то являются алиасами для командлетов Powershell (например, когда пишешь dir на самом деле выполняется get-childitem).
Специализация на администрировании это фича PS, но это не единственное, что он умеет. То есть там просто есть еще и нативные модули для AD, hyper-v, sql и так далее. Я не специалист по пайтону, но не представляю сходу, что такого, можно сделать на пайтоне, чего нельзя сделать в PS.river-fall
11.04.2018 15:25в powershell можно сделать вообще всё с виндовыми службами (намного больше, чем в GUI), а причина одна — сам GUI (Server Manager, AD administrative tools) под капотом запускает тот же самый Powershell
darthslider
11.04.2018 15:27Начиная с 2012 — да. Не уверен, насчёт прям всё, но server manager точно генерит внутри себя PS команды. Какой-нибудь Computer Management думаю работает «по старинке».
Я скорее про то, что не виндовыми службами едиными.
saboteur_kiev
11.04.2018 15:29В баш принято отделять мухи от котлет, и в самом баше вызывать консольные утилиты, которые могут сделать все с виндовыми или линуксовыми службами.
Именно этот подход кажется более удобным и устойчивым к изменениями — собственно поэтому шелл-программинг живет так долго практически не теряя обратной совместимости, при этом оставаясь удобным инструментом с минимум устаревшего подхода.
Сейчас активно пишу шелл скрипты, которые работают и под вин и под линукс и радуюсь.
AndreyHenneberg
11.04.2018 17:34+1На Python можно, например, написать программу, не задумываясь о структуре конкретной ОС. Даже той, на которой пишешь эту программу. И она будет работать без явного привлечения системных библиотек. И даже будет работать на другой ОС. В частности, у меня таких случаев в практике, наверное, половина: пишу под Linux, потом всё работает под MacOS X или Windows. Но! Для того, чтобы что-то писать на Python или Bash, мне не нужно знать подноготную ОС, я просто запускаю внешние утилиты и передаю результат работы дальше по конвейеру. Ну и кое-какие инструменты по работе со строками доступны. А в PS надо прямо в недра системы лезть. Для чего он, собственно, и делался.
darthslider
11.04.2018 17:52То, что ПШ ограничен виндой это понятно. А в этих рамках?
AndreyHenneberg
11.04.2018 18:16Я через него могу общаться с ОС «человеческим» языком, используя как просто оболочку для повседневной работы? Вряд ли. Как мне только что сообщили, для вызова консоли с этим инструментом, надо нажать хитрую комбинацию клавиш, о которой я не знал, хотя регулярно вынужден кому-то что-то настраивать в винде, получить какую-то менюшку и в ней выбрать нужный пункт.
Второй момент — синтаксис. Не как отдельного языка программирования, а как оболочки, чей язык может быть прозрачно использован в качестве языка программирования. Если я правильно помню, синтаксис команд ветвления и циклов там такой же, как в cmd.exe, то есть довольно страшненький.darthslider
12.04.2018 09:31Можете, конечно. Я может быть не помню какой-то фундоментальный шорткарт, но cmd я на уровен мышечной памяти вызываю комбинацией win+r -> cmd -> enter. Вместо этого можно просто делать win+r -> powershell -> enter. Или сделать себе алиас ps.
Синтаксис циклов (на примере for) на мой взгляд не особо отличается от питона. Зато наличие объектов позволяет очень удобно работать с массивами в цикле. Банальный пример, взяли нужные компьютеры из AD по имени и тут же вывели любой их параметр или любое сочетание параметров.
AndreyHenneberg
12.04.2018 09:42Ну вот не нужны мне объекты, мне нужны имена файлов и их содержимое в виде текста. Потому что, если нужно что-то более сложное, я использую Python или другой язык программирования. PS — удобное средство для администрирования именно Windows. Оболочка для работы с объектами, интерфейс для платформы .NET, а не для ОС. Вчера кто-то разницу очень чётко расписал: Bash — интерфейс для ОС, для управления файлами и потоками, а PowerShell — интерфейс для платформы .NET и сравнивать его надо с другой утилитой.
darthslider
12.04.2018 09:48Так не нужны объекты — не пользуйтесь. Берите только имена файлов и их содержимое в виде текста (строки).
«Интерфейс для платформы .NET, а не для ОС» — простите, я не понимаю эту фразу.
Есть примеры Core версии Windows Server, где powershell это единственный интерфейс который у вас есть. И в этом случае это как раз «интерфейс для ОС, для управления файлами и потоками».
tyomitch
11.04.2018 15:14Пожалуйста, не надо путать VB и VBScript. Между ними не больше общего, чем между Java и JavaScript.
saboteur_kiev
11.04.2018 12:36установка bash еще больше расширила возможности FAR.
FAR всегда дружелюбно относился к CLI, и являлся отличным дополнением. Особенно в связке с ConEMU.
А такие команды как:
edit:<grep -P «myregexp» *.txt
А встроенные макросы, которые могут работать не только внутри редактора но и непосредственно в панелях?
rezdm
10.04.2018 20:43+2Я ставлю GNU Utilities и наслаждаюсь ls/grep/awk/find/… под виндой внутри cmd
AndreyHenneberg
10.04.2018 21:04Я тоже так делаю, когда приходится иметь дело с этой ОС на хоть сколько-то постоянной основе. Но эти утилиты работаю… не очень хорошо, потому что установка по умолчанию настраивает пути так, что они рассчитаны на работу в своей песочнице и вывести их на «просторы» основной файловой системы очень сложно. К тому же, у Windows отстойно реализованы конвейеры. Я полтора года назад работал в одной странной конторе, где на все машины была установлена винда и работать приходилось в ней, хотя всё, что я писал, должно было работать в Linux. В итоге, у меня была возможность сравнить работу этих утилит одновременно и в винде, и в Linux. Увы, даже на куда более мощной машине с Windows они работали гораздо медленнее, чем на слабенькой виртуалке и древнем нетбуке (моём личном).
Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.tyomitch
10.04.2018 22:58Вы не с Cygwin путаете? Это у неё песочница, а gnuwin32 работает родными для Windows способами.
AndreyHenneberg
10.04.2018 23:37Пробовал работать с Cygwin и MSys2. В обоих случаях создаётся песочница, корневая директория, в которой всё и работает. Выход за её пределы возможен и сделать это не особо сложно, но всё равно это именно песочница. И все прелести такой организации прилагаются: дополнительные действия по перемещению корня куда-то, выход на корневые директории дисков Windows через какие-то странные структуры и так далее. Примерно такой же геморрой, как и при работе с WINE под Linux. Если мне нужны какие-то программы, у которых есть нормальные сборки под Windows, я не могу их использовать — система пытается установить то, что есть у неё в репозиториях, а это, зачастую, устаревшие на несколько лет версии. При этом, тянется, к примеру, собственная версия GTK, даже если у меня в системе уже есть программы, для которых установлена эта библиотека. То есть такая вот изолированная область с софтом в стиле *nix.
С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.firk
11.04.2018 01:01Какие ещё настроечные файлы у софта типа grep? Там просто набор скомпилированных под винду бинарников, вероятно с исправленным кодом в тех местах где используются unix-специфичные функции. unxutils.sourceforge.net
AndreyHenneberg
11.04.2018 01:38А, Вы про этот набор. Ну так этого маловато: мне нужен был более широкий набор, а там уже без песочницы, видимо, не получается.
Arty_Fact
11.04.2018 11:21Не совсем вас понимаю, что вы подразумеваете под «полноценной консолью»? В Тотале есть консоль.
saboteur_kiev
11.04.2018 12:37Насколько удобно с ней работать в тотале?
Насколько удобно перемещать данные из консоли в редактор и обратно, видеть результат консоли например вместо одной из панелей?Arty_Fact
11.04.2018 15:52У меня не было кейсов, которые бы заставили меня пользоваться КС в FAR или TC, но я изучил на досуге вопрос, потому что меня заинтересовало верхнее сообщение.
Не настолько удобно, как в FAR. Невозможно ни вместо одной из панелей, ни скрывать окно менеджера, оставляя окно командной строки. Если же написать ping 8.8.8.8, то он просто откроет отдельное окно командной строки, как указал AndreyHenneberg ниже. Но можно пользоваться чем-нибудь типа cd %$APPDATA%AndreyHenneberg
11.04.2018 18:28То есть, по сути, консоли у него нет. Потому что открыть КС для текущей директории можно и в Проводнике, чем я иногда пользуюсь. Просто TC — чисто GUI-шная программа, тогда как FAR работает в текстовом режиме, в том же самом эмуляторе терминала, который использует КС, поэтому он просто передаёт уже запущенной оболочке ввод и отображает её вывод. Ну или как-то так: я не знаю, как именно это реализовано, потому что в исходниках не копался, хотя они и доступны.
AndreyHenneberg
11.04.2018 14:42Увы, не припомню такой. Разве что запуск, по сути, отдельного приложения «Командная строка», но это не то. Консоль там открывается одной комбинацией в директории текущей панели, работает с файлами из этой панели (например, передаются выделенные в панели файлы)? Подробности, как это делается в FAR, я сейчас не вспомню, помню только, что как-то делается, а вот в Midnight Commander достаточно использовать placeholder %s и выделенные файлы будут вставлены в командную строку.
Andy_Big
11.04.2018 16:48+1Подробности, как это делается в FAR, я сейчас не вспомню
Control+Enter вставляет имя текущего файла из панели в командную строку. Причем имена с пробелами обрамляет в кавычки.
AndreyHenneberg
11.04.2018 18:23Я не про это. В MC всё точно так же, за исключением того, что не Ctrl-Enter, а Alt-Enter и имена с пробелами не заключаются в кавычки, а эти пробелы экранируются. Я имел в виду возможность вытряхнуть выделенные имена в командную строку стразу пачкой. И да, я знаю, что именно в FAR это есть, разве что не помню, как именно это делается, и сам им с удовольствием пользуюсь, когда надо разгребать горы файлов под виндой: на мой взгляд, ничего лучше под винду ещё не написали. А вот сборки MC под винду настолько убоги, что вызывают желание плакать и биться головой о клавиатуру, при том, что в родной среде он FAR-у не уступает, разве что нельзя туда прикрутить почтовый агент, но это уже извращение для любителей тонких изврашений.
Andy_Big
11.04.2018 18:31Я имел в виду возможность вытряхнуть выделенные имена в командную строку стразу пачкой
А, тогда прошу прощения, это я не знаю как делается :)
Разве что Control+Insert (копирует имена всех выделенных файлов) и потом Shift+Inser.AndreyHenneberg
11.04.2018 18:43+1Это можно посмотреть в подсказке, доступной из панелей — там описан синтаксис шаблонов командной строки. Там примерно тем же способом всё делается, только вариантов больше, за что приходится платить больше сложностью самых базовых конструкций.
saboteur_kiev
12.04.2018 00:13выделяете файлы, жмете Ctrl+Insert и имена копируются в буфер. Можно сразу вставить в строку стандартным Ctrl+V (Shift+Insert).
Можно вставить путь одной из панель через Ctrl + [ или ]
Можно подвинуть панели вверх, чтобы видеть пару строк консоли и соответственно видеть результат выполнения.
Можно вообще много чего делать. Например через Netbox подключится к удаленной sftp сессии на линукс, и не только ходить там по файловой системе и копировать файлы, но и сразу выполнять обычные линукс команды на удаленной системе.
В общем если с винды часто лазите на линукс-машины, и часто работаете со скриптовыми языками (баш, питон, cmd, etc) то FAR становится мега-удобным.
SchmeL
11.04.2018 11:15+2Total Commander ничем не хуже. Вкусовщина конечно.
Есть одна проблема — он платный и только под windows. А щелканье по цифрам во время запуска не освобождает от ответственности. Давно перешел на открытый double commnader, который поддерживает плагины от TC.
EvgeniyNuAfanasievich
11.04.2018 12:45+1Тотал платный же для коммерческого юзанья :-(
F0iL
11.04.2018 21:08есть еще Double Commander как опенсорс-альтернатива, но детально функционал не сравнивал.
TechnoMag
10.04.2018 22:34У меня FAR долго запускается. Пробовал голый FAR — без плагинов, на XP, на Win 7 — запуск дольше чем Total Commander, и память кушает больше, чем Total Commander. Предпочел Toatal. Хотя сам вспоминаю времена Norton Commander… Еще минус FAR — консоль Windows, шрифты. Midnight Commander более приспособлен к изменению размера консоли и изменению шрифтов.
firk
11.04.2018 01:06У меня запускается за, кажется, меньше 0.1 сек (просто мгновенно появляется окно с панелями). Что вам с консолью не нравится тоже непонятно — во-первых, это не чаcть FAR'а (так же как и не часть Midnight Commander'а, её и там и там рисует системная графическая оболочка, либо текстовый режим видеокарты с опять же системными шрифтами), а во-вторых она настраивается как угодно.
dom1n1k
11.04.2018 11:10+1Такое бывает, если в Винде как-то криво настроена сеть — Far может долго тупить на чтении неотвечающих сетевых шар.
В обычных условиях Far запускается полсекунды.
saboteur_kiev
11.04.2018 12:40У меня FAR долго запускается.
Доли секунды. Ну и можно вообще не закрывать месяцами — утечек не вижу.
память кушает больше, чем Total Commander
Простите, что? сколько килобайт, ну ладно мегабайт там разницы? Это же не браузеры, у которых сотня мегабайт туда-сюда.
Еще минус FAR — консоль Windows, шрифты
Использование консоли — это не минус, это особенность, из-за которой большинство пользователей ФАР-а и сидят на ФАРе-.
А если вам не нравится шрифт — в 2018 году сидеть на FAR-е без ConEmu, который решает все вопросы с шрифтами, ресайзом и выделением текста — показатель, что вы в принципе не активный пользователей панельного менеджера.firk
11.04.2018 15:31в 2018 году сидеть на FAR-е без ConEmu, который решает все вопросы с шрифтами, ресайзом и выделением текста — показатель, что вы в принципе не активный пользователей панельного менеджера.
Никаких ConEmu не знаю, и ничего похожего на перечисленные проблемы в FAR в консоли win7 не замечал. Пользуюсь активно. Причём тут номер года, вообще непонятно.
saboteur_kiev
12.04.2018 00:14А попробуйте быстро выделить кусок текста в консольном экране?
Как вы это делаете в стандартной win7 консоли?firk
12.04.2018 01:06right click — mark — выделяю — enter
saboteur_kiev
12.04.2018 01:20А я просто выделяю. как в putty.
А с ALT могу выделить блоком.
p.s. вдобавок, подозреваю, что у вас не стандартная консоль, ибо в стандартной win7 консоли нужно сперва leftclick на меню слева-сверху, а уже там markfirk
12.04.2018 01:32А да, оказывается right click не работает если запущена программа, использующая мышь. Но копировать текст прямо из панелей таким образом ни разу не приходилось, да и не знаю зачем это. Запустите cmd или что-нить похожее — right click будет. Ну да, в putty чуть поудобнее, но лишь чуть. У фара хоткей Alt-Ins для консольного копирования.
saboteur_kiev
12.04.2018 11:13А даблклик у вас тоже не работает и не выделяет ничего?
Как зачем? Именно в этом и заключается основной момент — чем вы занимаетесь. Для тех, кот активно работает со скриптами, с управлением файлов и конфигурациями, очень удобно копировать что-то с экрана и сразу вставлять в консоль.
В FAR+conemu я могу это делать так, как в gui-шных putty например — то есть просто выделение мышкой, выделение дабл-кликом слова, выделением трипл-кликом всей строки. Быстро и удобно.
Я как бы подозреваю, что админов и продвинутых пользователей консолей не так много, но именно для них подобные инструменты будут удобнее любых других. К хорошему быстро привыкаешь.
tyomitch
12.04.2018 09:53p.s. вдобавок, подозреваю, что у вас не стандартная консоль, ибо в стандартной win7 консоли нужно сперва leftclick на меню слева-сверху, а уже там mark
Либо Alt+Space, что быстрее.
tyomitch
12.04.2018 09:51Внезапно, Ctrl+M
saboteur_kiev
12.04.2018 11:14Нет
tyomitch
12.04.2018 11:40У меня нет под руками Win7, чтобы проверить. На моём Win10 работает.
В любом случае, Alt+Space — E — K должно работать, притом быстрее, чем манипуляции мышкой.saboteur_kiev
12.04.2018 11:52То есть вместо того, чтобы
1) выделить мышкой
вы предлагаете
2) ALT+Space — E — K и затем выделить мышкой.
И вы утверждаете, что второй вариант быстрее?
И вставить тоже не
1) Ctrl-V
а
2) ALT+Space — E — P?tyomitch
12.04.2018 12:03Нет. Я утверждаю, что мой вариант быстрее, чем предложенный вами выше в ветке «шариться мышкой в двухуровневом меню, и затем выделить мышкой.»
sumanai
10.04.2018 15:56Его код уже утекал с кодом NT4, так что ничего особо нового там нет. Хотя лицензия MIT радует.
yul
10.04.2018 16:08Какой-то некроэксгибиционизм. Какую ценность сейчас представляет этот код? Разве в какой-нибудь музей окаменелостей программного кода )
firk
10.04.2018 16:14Что за набор дезинформации. Кроме того, что как уже выше сказали, File Manager никогда не становился заменой нормальным альтернативам — Norton Commander и его клонам
Поддержки длинных имён файлов не было, как и поддержки пробелов в именах. Если Диспетчеру приходилось отображать длинные файлы, то он показывал первые шесть символов, затем символ тильды "~" и число, обычно единицу.
Это не диспетчер, это старое file api операционной системы. Про пробелы — отдельное враньё, их поддерживал и DOS с давних времён.
вы оцените потрясающую обратную совместимость программ под Windows, ведь софт 28-летней давности почти без модификаций работает на последней ОС
Это не достижение, это норма. Причём по-хорошему он должен работать не "почти без модификаций" а вообще без модификаций.
Специально для установки Windows 3.0 приходилось докупать несколько мегабайт оперативной памяти, а иногда и апгрейдить процессор, например, с 20 МГц до 40 МГц.
3.1 (и тем более 3.0) нормально работал и на около-10МГц
Апгрейд до 40 это скорее про Win95.Alozar
10.04.2018 16:33+1Это не достижение, это норма. Причём по-хорошему он должен работать не «почти без модификаций» а вообще без модификаций.
А потом окошки ругают за тормознутость из-за обратной совместимости, когда в каждой версии необходимо поддерживать и эмулировать все предыдущие, включая баги.
SergeyMax
10.04.2018 17:58Про пробелы — отдельное враньё, их поддерживал и DOS с давних времён.
Нет, пробелы не поддерживались. Нажмите Ctrl+N в фаре, чтобы посмотреть, как выглядели имена в DOS.
tyomitch
10.04.2018 18:27Нет, пробелы поддерживались. en.wikipedia.org/wiki/8.3_filename#Directory_table
SergeyMax
10.04.2018 19:13Окей, передо мной консоль MS DOS 6.22. Какие команды мне надо набрать, чтобы убедиться в верности ваших слов?
tyomitch
10.04.2018 19:37
SergeyMax
10.04.2018 19:57Ой, про qbasic могли бы и не стараться, это первое, что в гугле находится)
tyomitch
10.04.2018 20:07Раз пользоваться гуглом вы умеете сами, тогда в чём состоял ваш вопрос?
SergeyMax
10.04.2018 20:28Вопрос состоял в том, поддерживает ли дисковая операционная система имена без пробелов, или нет. Выяснилось, что FAT и API операционной системы такие имена поддерживают, а сама DOS (в виде своих команд) — нет. Я правильно подвёл итог?
tyomitch
10.04.2018 20:45
DMGarikk
10.04.2018 22:19у вас PC DOS, а MS?
tyomitch
10.04.2018 22:36PC-DOS от MS-DOS отличатся только копирайтом; программно они идентичны. PC-DOS поставлялась вместе с новыми компьютерами, MS-DOS — как отдельный продукт.
DMGarikk
10.04.2018 23:57разве?
в pcdos и системные файлы по другому назывались и набор утилит был другой в поставкеtyomitch
11.04.2018 08:08Я подумал было, вы спрашивали про саму ОС, а не про набор поставляемых утилит?
Очевидно же, что поддержка пробела в именах не зависит ни от набора поставляемых утилит, ни от имён системных файлов.
В любом случае, вы можете сами зайти на www.pcjs.org и там поэкспериментировать с различными досами.
SergeyMax
11.04.2018 08:28Поясните пожалуйста, что вы хотели сказать вашей картинкой?
1) В именах поддерживаются знаки вопроса
2) В именах поддерживаются пробелы
3) В именах поддерживаются пробелы и знаки вопроса
4) В именах не поддерживаются ни пробелы, ни знаки вопросаiig
11.04.2018 10:11Древнее проснулось зло ;)
5. Походу магия PC DOS умеет превращать знак вопроса (недопустимый символ для FAT) в пробел (допустимый).tyomitch
11.04.2018 12:00Вы так говорите, как будто впервые видите знак вопроса в качестве wildcard character. Он означает «оставить в этом месте тот символ, который уже стоял»; например,
ren magic look?at.meпереименует файлmagicвlookсat.me. Осталось добавить, что имена в FAT дополняются до 8.3 пробелами — вот и объяснение, почему команда на моём скриншоте оставила внутри имени пробел.
tormozedison
12.04.2018 23:25Здрасьте, какой же это QBASIC? Это BASICA. Работает только на оригинальных матерях IBM. Кто вспомнит, почему?
firk
10.04.2018 18:45Это имена с пробелами, созданные через новый интерфейс. Если же создать имя с пробелом через старый (дос или его эмулятор в win9x, насчёт эмулятора в новых виндах и ntfs не проверял) — они будут показываться нормально везде.
DrPass
10.04.2018 16:57Специально для установки Windows 3.0 приходилось докупать несколько мегабайт оперативной памяти, а иногда и апгрейдить процессор
Windows 3.0 вполне сносно работала на 5МГц процессоре с 640 Кб ОЗУ, и с CGA-дисплеем. Вот 3.1 уже была попрожорливее, и требовала как минимум процессора с поддержкой защищенного режима.
vdem
10.04.2018 16:58Если Диспетчеру приходилось отображать длинные файлы, то он показывал первые шесть символов, затем символ тильды "~" и число, обычно единицу. Если папка содержала несколько файлов с одинаковыми первыми шестью символами в названии, то им присваивались цифры 2, 3 и так далее.
Это не он «показывал», это формат записи длинных имен в FAT в стандартную запись о файле — поскольку в файловой системе просто не было предусмотрено места для длинных имен. Я уж не помню как там хранились длинные имена, но как-то через Ж. Так что диспетчер не то чтобы специально показывал тильду и число, он просто показывал то, что записано в поле с именем файла в файловой системе, и не умел читать длинные имена.Andy_Big
10.04.2018 17:32Я уж не помню как там хранились длинные имена, но как-то через Ж
Через несколько связанных записей, ЕМНИП.
scg
10.04.2018 17:55Что-то вроде того. В директорию, после основной записи файла добавляли несколько файловых записей с атрибутом ATTR_LONG_NAME (15) и первым байтом шел номер последовательности куска имени, а по остальным полям разбрасывали 13 символов в кодировке UCS2-LE. Да, еще чексумма зачем-то добавлялась всего имени. Старые операционки файлы с неправильным атрибутом игнорировали, а новые — интерпретировали его в длинное имя.
Andy_Big
10.04.2018 18:02Да, что-то такое, я уже точно не помню. По-моему там еще в каждой записи кроме номера текущего куска указывалось и общее количество записей.
Когда-то давным-давно делал на микроконтроллере CD/MP3-плеер, работающий с CD-приводами и жесткими дисками, разбирал FAT16 и FAT32. Распространенных библиотек для контроллеров тогда еще не было, все приходилось делать самому :)scg
10.04.2018 18:35По-моему там еще в каждой записи кроме номера текущего куска указывалось и общее количество записей.
Сейчас посмотрел: у последнего куска имени в номере выставляется 6-й бит. Получается, что не больше 32-х кусков может быть. Оставшиеся символы в записи заполняются 0xff-ками.
Уменя была прямо противоположная задача: эмулировать флэшку с FAT32 :) Я-то сам этого тоже уже не помню, но SVN со старым кодом под рукой.
Nikeware
10.04.2018 18:50«Эндрю Шульман — Неофициальная Windows 95»
Весьма занимательное чтиво по этому поводу.
uanet
10.04.2018 17:13Где-то лежат несколько установочных дисков Hyundai MS Windows 3.0 (честно купил в книжном магазине коробку), 720КБ 3,5" дискеты, штук 5, кажется.
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 раза больше ОЗУ» формула уехала в сторону «своп лучше выключить, совсем».vitalyvitaly
10.04.2018 19:59Я запускал когда-то софт Win 3.1 под 80286 1 Mb. Это был конечно, еще тот номер — во первых, даже выкраивая из памяти каждый байт, работали далеко не все программы, кроме стандартной поставки. Но если что-то работало — по воспоминаниям СУБД порождала свопинг минут на 15 буквально после каждой элементарной операции.
saboteur_kiev
11.04.2018 12:42smartdrv.exe?
YMA
11.04.2018 15:39smartdrv.exe сам памяти хочет под кэш, и чем больше — тем лучше, а на машине с 1МБ памяти — лишней памяти и тогда не было. Так что увы, он в такой ситуации не очень поможет, еще и собой память займет.
saboteur_kiev
12.04.2018 00:15smartdv для fat системы загружал дерево каталогов в память и работа с файловой системой ускорялась в РАЗЫ. даже на 640 кб.
vitalyvitaly
11.04.2018 16:30На мегабайте ОЗУ?! Достаточно бессмысленная затея, хотя чистые DOS-приложения теоретически можно было ускорить. Но для Windows 3.1 это только приведет к растрате драгоценной памяти. Вот с 2 мегабайтами теоретически что-то можно было попытаться.
DMGarikk
10.04.2018 17:19+1особо было прикольно, например через NC скопировать папку Мои документы с кучей новомодных файлов и названий папок на русском языке, с пробелами и длинными именами на внешний диск, а потом осознать что все это превратилось в мешанину из filen~12 filen~13 и пипец ;))
terra-slav
10.04.2018 19:43-1M$ в своем репертуаре — кидает гнилые кости в толпу, стараясь показать свою неописуемую щедрость=))
kloppspb
10.04.2018 21:23докупать несколько мегабайт оперативной памяти
Что-то на припоминаю, разве это было реально? Докупить и вставить в смысле. Вот купить и вставить вставить сопр в 386 (если плата позволяет) — да, но память...
Andy_Big
10.04.2018 21:49Да, было реально. На работе, помню, докупили и вставили в 386 4 МБ (насколько я помню) оперативки, так два из них сразу пустили под виртуальный диск для оперативных задач :)
quwy
10.04.2018 22:16На платах с i386 и аналогами уже нормой были 30-пиновые SIMM, до 8 слотов. Были и платы с DIP-панельками. В общем нормальные машины (не ноутбуки и не всякие брендовые выпендрежи) позволяли наращивать RAM без проблем.
firk
11.04.2018 01:12Пиновые — это не SIMM, а SIPP, использовались в основном на 286. На 386 они уже выходили из употребления (устарели по причине механической ненадёжности штырьковых контактов), в пользу SIMM.
quwy
11.04.2018 03:10Под пином уже давно понимается любой вывод, даже термин pinout применяется к любой распиновке, не только к DIP-микросхемам. И во времена троек говорили именно «30-пиновый SIMM», а потом повился и «72-пиновый SIMM» для четверок и первопней.
ikmsk
11.04.2018 13:32Диспетчер файлов из Windows быстро вышел на первую строчку в списке самых популярных репозиториев GitHub за сутки.
Это не удивительно — я, например, даже не дочитав статью, собрал этот проект чтобы вспомнить замечательное время простых интерфейсов.
aleksandros
11.04.2018 15:1625 лет прошло, а Эксплорер-Проводник как не умел делать «умную» ширину столбцов, так и не умеет.
Alexsandr_SE
Не понял фразы. "Программа пришла на смену управлению файлами в MS-DOS и стала заменой многочисленным файловым оболочкам вроде Norton Commander, хотя многие пользователи по привычке ещё долгие годы пользовались NC и Windows-версией Total Commander."
Тотал фар и т.п. обладают мягко говоря куда большими возможностями. Именно поэтому они применяются до сих пор, хотя и заметно меньше.
saboteur_kiev
Вполне нормальная фраза.
На смену управлению файлами в MS-DOS, диспетчер файлов пришел в ранних версиях Windows.
На тот момент ни тотала ни фара еще не было, они появились уже во временя win-95, если не во время OSR-2.
lieff
Был Dos Navigator. Собственно из того что я видел, все переходили NC->Dos Navigator, потом в винде уже ->Far или ->Total Commander. Я ни разу не видел в своем окружении, чтобы тот, кто ими пользовался, перешел на стандартный проводник.
DMGarikk
тотал(тогда еще windows) появился в 93 году
saboteur_kiev
А публичный Windows 1.0 в 1985.
Scooby-do
Total Commander раньше назывался Windows Commander, но потом кто-то на кого-то подал в суд.
Alexsandr_SE
Тотал появился позже, но до него был Norton Commander, это ПО еще с седых времен DOS было.
DN появился кажется еще в 91году.