mc-4.1.40-MP: Двадцать лет спустя...

https://github.com/MidnightCommander/mc - не то же самое? или авторский форк?

Может, стоит объединить усилия с https://github.com/blue-panels/mcommander ? У него как раз тоже актуализация работы с архивами, свой шелл и всё такое. И всё это на базе актуального mc 4.8.*. Хотя понятно, что твой проект намного старше…

утечки памяти: 42 байта. Все остальные изничтожены при помощи valgrind.

Это однозначно плюс.

И всё это на базе актуального mc 4.8.*

Не вижу смысла. именно благодаря так гордо произносимой цифре 4.8. Для меня это означает одно - bloatware. Будь он хоть золотой или палладиевый, он зависит от glib2. А мне это сразу неинтересно.

У меня цель совсем другая. В идеале - 0x0h внешних зависимостей и максимальная стабильность при максимуме эффективности рабочей среды. Оно должно работать везде, компилироваться кругом, не вызывать головной боли и вопросов при установке. А когда в голой NetBSD например, ты хочешь поставить просто mc, а к ней прилагается «половина гнома», - то нафиг такой mc нужен… ИМХО, конечно, но мне в туда не надо.

https://web.archive.org/web/20050409013745/http://mc.linuxinside.com/cgi-bin/dir.cgi

Из фрибсд порт дропнули, чинил его назад для себя чтобы собрать в 12.х ветке, исправил проблемы компиляции и какие-то баги. Впрочем многое может быть неактуально раз тут много правок.

https://paste.debian.net/plainh/1c6b0039

фряха - следующий этап… завтра qemu запрягу, и приступлю. «Оставил на сладкое»… Хотя, логичнее было бы оставть опенька, он у меня кровушки попил, да… :)

Акутуально ли? - вряд ли. но всё равно интересно будет глянуть (сохранил к себе). Благодарю.

А где релиз скачать?

Здесь пусто…

https://github.com/PaLegba/mc-4.1.40-MP/releases
https://github.com/PaLegba/mc-4.1.40-MP/tags

ОК. :) «релиз» в терминологии гитхаба будет сразу после того, как будет закончена обкатка на freebsd (сегодня-завтра, как я расчитываю), «тэги», соответственно - тоже. Что же касается самого факта размещения последних стабильных и вылизанных исходников, - это и есть тот самый «релиз» из новости. Но, да, в современном сознании - прямое использование привычной терминологии действительно может накладываться на «ассоциативные парадигмы» конкретного ресурса, - спасибо, учту на будущее, «всё будет в лучшем виде».

У него как раз тоже актуализация работы с архивами

я посмотрел.

Есть занимательные идеи, бесспорно. Когда закончу с текущими делами, посмотрю подробнее и подумаю, - «а не каннибализировать ли часть к себе в проект?», естественно - с соблюдением авторских отсылок и лицензий (чем почему-то побрезговали те, кто последние 20 лет каннибализировал идеи из mc-MP).

Честно говоря, единственное, что приходит на ум, после беглого прочтения README.md - это фраза из сериала «Ликвидация»: «кто тебя учил из трояка писку мастырить, копеечкой работать надо…».

Там прямо-таки флеш-рояль из модных технологий: тут тебе и плагины (плагины?!), и LUA scripting [заявлен, как альтернативный, ага], и glib2 [куда же без него], и даже systemd в списке «панельных плагинов» упомянуть не забыл, - какой молодец! :) [I use Void Linux btw]

Архивы, конечно же - libarchive. Какая прелесть.

А вот «mcstruct» - штука действительно интересная, посмотрю повнимательнее.

Code folding - у меня был, в потерянной версии pre10 [товарищи коллеги, ни у кого слепка не осталось «с тех времён»?], видимо нужно лезть на старые cd/dvd архивы, и искать, или просто сделать повторно «с нуля», как уже было.

Viewer - структурированный просмотр для [нужный модный формат подставить] - опять же, штука полезная, когда ты devops[-на-побегушках], и тебе нужно быстренько поглядеть, где там в конфиг [микросервиса] нерадивый джун впихнул ключик от рутовой консоли центрального узла.

Спасибо, я составил представление о пректе.

Это проект, который ориентирован на «современную парадигму» корпоративного использования (в основном). Просто за основу был взят mainline mc (зачем-то).

Чего было с нуля не написать, используя «новый модный TUI», а-ля btop? - было бы совсем «стильно модно молодёжно». А еще сегодня модно писать на rust, да, - было бы вообще мега-популярно, я уверен.

Нет, я конечно понимаю, что «работать нужно здесь и сейчас», - сам такой же, на работе - полный набор всего это корпоративного «бобра», и понимаю, что инструменты проще «прилепить сбоку», поверх того, что у тебя уже есть в руках… прекрасно понимаю…

Понимаю, потому что мой mc-MP и начался с того, что я просто хотел увидеть в mc часы, в правом верхнем углу экрана, как бы наивно и глупо это ни прозвучало сегодня…

За фряху отдельное спасибо.

NetBSD например, ты хочешь поставить просто mc, а к ней прилагается «половина гнома»

