Midnight Commander 4.8.16

Предоставлять в новости ссылку на github для проектов которые там хостятся - хороший тон, потому что повышает вероятность что кто-нибудь заведёт issue или пришлёт pull request.

У них для этого целый собственный сайт есть, но ладно, ссылку добавил.

Хорошая и нужная утилита. Иногда, просто незаменимая.

Они непонятно где хостятся. Репозиторий и багтрекер есть и на их сайте и на гитхабе. Параллельно и с разными тикетами.

Улучшен поиск файлов: при пустом имени файла теперь теперь выводятся все встретившиеся файлы

Не понял: Все встретившиеся «пустые файлы»?

Скажите хотя бы, как создать файл с пустым именем!

Файл — именованная область данных на носителе информации. (c) Определение.

sudopacman, поменяй «при пустом» на «при незаданном», что ли...

Они непонятно где хостятся

Они понятно, где хостятся. Думаю, вешать issue на github неправильный момент: их там просто меньше.

Вот! А говорили что сдох.

Иногда, просто незаменимая.

Например? А то я так и не смог найти ей применение.

Надо бы вбросить.
[trollmode]Когда же наконец появиться удаление в Корзину?[/trollmode]

Мне вот интересно, поиск файла по пустому имени файла это кул, а поддержку просмотра сетевого окружения не хотят добавить, хотя бы как в FAR'e?

Скажите хотя бы, как создать файл с пустым именем!

Вот я и не понимаю как должны «пустые» или «незаданные» файлы встретиться с чем-то?

Какой будет вывод при «пустой-незаданной строке»?

