Возрождение Midnight Commander

Уважаемые спорщики. Я так понимаю писать никто ничего и не собирался? Оно и понятно спорить и проектировать куда как интереснее... ;)

Алсо, в качестве графического mc вполне себе неплох tuxcmd. Не использую постоянно только из-за торомозов интерфейса. Даже thunar какой-нить субъективно шустрее работает, не говоря уж об mc. Зато tuxcmd двухпанельный и табы умеет.

> Уважаемые спорщики. Я так понимаю писать никто ничего и не собирался? Оно и понятно спорить и проектировать куда как интереснее... ;)

А тебе прям по результатам флейма надо было работающий ФМ получить? Извини, дела так быстро не делаются. Полезные мысли я из обсуждения извлёк и многое для себя прояснил.

> Уважаемые спорщики. Я так понимаю писать никто ничего и не собирался? Оно и понятно спорить и проектировать куда как интереснее... ;)

Сначала надо понять *что* писать. Этим мы тут и занимаемся.

Как пример: сначала я полагал, что надо написать обвязку вокруг подпатченных ls, mv, cp, но теперь засомневался, т.к. выходной формат этих утилит достаточно свободный, т.е. парсить его можно лишь ненадежно. Скажем, если (ls) в имени пользоваетля будет пробел? Или (ls) в имени файла -- ньюлайн? А как графическая оболочка будет парсить сообщение об ошибке ср, если оно локализовано на китайском?

Поэтому даже кажется, что данные утилиты требуют переписывания.

> Сначала надо понять *что* писать. Этим мы тут и занимаемся.

может стоило бы для начала понять *зачем* ? туева хуча существует уже коммандеров разного рода. ну нарисуете вы еще один, и что ?

если в mc не устраивает функционал его extfs (кстати, в /usr/share/mc/extfs/ заглядывали? а то у меня ваша высоконаучная дискуссия вызывает дежавю), то может нужнее было бы его усовершенствовать? или это не гламурно?

вобчем - успехов вам ;)

относительно vim

> это кем надо быть, чтобы выход на :wq или на :q! повесить.

"профессионал отличается от любителя знанием истории вопроса" (с) доцент Добровлянский, КПИ, 1985.

что бы далеко не ходить - man ed, первоисточник - товарищи B.W.Kernighan и P.J.Plauger, в своей канонической книге Software Tools in Pascal, 1981. Лень искать, но по моему у них потом вышла еще и Software Tools in C или как то так. спорить о значении результатов трудов указанных товарищей надеюсь не будем ? ;)

а vi/vim - чисто исторически - визуальная оболочка к ed. при этом ed и vi имеются в любом юниксе. поэтому умение пользоваться как минимум vi - это таки квалификационное требование к любому нормальному админу.

еще к вопросу "зачем ?", ознакомьтесь на досуге с подборкой http://www.softpanorama.org/OFM/index.shtml

>> Сначала надо понять *что* писать. Этим мы тут и занимаемся.

> может стоило бы для начала понять *зачем* ? туева хуча существует уже коммандеров разного рода. ну нарисуете вы еще один, и что ?

И в этой хуче ни одного (удобного && функционального). Мотивация понятна?

> если в mc не устраивает функционал его extfs

Не только

> (кстати, в /usr/share/mc/extfs/ заглядывали?

Заглядывал. И даже ковырял. И даже считал производительность. Потом икал: каталог net из сорсов ядра распаковывается из zip-архива 40 минут! Нормальная vfs управляется с этой задачей за 3 секунды. (пруфлинк: http://code.google.com/p/fuse-zip/wiki/PerformancePage)

> а то у меня ваша высоконаучная дискуссия вызывает дежавю), то может нужнее было бы его усовершенствовать? или это не гламурно?

мц надо пристрелить, чтоб не мучался.
"broken by desing патчами не исправишь"(ц)

> ознакомьтесь на досуге с подборкой http://www.softpanorama.org/OFM/index.shtml

забукмарчил

> Быстрее mc под венду портируют, чем FAR под линукс.

Что-то мне это напомнило... А!

"Болт, забитый молотком, держится прочнее, чем гвоздь, закрученный отвёрткой"!

А так - сборка mc для win32 давно уже есть. Используется, в частности, в ReactOS. Правда, версия древняя, 4.1.36.