После семи месяцев разработки опубликован (https://mail.gnome.org/archives/mc-devel/2019-January/msg000...) выпуск консольного файлового менеджера Midnight Commander 4.8.22 (http://www.midnight-commander.org/), распространяемого в исходных текстах под лицензией GPLv3+.Список основных изменений (https://www.midnight-commander.org/wiki/NEWS-4.8.22):
- Добавлена поддержка операций клонирования файлов, предоставляемых файловой системой Btrfs (применение BTRFS_IOC_CLONE для создания копии файла через добавление на уровне метаданных дополнительной ссылки на уже имеющиеся данные, без фактического копирования содержимого файла);
- В заголовке окна с результатами поиска обеспечено отображение файлового шаблона и маски поискового запроса;
- При поиске файлов теперь отдельно запоминается состояние поля поиска по содержимому, что позволяет при поиске из встроенного просмотрщика или редактора не заполнять это поле старым значением из файлового поиска;
- Улучшена поддержка окружения IBM i 7.3 PASE (Portable Application Solutions Environment);
- Улучшена обработка ошибок в процессе создания жёстких ссылок;
- Добавлена возможность переопределения формата приглашения ввода в оболочке Fish;
- Обеспечено сохранение времени модификации и доступа (mtime и atime) при копировании файлов через SFTP;
- Во встроенном редакторе добавлена подсветки синтаксиса сборочных сценариев Meson (https://www.opennet.ru/opennews/art.shtml?num=49774) и реализована подсветка ключевого слова "null" для скриптов на языке PHP;
- В конфигурации внешних обработчиков улучшено распознавание форматов
MS Office и добавлена поддержка вызова проигрывателя MPV в случае невозможности вызвать "mplayer -identify";
- Устранена проблема, из-за которой операция перезаписи одного файла выполнялась без вывода диалога подтверждения операции;
- Решены проблемы со сборкой на платформах Apple;
- Налажен процесс копирования и перемещения файлов при наличии в имени или пути обратного слеша;
- Устранены крахи, возникавшие при установке соединения через FSTP и при возврате из командной оболочки.
URL: https://mail.gnome.org/archives/mc-devel/2019-January/msg000...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49895
На сколько помню его перестали развивать. И тут такое.
https://github.com/MidnightCommander/mc/commits/masterПерестали развивать? Серьезно? У них стабильно по паре версий в год, емнип.
>Серьезно?Да, несколько лет назад проект был по факту заморожен. Потом его подняли, отряхнули от пыли и продолжили развивать.
Просто mc это такая программа, номером версии которой никто не интересуется и поэтому за новостями тоже никто не следит. Так что назнание текущего состояния -- вполне нормально.
> Потом его подняли, отряхнули от пыли и продолжили развивать.Тогда уж в единственном числе. Там, судя по git, один человек (aborodin) всё пилит.
> Просто mc это такая программа...которая не нужна (или устраивает "как есть") подавляющему большинству тех, кто мог бы развивать, и нужна тем, кто развивать (или даже чинить) обычно неспособен.
А тут сложилось то самое сочетание, когда наши люди с привычкой к vc.com всё-таки взялись. Кстати, один из предыдущих майнтейнеров от GNU был тоже наш соотечественник, Павлом зовут.
Андрей, Сергей и все-все-все -- спасибо за труды :)
Проблема MC в том, что это нерасширяемый говнокод с начала и до конца, который очень тяжело поддерживать + адова смесь для обработки файлов по расширениям и VFS, который просто мрак.MC на моём top end компьютере полторы минуты открывает архив с ~100K файлами, потому что там awk/sed и прочая дрянь - это просто ад.
Far в Linux (wine) работает лучше, чем MC на порядок.
// b.
mc и его ужасная работа с архивами, особенно с zip - благодаря этому запомнил параметры консольных архиваторов. А вот из-за mcedit так и не смог vim пользоваться без шпаргалки
Значит помимо прямых функций он оказал на вас ещё и положительно-обучающее влияние. Команды архиваторов выучили, а vim что с mcedit что без зубрить не перезубрить...
> а vim что с mcedit что без зубрить не перезубрить...Да ладно, vimtutor пройти за четверть часа -- уже много чего полезного может к пальцам прилипнуть и начать время экономить.
С каких пор пор использование vim стало укладываться в vimtutor? Серьёзно? Прочитано несколько книг и куча сторонних мануалов, использую его больше 7 лет, но до сих пор считаю, что новичёк в нём и часто открываю что-то новое. Использовать вим на основе лишь вимтутора - глупая до безобразия затея
> С каких пор пор использование vim стало укладываться в vimtutor?Да нет же, там в контексте речь была о _начале_ освоения, а не о _всём_ использовании.
А чем хороший инструмент отличается от посредственного (хотя оба применимы) -- так это редко кем встречаемым "потолком", как мне видится :)
Ну, если уж совсем на начальном-начальном, то для вима хватит трёх команд: i - редактировать, :wq - сохранить, :q! - выйти без сохранения. Ну ещё ESC жать после редактирования
Что касается zip, то он не нужен. На сей счет есть tar и куча отличных компрессоров на выбор.
Far нэтивно работает в Linux. MC на его фоне - да, теперь в тени.Ставил под Ubuntu/Mint/Raspbian/Armbian/Debian по инструкции:
https://github.com/elfmz/far2l
А mc нативно работает в aix, solaris, hp-ux и т.д.
Их проблемы натуралам не интересны.
> Far нэтивно работает в Linux. MC на его фоне - да, теперь в тени.Собрал побаловался. Выглядит и работает вполне аутентично. Аккуратненько.
Недостаток - оно иксовое, эмулирует консоль в окошке.
Спасибо, что напомнили про far2l.
Я уже давно пользуюсь mc, потихоньку привык. Но сейчас запустил far2l - всё же far мне нравится больше. mc пользоваться не перестану, но, наверное, в большинстве случаев буду пользоваться far2l.
>VFS, который просто мрак.VFS элементарно расширяется плагинами с простейшим шелл-интерфейсом
Зато подсветка синтаксиса в mc работает в разы быстрее и незаметно для глаза, в отличие от ФАР.
Лично для меня это куда важнее каких-то там зипов. Родные tgz/txz открывается вполне шустро.
Такая программа не нужна в роли "полностью отказаться от shell и заменить на mc".В качестве дополнительного инструмента очень удобная вещь.
А чем его заменить для одноразовых действий, которые нет смысла скриптовать?Нужно различать полезность и необходимость, говорю как пользователь мыши в gvim.
Посмотри на vifm
emacs + sunrise commander ;)
А можно поинтересоваться, а зачем оно надо? В чем прикол пользоваться подобными штуками тем более под линуксом? Ладно там - винда, но и теперь с wsl и в этом необходимость отпала.
Ты вот сейчас спрашиваешь зачем нужен файловый менеджер? Серьёзно?
Я не это спрашивал.
Отлично! Спасибо за ньюз.
Он всё ещё не умеет показывать содержимое папки тайлом тумбнейлов!!!!11 О, какую боль это причиняет моей любви к прогрессу!!!!!!11
Любители прогресса должны страдать^w уметь дописывать недостающие фичи.
> Любители прогресса должны страдать^w уметь дописывать недостающие фичи.Вы же их вот только что оскорбили!
Я??7 Это всё прогресс!
Это не задача ФМ, поставь например geeqie.
>Добавлена поддержка операций клонирования файлов, предоставляемых файловой системой Btrfs (применение BTRFS_IOC_CLONE для создания копии файла через добавление на уровне метаданных дополнительной ссылки на уже имеющиеся данные, без фактического копирования содержимого файла);А чем это отличается от обычной жёсткой ссылки?
Тем, что получаются все-же разные файлы. Это как снапшот, только файл. Изначально все блоки общие, но при изменении одной из копий выделяются новые.
Видимо, тем, что при изменении данных по одной жесткой ссылке меняются данные по всем ссылкам, а в случае BTRFS происходит COW.
> Обеспечено сохранение времени модификации и доступа (mtime и atime) при копировании файлов через SFTP;Ура! Спасибо разработчикам!
Доброе дело! Спасибо!
А распаковка зипов все так же смертельно медленна. И все также тикеты на это закрывают как "дубликат #3", который вообще отмечен как "new enhancement" и которому 10 лет.
Ах да, забыл про "A lot of changes in VFS layer are required for this issue. That will be possible only after 4.8.0 release.", который оставлен 7 лет назад и который вроде бы как должен пояснить почему тикет никто не исправляет.Впрочем, все успешно обходятся командной строкой и unzip для таких случаев.
это давно уже стало не багом, а свойством, как смерть или налоги
Вот в FARe было классно сделано. Для каждого расширения имен архивом можно было прописать свою команду оперирования с архивом. Естественно для большинства их них в древние времена ставил RAR, ну а позже 7z.
Сейчас когда зипую коллекцию файлов fb2 тоже в скриптике зипования прописал 7z, тем более что он очень медленно и успешно развивается под Линухом.
Можно сделать проще и намного элегантней, скрипт типа такого:
...
for n in $@
do
if [ -f "$n" ]; then
case "${n%,}" in
*.tar.bz2|*.tar.gz|*.tar.xz|*.tbz2|*.tgz|*.txz|*.tar)
tar xvf "$n" -C $(dirname "$n") || 7z x "$n" -o$(dirname "$n") ;;
...
*.zip) unzip "$n" -d $(dirname "$n") || 7z x "$n" -o$(dirname "$n") ;;
...
esac
else
echo "'$n' - file does not exist"
return 1
fi
done
...
P.S.Разные типы и подтипы архивов (здесь не стал все указывать), распаковываются через родной распаковщик, либо 7z в случае отсутствия. Это можно запускать через .desktop-файл помещенный в /usr/share/applications из любого GUI- или console- файлового менеджера.
> Можно сделать проще и намного элегантней, скрипт типа такого:
> for n in $@...спотыкнётся на первом же аргументе с пробелами, тогда уж "$@". :)
Точно, спасибки...
Че-то там сломали с поиском... :(F2=>m=>rsync=>Enter=>F7=>-f=>Enter
нашел "exclude-from", ищем дальше Shift-F7=>Continue from beginning?
т.е. больше ничего не нашел, хотя вообще-то ниже есть
опция '-f, --filter=RULE add a file-filtering RULE'
Лично для меня MC - это один символов GNU/Linux.
Именно MC открыл мне дорогу в этот прекрасный мир.
Автору и всем, кто продолжает сопровождать этот проект - мой низкий поклон.
С женщинами интереснее и приятнее, братан. Попробуй, вдруг понравится?
https://github.com/gokcehan/lf
7 месяцев на это?))) походу они пальцем раз в день одну клавишу нажимают)))
Покажите как надо)
Благодаря МС лет 12 назад я наглядно понял, какие существуют баги в ликуксе 1) баги-фичи: двойной Esc когда казалось бы логично иметь один; 2) глобальные-могилой-исправляемые баги: отсутствие адекватного прогресс-бара при копировании на флешку; 3) локальные-говнобаги, для которых надо ставить костыли: загрузка мс полчаса на некоторых системах, если не прописать в етц-хостс резолв себя на 127001.МЦ все это очень компактно иллюстрирует, под эту классификацию попадает большинство багов в линухе
1) Входит в привычку и не замечаешь.
2) А что не так с ним? Шиндовс может отрапортовать что все записалось, однако необходимо сделать аналог umount перед вытаскиванием. Если же речь о сколь-нибудь больших объемах, то все отображается адекватно.
3)дык хостнейм чому задал, но не прописал в днс/hosts/yp? Такое поведение скорее плюс, лишний раз по лбу лентяю.
1) если бы ты понимал как работает нормальная консоль, то ты бы знал, что введение "одного ESC" убьет половину ее функционала, превратив ее в некое подобие msdos-о-виндового убожища.. но зато зато да - одно esc для мышевозера-неосилятора.
2) адекватный прогресс-бар в принципе невозможен при "адекватном кешировании" на уровне vfs, потому что он будет показывать всегда мгновенную скорость в начале и непонятное нечто в конце "процесса". ну или убить все кеширование и сделать как в венде - опять таки в угоду...
3) вообще-то баг в голове админа этого самого локалхоста. хотя тут соглашусь - это можно было бы резолвить в фоне.в общем типичное виндузячье мнение. мнение человека, который совершенно не понимает о чем говорит и как "оно все" работает, точнее как должно..
> ну или убить все кеширование и сделать как в вендеAFAIR, венда вообще-то делает абсолютно то же самое, кэширует и пишет потихоньку на медленный девайс (флэшку) в бэкграунде