Re^27: Возрождение Midnight Commander

> По отсуствию демона я могу только повторить: монтированием (и запросом логинов/паролей) занимается сам ФМ; если при выходе остались занятые FUSE-ФС, ФМ запрашивает пользователя, оставить их смонтированными после выхода или отменить выход (было бы удобно предъявлять список программ, использующих эти ФС). Если FUSE поддерживает umount -l, можно при выходе вызывать его.

ясно

> А вообще, FUSE - это круто и всё такое, но я сильно подозреваю, что написать модуль VFS для поддержки какого-нибудь формата в текущем MC проще, чем написать модуль для FUSE.

Да, ты прав. Но модули vfs, которые не могут за сутки распаковать архив исходников ядра(уж очень показательный пример архива с тучей файлов) не нужны даже если их просто написать.

>mount без параметров

Ты получишь ВСЕ маунты ВСЕХ пользователей в системе + системные маунты. Если так - сорри, но мне дальше неинтересно:)

Re^27: Возрождение Midnight Commander

>>mount без параметров
> Ты получишь ВСЕ маунты ВСЕХ пользователей в системе + системные маунты. Если так - сорри, но мне дальше неинтересно:)

Городить велосипед для per-user маунтов тоже как-то неинтересно. Да и отфильтровать этот список по точке монтирования можно, чтобы только своё видеть.

>Городить велосипед для per-user маунтов тоже как-то неинтересно. Да и отфильтровать этот список по точке монтирования можно, чтобы только своё видеть.

Для многопользовательской системы - это НЕ велосипед. Если это per-user монтирование, то пользователь должен иметь возможность посмотреть: что он, как пользователь, примонтировал (независимо от того, есть у него права на просмотр /proc/mount или нет - а такое тоже не исключено). И должен иметь возможность закрыть эту информацию от других пользователей системы. Администратору тоже не интересно фильтровать /proc/mounts от пользовательских маунтов - например, в системе, у которой десяток, сотня пользователей: сервер + тонкие клиенты.

спасибо, question4 за ebuild

avfs есть в дебиане. Я ее прикрутил (пока от рута, от юзера почему-то не пошла, даже после внесения юзера в группу fuse, и еще потребовался fuse-tools).

В 200-метровый архив из 15000 файлов по 10-20 килобайт входит меньше чем за секунду. Меня устраивает.

Следующим постом -- моя кастомарная сд. Могут быть баги.

Скорее, тут куча багов :-)

cd() {
    if [ "$1" = "" ]
    then builtin cd
    else
        if `builtin cd $1 2&>/dev/null`
        then builtin cd $1;
        else
            if [ `dirname $1` != `dirname /$1`  ]
            then builtin cd ~/.avfs/$PWD/$1# 
            else builtin cd ~/.avfs/$1# 
            fi
        fi
    fi
}

В частности, не заходит в файлы с пробелами в именах.

> Администратору тоже не интересно фильтровать /proc/mounts от пользовательских маунтов - например, в системе, у которой десяток, сотня пользователей: сервер + тонкие клиенты.

У меня показывает (даже если зайти в два архива одновременно)

fusectl on /sys/fs/fuse/connections type fusectl (rw)

avfsd on /root/.avfs type fuse.avfsd (rw,nosuid,nodev)

В кастомарной cd лишний &.

В общем, результат меня устраивает -- я МС юзал в основном для прохода по архивам.

Остались команды копирования с прогрессом и качественный виджет для ходьбы по ФС (некачественный делается из консольного dialog-а)

>Я ее прикрутил (пока от рута, от юзера почему-то не пошла, даже после внесения юзера в группу fuse, и еще потребовался fuse-tools).

А что, в Debian нет

control fusermount

? Или Debian уже тоже наводнили Убунтовские ламеры?:)

>Остались команды копирования с прогрессом

dd подойдёт?:)

> dd подойдёт?:)

Оно, понимаешь ли, должно ETA подсчитывать, как в МС.

Re^29: Возрождение Midnight Commander

> У меня показывает (даже если зайти в два архива одновременно)

это за счёт принципа работы avfs, у которой все фс живут в одном процессе. Эта практика порочна, потому не следует этим гордиться :)

Re^29: Возрождение Midnight Commander

>> dd подойдёт?:)
> Оно, понимаешь ли, должно ETA подсчитывать, как в МС.

Как в мц -- это неповторимо :) мц не совсем eta подсчитывает

Re^29: Возрождение Midnight Commander