Все файлы в текущем каталоге? Аналог ls ./*?

Аналог ls ./*?

Да. Вместо * теперь достаточно пустоты.

Я уже ничего не могу поменять, стучись в спецтопик.

Отличная новость! Отличный файл-менеджер! Джва года ждал!

Для Debian 8 http://software.opensuse.org/download.html?project=home:Sunderland93&pack...

убрана опция «Search for content», поиск с учётом содержимого теперь отключается путём указания пустого значения в поле «Content» .

Зря. Так уже было в старых версиях. Но с галочкой нагляднее.

а поддержку просмотра сетевого окружения не хотят добавить, хотя бы как в FAR'e?

FTP и SCP из коробки есть, а если ты имел в виду именно виндовое сетевое окружение (SMB/CIFS) - задача интересная, да, но при вкомпиливании по умолчанию слишком много потянет, а можно ли это для mc сделать отдельным модулем, я не знаю. Во всяком случае, приколачивать mc к самбе гвоздями я бы очень не хотел.

Чем в этом плане хорош FAR, кстати - там всё модуляризируется через DLL с открытым API.

FTP и SCP из коробки есть, а если ты имел в виду именно виндовое сетевое окружение (SMB/CIFS) - задача интересная, да, но при вкомпиливании по умолчанию слишком много потянет, а можно ли это для mc сделать отдельным модулем, я не знаю. Во всяком случае, приколачивать mc к самбе гвоздями я бы очень не хотел.

А не прикрутить ли к mc какой-нибудь простой, но универсальный протокол наподобие 9P для общения с процессами-плагинами? А уж плагины пусть тянут хоть самбу, хоть чёрта лысого?

IMHO,единственный вменяемый файловый менеджер

Во встроенном текстовом редакторе добавлена подсветка синтаксиса языка Go.

Это конечно очень нужно и важно, но может когда-нибудь подсветку баша поправят?

Иногда, просто незаменимая

Можно кейс, когда mc незаменим?

Иногда, просто незаменимая

просто незаменимая

убрана опция «Search for content»

Зря

+1

хе. пару раз об этом думал..., когда стирал случайно.

mc - всему голова!

Можно кейс, когда mc незаменим?

например поиск файлов и по содержимому в файлах
при этом формируется список найденных вхождений

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

Да, неделя файловых менеджеров объявляется открытой!

http://www.tataranovich.com

deb http://www.tataranovich.com/debian jessie main
deb-src http://www.tataranovich.com/debian jessie main

deb http://www.tataranovich.com/debian jessie nightly
deb-src http://www.tataranovich.com/debian jessie nightly

А не прикрутить ли к mc какой-нибудь простой, но универсальный протокол наподобие 9P для общения с процессами-плагинами? А уж плагины пусть тянут хоть самбу, хоть чёрта лысого?

https://github.com/MidnightCommander/mc/blob/master/src/vfs/extfs/helpers/README

Это хорошо, спасибо.
Но есть вопросик. Почему у меня mc этой сборки не знает свою версию (ни по F1, ни по mc --version)?

GNU Midnight Commander, версия unknown
Скомпилирован с библиотекой GLib версии 2.42.1
С библиотекой S-Lang и с базой данных terminfo
Со встроенным редактором
C поддержкой внутренней командной оболочки
С поддержкой фоновых операций
С поддержкой мыши в xterm и консоли Linux
С поддержкой событий X11
С поддержкой интернационализации
С поддержкой многих кодировок
Виртуальная файловая система: cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish
Тип данных: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

вот это комбайн!

например поиск файлов и по содержимому в файлах
при этом формируется список найденных вхождений

Подскажи комбинацию, плиз.

Обновился и тут же словил баг:

зашел через «Shell link...» на удаленный рабочий сервер (я так понимаю, через FISH) и обнаружил странный глюк - куча папок и файлов с именами типа «232323230065464560» и т.д. Если зайти просто из консоли и выполнить команду 'ls', то все нормально. Откатился на предыдущую версию 4.8.15 - тоже все в порядке.

Ставил из репы Татарановича (Debian 7, x86), если чо.

Это ж багфикс релиз, который тестировали несколько месяцев. Регрессий просто не может быть.

Можно кейс, когда mc незаменим?

patchfs

Подскажи комбинацию, плиз.

M-S-? + опциональная панелизация

а если ты имел в виду именно виндовое сетевое окружение
(SMB/CIFS) - задача интересная,

В первом приближении, она решается посредством --enable-vfs-smb при сборке. julixs

но при вкомпиливании по умолчанию слишком много потянет

Проблема не в этом. Проблема в том, что, при отсутствии DNS, mc начинает очень долго стартовать. Что не нравится пользователям, у которых сеть есть не всегда. Потому в дистрибутивы mc собирают без smb, как правило. В общем, проблема где-то тут: http://www.midnight-commander.org/ticket/1

Я уже откатился на 4.8.15, где все норм. Ради тебя не буду повторять и постить сюда скриншот. Багрепорт им отправил уже.

https://github.com/MidnightCommander/mc/blob/master/src/vfs/extfs/helpers/README

Я в курсе, но считаю, что это всё костыли. Их существование оправдывает лишь то, что ни вы, ни я, ни кто-либо другой не имеет ни времени ни желания всё это переделать.Плагин должен жить отдельным персистентным процессом всё время, пока он нужен, а не запускаться, чтобы «файлы скопировать».

говорили что сдох

Просто редко двигался.

M-S-?

Можно подробнее? Что нажимать?

Есть поиск по Alt-? вроде. Это не он?

Плагин должен жить отдельным персистентным процессом всё время, пока он нужен, а не запускаться, чтобы «файлы скопировать»

интересно, как вы определите, что он, плагин, все еще нужен? а в readme описан всего-лишь интерфейс. и никто ведь не мешает запускать отдельный постоянно висящий процесс, и общаться с ним из тех-же шеловских хелперов по любому приемлемому ipc - named pipes, d-bus, whatever

он

интересно, как вы определите, что он, плагин, все еще нужен?

Странная постановка вопроса. mc не может определить, открыты на панелях каталоги нативно или через vfs?

и никто ведь не мешает запускать отдельный постоянно висящий процесс, и общаться с ним из тех-же шеловских хелперов по любому приемлемому ipc - named pipes, d-bus, whatever

Ага, я тоже люблю race conditions.

Лучший.

Кстати, раз уж разработчики в треде, рассмотрите пулл реквест.

Я тут как раз занимаюсь развлечением: натравливаю разные файловые менеджеры на каталог с пятью тысячей файлов и смотрю, где кривые руки разработчиков наплодили косяков, таких как алгоритмы со сложностью O(n^2).

У MC всё в порядке с прямотой рук, но один любопытный hot spot я всё же нашел. Суть такова:

Сортировка по имени 5400 элементов каталога занимает 21% инструкций программы по callgrind-у. Из них собственно сортировка - только 10%, и еще 11% - генерирование ключей для сортировки в str_create_key_for_filename(). Стал смотреть, почему так долго. str_create_key_for_filename() вызывает str_utf8_normalize(), которая шарашит вызовы Glib для нормализации строк. Вот Glib все эти 11% и сжирает.

Заглянул в сорцы Glib, а там нет никакой оптимизации частных случаев: алгоритм нормализации раскладывает строку в UCS-4, нормализует, а потом сшивает в utf-8 обратно. Брутально.

Имена файлов в подавляющем большинстве случаев набраны в ASCII, поэтому их «нормализация» тривиально выполняется при помощи strdup(). Если запускать настоящий алгоритм нормализации только когда это действительно необходимо, можно хорошо сэкономить.

Вот такой патч на моём тестовом наборе уменьшает время работы str_utf8_normalize() с 11.9% до 1.4%, или в абсолютном выражении с 21 миллиона инструкций до 2 миллионов.

diff --git a/lib/strutil/strutilutf8.c b/lib/strutil/strutilutf8.c
index 8ec754d..9ff0f6d 100644
--- a/lib/strutil/strutilutf8.c
+++ b/lib/strutil/strutilutf8.c
@@ -1080,6 +1080,17 @@ str_utf8_normalize (const char *text)
     const char *start;
     const char *end;
 
+    const char *p = text;
+    while (1)
+    {
+        char c = *p;
+        if (c == 0)
+            return g_strdup(text);
+        else if (c < 0 || c > 127)
+            break;
+        p++;
+    }
+
     fixed = g_string_sized_new (4);
 
     start = text;

(Пояснение: избыточная проверка c > 127 добавлена на случай если char окажется беззнаковым на какой-нибудь платформе.)

Просто все файлы. Как и в утилите find

Зачем? Не вендувс же! Есть фузе, есть модули под нее. Мс не должен делать ничего сложнее подсветки и распаковки архивов...

убрана опция «Search for content», поиск с учётом содержимого теперь отключается путём указания пустого значения в поле «Content» .

noooooo... :(

а, впрочем, ладно.. если только в этом поле хистори оставили