Depends On: e2fsprogs glib2 glibc gpm libssh2 sh slang which

Жесть, что они там курят в NetBSD?… (вопрос риторический)

Это меня как-то на Федоре затронет или это что-то непонятное?

$ mc --version
GNU Midnight Commander 4.8.33

Нет, это форк mc, сделанный в 2004 году для убирания из него блоатвари и исправления других проблем.

Depends On: e2fsprogs glib2

А glib2 нынче собирается meson, а он тянет python3 ….

Интересно, когда перестанут повторять этот бред про «пол-Гнома»?

Вот дефолтный mc в дебиане:

$ ldd /usr/bin/mc
...
	libgmodule-2.0.so.0 => /lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xf7b1a000)
	libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf79ce000)
...

Ну если кому-то очень хочется вместо использования GArray, GString, GTree и пр. и их API всё делать врукопашную на чистой libc, то кто ж ему запретит? Попутного ветра в спину.

Я знаю один проект, написанный на gtk, но почему-то без glib, хотя казалось бы. Вот там автор таким самоудовлетворением и занимается.

А glib2 нынче собирается meson, а он тянет python3 ….

Что же ты делаешь со мной… Зачем я нырял в эту кроличью нору :(

Я знаю один проект

Там сишка или кресты? Если второе, то логично.

Спустя 22 года простоя

стоит перейти на github

Что за бред я только что прочитал? Разработка давно на гитхабе, а последний релиз был в январе прошлого года: https://github.com/MidnightCommander/mc/releases/tag/4.8.33

А glib2 нынче собирается meson

Muon не прокатит?

Читай внимательно, новость не про мейнстримный mc, а про форк.

P.S. Добавил в тело новости словов «форк», хотя по названию тоже можно было догадаться.

Кстати, похожие темы удачно подобраны.

Жаль, конечно, что нормальную практику миграции фич и патчей из одного форка в другой ты называешь «каннибализировать». Опенсорс, собственно, этим и живёт.

с соблюдением авторских отсылок и лицензий (чем почему-то побрезговали те, кто последние 20 лет каннибализировал идеи из mc-MP)

А подробнее? Кто и чем побрезговал?

тут тебе и плагины

и даже systemd в списке «панельных плагинов» упомянуть не забыл

Ты сам ответил на свой вопрос, зачем нужны плагины. Вот для этого и нужны, чтобы лишние зависимости не тянуть. Не пользуешься systemd – просто не ставишь соответствующий плагин.

и glib2

Ну это по наследству от мейнстрима досталось.

Просто за основу был взят mainline mc (зачем-то).

Например, затем, что в современных mc починили безумно раздражавшую вещь – командная строка под панелями и командная строка терминала, появлявшегося по Ctrl+O, были никак не связаны друг с другом. Даже виндовый FAR таким не страдал, хотя командная строка в винде тот ещё глюкодром.

Когда в mc это починили, у меня как будто крылья выросли. Можно в терминале писать команду (в т.ч. выбрав её из истории), потом нажать Ctrl+O, накопипастить Alt+Enter-ом имён файлов в параметры, опять нажать Ctrl+O и продолжать редактирование. В твоём форке так можно? Если можно, то интересно, стоит потыкать.

22 года ждали, поздравляю пользователей.

ну, я это сделал :) но как-то не особо пользовался, - ты лучше дождись следующего коммита, я туда доделанную версию запихну, раз такое дело… […я эту штуку реализовал, но я ей уделил как раз крайне мало внимания, - были немного другие приоритеты]

система сборки: полный отказ от autoconf/automake в пользу suckless Makefile/config.mk/config.h

autoconf/automake - позволял просто/удобно настраивать сборку

./configure --help 
./configure --prefix=<...> --ect=<...>
make -jxxx

suckless Makefile/config.mk/config.h

это редактирование файла и/или настройка окружения

export PREFIX=...
export BINDIR=...
...
make -jxxx

перейти на github, а не пилить «страшный код в страшном подвале».

А код вас об этом просил? Лежал он себе 22 года в своем теплом уютном подвальчике, ни кого не трогал, ни кому не мешал. Вдруг вламывается какой-то сумасшедший дед, телепортирует к себе на гитхаб, отрывает automake, запихивает в qemu, подключает к LLM, опутывает MCP и давай пилить-релизить. А некоторые деда еще и подначивают, каннибализировать предлагают. Ну вот зачем эти криминальные хроники на LOR?

Вдруг вламывается какой-то сумасшедший дед

И в голове заиграла «Паника в селе». LLM? Ну так не честно, нужно тег ИИ тогда, чтобы это непотребство не видеть. В тексте нигде это не упомянуто, ждем опровержение от автора.