> avfs есть в дебиане.

Хы,оказывается, она есть. А я её почему-то сам собирал :)

> Я ее прикрутил (пока от рута, от юзера почему-то не пошла, даже после внесения юзера в группу fuse, и еще потребовался fuse-tools).

А должна бы.

> В 200-метровый архив из 15000 файлов по 10-20 килобайт входит меньше чем за секунду. Меня устраивает.

avfs использует те же vfs-плагины, что и мц, так что жди тормозов на распаковке.

>В частности, не заходит в файлы с пробелами в именах.

классическая проблема :) попробуй рассматривать $1 как "$1"

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

fixed

> avfs использует те же vfs-плагины, что и мц, так что жди тормозов на распаковке.

Мне главное чтобы медленнее не было, однако это уже более Ъ, чем vfs.

>> Оно, понимаешь ли, должно ETA подсчитывать, как в МС. > Как в мц -- это неповторимо :) мц не совсем eta подсчитывает

Ладно, я готов таки отказаться от неповторимого подсчета в мц.

Кстати, люди уже озаботились прогрессбаром в ср: http://bugs.archlinux.org/task/11603

для Ъ: есть патч для cp & mv, чтобы по SIGUSR1 выплевывать прогресс.

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

cygwin?

Re^2: Возрождение Midnight Commander

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

Он уже портирован давненько

Неужели под Linux нет для консоли ничего адекватнее, чем [n]curses/s-lang?

Re^2: Возрождение Midnight Commander

> Неужели под Linux нет для консоли ничего адекватнее, чем [n]curses/s-lang?

А откуда взяться чему-либо более адекватному чем ncurses, которая практически 1 в 1 посылает терминальные последовательности?

> Если нужно по терминалу пользовать MC - включил ESC последовательности. А локально они только мешают.

Очень удобная штука, между прочим. Даже локально.

> Сейчас 2008 год, писать под терминал вообще нецелесообразно.

Будем ставить иксы на сервер? А оно кому-то надо?

Мужики, вот вы тут открытым текстом обсуждаете написание файл-менеджера, а Стиви сидит и читает... Как дочитает, побежит патентовать потыреные идеи...

> Он уже портирован давненько

Мда, пора завязывать с путешествиями в недалёкое прошлое... А то так недолго и завязнуть там нафиг.

> cygwin?

А FAR при помощи вайна портировать предлагается? ;)

Для запуска файлов внутри DE можно попробовать добавить в mc.menu:

+ ! t t
k       Run current file with DE
        (xdg-open %f &) > /dev/null 2>&1

+ t t
k       Run tagged files with DE
        set %t;
        while [ -n "$1" ]; do
          (xdg-open "$1" &) > /dev/null 2>&1
          shift
        done

Теперь по F2 k текущий/выделенный файл должен открываться средствами DE.

>А откуда взяться чему-либо более адекватному чем ncurses, которая практически 1 в 1 посылает терминальные последовательности?

И потому тормозит даже на локалхосте...

Хочется чего-то более умного, которое напрямую будет работать с консолью, фреймбуфером, иксами... А с терминалом - только при удалённой работе :)

>Теперь по F2 k текущий/выделенный файл должен открываться средствами DE.

Если бы он по правому клику мог вызывать контекстное меню файла для текущего DE, как это умеет FAR - вот тогда был бы реальный профит :)

а FAR умеет вызывать контекстное меню файла для текущего DE?? Или только от Explorer'a ? ;)

>а FAR умеет вызывать контекстное меню файла для текущего DE?? Или только от Explorer'a ? ;)

А там Эксплорер - текущий by default :) Но, вообще, этот функционал реализован плагином. Так что при смене DE, при желании, можно написать альтернативное решение.

Т.е. там весь цимес в том, что по правому клику можно плагин вызвать для файла. А в Linux в терминалке этого в принципе не сделаешь :-/ Правый клик самой терминалкой отрабатывается.

Re^10: Возрождение Midnight Commander

>> Сейчас 2008 год, писать под терминал вообще нецелесообразно.
> Будем ставить иксы на сервер? А оно кому-то надо?

Про sftp мы дружно забываем, да?

Re^4: Возрождение Midnight Commander

> Хочется чего-то более умного, которое напрямую будет работать с консолью, фреймбуфером, иксами... А с терминалом - только при удалённой работе :)

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

Re^2: Возрождение Midnight Commander

> Для запуска файлов внутри DE можно попробовать добавить в mc.menu:

А чем тебе run-mailcap, используемый по умолчанию, не угодил?

>>run-mailcap

он использует не все ситуации, а только некоторые. Я хочу например открыть каталог "1" или файл "1.txt" на текущей панели в конке/kwrite. run-mailcap для них не прописан, да и как ты пропишешь правило для каталога? Во-вторых, mailcap использует жёстко забитые программы, а xdg-open - DE-зависимые.

>> run-mailcap
> он использует не все ситуации, а только некоторые. Я хочу например открыть каталог "1" или файл "1.txt" на текущей панели в конке/kwrite. run-mailcap для них не прописан, да и как ты пропишешь правило для каталога?

> Во-вторых, mailcap использует жёстко забитые программы,

Файлы ~/.mailcap и ~/.mime.types уже отменил пленум fd.o?

> а xdg-open - DE-зависимые.

Сомнительное удовольствие. Кроме того -- это велосипед при живом run-mailcap.

>>Файлы ~/.mailcap и ~/.mime.types уже отменил пленум fd.o?

Пользователю над будет настраивать программы дважды? Один раз в DE, другой раз ручками в ~/.mailcap? А в ~/.mailcap прописывать тот же xdg-open? Не слишком ли много гемора и ограничения функционала? В консоли xdg-open как бы не будет работать.

>>Сомнительное удовольствие. Кроме того -- это велосипед при живом run-mailcap

Это способ запускать программы внутри DE. Если ты ждёшь чего-то другого, то это не то.

>> Файлы ~/.mailcap и ~/.mime.types уже отменил пленум fd.o?
> Пользователю над будет настраивать программы дважды? Один раз в DE, другой раз ручками в ~/.mailcap? А в ~/.mailcap прописывать тот же xdg-open?

mailcap настраивается автоматически и в 99% случаев так как надо.

> Не слишком ли много гемора и ограничения функционала? В консоли xdg-open как бы не будет работать.

Это проблема DE, что они плодят велосипеды. И весь геморрой растёт оттуда.

>> Сомнительное удовольствие. Кроме того -- это велосипед при живом run-mailcap
> Это способ запускать программы внутри DE. Если ты ждёшь чего-то другого, то это не то.

Я жду DE-независимого способа. Не работающего для всех DE, а именно независимого от понятия DE вообще.

>>Это проблема DE, что они плодят велосипеды. И весь геморрой растёт оттуда.

это проблемы fd.o, man xdg ;)

>>Я жду DE-независимого способа. Не работающего для всех DE, а именно независимого от понятия DE вообще.

такого не существует пока.

>Нет уж, концепцию ломать низя.

Для концептуальных, готовых мириться с невысокой скоростью работы, никто не отменит и старый добрый mc :)

>> Нет уж, концепцию ломать низя.
> Для концептуальных, готовых мириться с невысокой скоростью работы, никто не отменит и старый добрый mc :)

Старый добрый останется, а новым добрым откуда взяться? Пример: есть ли хоть одна утилита для работы с bluetooth, не загаженая DE-растами?

>> Это проблема DE, что они плодят велосипеды. И весь геморрой растёт оттуда.
> это проблемы fd.o, man xdg ;)
fd.o == {гномерасты, кедерасты, рохерасты} :)

>Старый добрый останется, а новым добрым откуда взяться?

А им итак браться уже не откуда. В контексте файлменеджеров, конечно. Да и просто нового софта под ncurses всё меньше и меньше...

>Пример: есть ли хоть одна утилита для работы с bluetooth, не загаженая DE-растами?

hcitool :)

> Да и просто нового софта под ncurses всё меньше и меньше...

И это пралльно.

>> Пример: есть ли хоть одна утилита для работы с bluetooth, не загаженая DE-растами?
> hcitool :)

Неюзабельна.

Реально нужный кусок кода из МС -- это его копирование и перенос с прогрессом (а еще ЕМНИП если mv не получился, то он все переносит обратно).

Если эту функциональность реализовать отдельной прогой (которая прогресс показывает на stderr), вызывать ее из МС и там показывать прогресс (так же, как и сейчас) -- тогда был бы юникс-вей.

( А если нет -- то буду копать в сторону mv/ср с прогрессом, может продолжу патч -- он вроде статистику не всю считает ).

Впрочем, возможно что модульный вариант МС я бы делал совсем иначе. И не только mv & cp, но даже и ls -- не юникс-вей, ибо распарсить однозначно их вывод может можно, но остаются сомнения (особенно если они еще и локализованы...)