сколько мусора за собой тянут все эти продвинутые системы сборки? autotools были «первыми» такими комбайном. НО, тогда, когда их повсеместно начали использовать, чтобы разрулить «зоопарк дистрибутивов» в linux - «скриптовым царём популярных систем» был perl, и perl сразу из коробки был в системе, как правило. Комбайн autoconf/automake был «сразу подо всё», и, в конечном итоге - перестал работать «из коробки», потому что perl стал опциональным, а популярность набрал cmake… потом появились всякие meson, ninja, - имя им легион… и каждый комбайн тянет за собой состав зависимостей. А make, универсальный make, - будь это gnu, или bsd, или posix - он есть там, где ты что-то собрался компилировать… и почему-то зависимостей не хочет, и делает ровно одну вещь - он собирает то, что ему сказано. НЕ справился - виноват не он, а криворукий [пользователь], который не знает, что делает и что-то недоконфигурировал. Suckless подход [грубо] - это подход минимализма, экстремальный K.I.S.S. Для сборки, например, тебе нужен компилятор + make/m4 - и всё. И пофигу - bsd это, linux, haiku или solaris. Если нужных кейсов для сборки нет в config.mk - добавь, а не надейся на то, что система автобилда за тебя всё найдёт и добавит. Как правило - об этом должен позаботиться [я] разработчик, который сделает сборку максимально безболезненной на большинстве пользовательских систем… ну и, да, все мы помним - RTFM, прямые руки и ССЗБ, если что-то пошло не по плану.

/// если такие вещи надо объяснять… то, видимо, уже и не надо объяснять…

…я его породил, я его и добью…

Где дропнули? https://www.freshports.org/misc/mc

После этой актуализации большие архивы перестали открываться. Но это вряд ли баг в самом MCommander. Пока не репортил.

можно было и без пафоса объяснить.
ми, таки, слова-то слышим! :о)

… а как проснулась молодёжь в середине выходного дня - «вечер перестал быть томным». :)

Узнаю родной ЛОР, - прямо-таки соскучился по этой радостной, доброжелательной и дружелюбной манере общения. :)

главное не расслабляйтесь! :о)

Спустя 22 года простоя состоялся выпуск форка Midnight Commander – mc-4.1.40-MP.

Автор, ты курить бы бросал:

u@e:~> mc --version
GNU Midnight Commander, версия 4.8.33
Скомпилирован с библиотекой GLib версии 2.88.3
С библиотекой S-Lang 2.3.3 и с базой данных terminfo
Скомпилирован с библиотекой libssh2 версии 1.11.1
Со встроенным редактором
C поддержкой внутренней командной оболочки
С поддержкой фоновых операций
С поддержкой мыши в xterm
С поддержкой интернационализации
С поддержкой многих кодировок
Виртуальная файловая система:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Типы данных:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;
u@e:~> ldd /usr/local/bin/mc
/usr/local/bin/mc:
        libslang.so.2 => /usr/local/lib/libslang.so.2 (0x146c86444000)
        libtinfow.so.9 => /lib/libtinfow.so.9 (0x146c872ba000)
        libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x146c87d36000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x146c88875000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x146c89772000)
        libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x146c8aa98000)
        libutil.so.10 => /lib/libutil.so.10 (0x146c8b7e5000)
        libc.so.7 => /lib/libc.so.7 (0x146c8c101000)
        libncursesw.so.9 => /lib/libncursesw.so.9 (0x146c8c597000)
        libdl.so.1 => /usr/lib/libdl.so.1 (0x146c8d3df000)
        libm.so.5 => /lib/libm.so.5 (0x146c8e0be000)
        libcrypto.so.35 => /lib/libcrypto.so.35 (0x146c8fa00000)
        libz.so.6 => /lib/libz.so.6 (0x146c8e4ad000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x146c8f358000)
        libthr.so.3 => /lib/libthr.so.3 (0x146c9029b000)
        libsys.so.7 => /lib/libsys.so.7 (0x146c9081c000)
        [vdso] (0x146c857be000)
u@e:~> freebsd-version -ku
15.1-RELEASE-p5
15.1-RELEASE-p5

расслабишься тут наxpен… сидишь себе, наступаешь на грабли сборки во freebsd, дописываешь/gправишь config.mk, параллельно пишешь себе внутреннюю инструкцию, чтобы не забыть включить в документацию - какие pkg для сборки накатить надо (и - попутно - от каких зависимостей еще нужно избавиться)… «и тут - оладьи!» %)

это-ли не есть ПРЕКРАСНО?! :о)

Muon не прокатит?

Не знаю, пока не пробовал. С недавнего времени есть виртуалка с openbsd 6.9/sgi, так вот там компилятор есть, а поставятся ли штатные порты - это боооль(ш|н)ой вопрос.

2026

корпоративного использования

mc

это шутка какая-то?

Правильно. В первую очередь OpenBSD остальные бздуны подождут.

В нынешних реальных я бы даже линупс на последок оставил.

система сборки: полный отказ от autoconf/automake в пользу suckless Makefile/config.mk/config.h

Почему не cmake, который тоже ещё более suckless?

Makefile это такой ассемблер от мира сборочных систем. Да, make делает ровно то, что ты ему скажешь, но больно уж многословно. Все эти сборочные надстройки не от хорошей жизни родились. (Кстати, я предпочитаю именно те системы, которые не сами вызывают компилятор, а сделаны как надстройки над make или ninja, поскольку СВОЮ работу make действительно выполняет хорошо.)