Альтернатива win commander
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Альтернатива win commander - 2007-12-25 14:05:59.960000
|
|
|
BugRIPPER
Сообщений: 465
Оценки: 0
Присоединился: 2005-02-18 00:16:04
|
Подскажите нормальный файл менеджер для линуха. Сам использую вин кмд в виндавсе.
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-25 14:21:03.353333
|
|
|
Samotnik
Сообщений: 399
Оценки: 0
Присоединился: 2007-09-30 12:22:09.700000
|
Если очень серьёзно - ls/cd
Если чуть-чуть менее серьёзно - mc
Для гнома - GnomeCommander
Для кед - krusader
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 13:20:01.726666
|
|
|
XerrroX
Сообщений: 221
Оценки: 0
Присоединился: 2007-06-13 14:47:48.220000
|
quote:
ORIGINAL: Samotnik
Если очень серьёзно - ls/cd
Если чуть-чуть менее серьёзно - mc
Для гнома - GnomeCommander
Для кед - krusader
Насколько я понимаю GnomeCommander - жалкая реинкарнация Total'a?
Просто никогда не юзал, только видел на скринах…
Вообще зачем какой-либо файл манагер, если есть ls, cd и ещё куча добра?
Хотя да, файловые манагеры похожие на вендосовские удобнее, для вендузятников и начинающих линухоедов))
Советую посмотреть, что юзают другие линуксоеды и самому выбрать, их не очень много на самом деле
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 15:25:42.690000
|
|
|
BigIron
Сообщений: 898
Оценки: 0
Присоединился: 2007-05-13 18:53:43.593333
|
А зачем собсно альтернатива?
Я вот например иногда и сам им пользуюсь из под вайна, хожу по вайновым дискам, хороший заменитель экплорера :D
А если хочешь понтануться - поставь и научись emacs ;)
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 15:56:11.513333
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: BigIron
А зачем собсно альтернатива?
потому что тотал – убожество. в венде, за неимением лучшего приходиться сглатывать, а в лине-то зачем?
*nix-шелл – это хрестоматийный пример *nix'ового софта: на первый взгляд непонятно как пользоваться, но если дать себе труд разобраться что к чему, если заставить себя забыть на недельку про альтернативы (даже не думать о них, чтобы не смущали мозг), то потом возврат к explorer-like и commander-like файловым менагерам выглядит как шаг назад по пути автоматизации ручного труда. А нахрена нужен компьютер, как не для автоматизации тупых действий?
При этом я ведь не пытаюсь убедить, что надо уметь писать на bash скрипты, которые используя telnet почту по smtp отправляют. Хоть я и писал такой скрипт (чем-то меня не устроили тогда существующие программки), но я не настаиваю. Но такие вещи как поиск файлов, пакетная обработка файлов (вон недавно была целая статья о том как это сделать в фотошопе – в bash такая статья будет глупостью, вместо неё можно написать RTFM, в переводе на русский: сходи и почитай мануал к imagemagik. А пакетность к imagemagik приделывается в полпинка. Тупая задача прописать теги в mp3/ogg/flac файлы. Скажем тупо разбить имя файла на две части: исполнитель и название трека, и внести в теги файла. explorer-like сосут причмокивая. commander'ы начинают искать плугины. в bash-же это делается максимум за десять минут сочинения команды. Хотя нет, если музыки гигов несколько сот, то время может увеличиться за счёт времени выполнения этой команды. Но это уже мелочи: никто не заставляет тратить своё время наблюдая за ходом выполнения.
Я тут интереса ради прикинул сколько времени уходит на смену текущей директории в commander-like, и сравнил с bash. Если теоретически, то количество нажатий на клавиши для commander-like зависит от среднего числа поддиректорий тех директорий через которые мы проходим линейно. В bash – логарифмически. На практике это означает, что если среднее число поддиректорий больше десяти, то commander сосёт. Причём это не учитывая того, что при достаточно большом количестве поддиректорий, найти нужную может быть сложно. bash при этом, своими шаблонами и автодополнением позволяет сильно упростить поиск, если в голове есть хотя бы кусочек названия нужной поддиректории.
при этом, не-sh-based менагеры бесят своим копированием: они почему-то считают, что опции копирования надо узнавать у пользователя по мере возникновения проблем, задавая ему вопросы типа, что делать в случае если копируемый файлик затирает существующий, что делать если копируемый файлик не читается. И при этом, варианты ответов которые они предлагают откровенно убоги: делать бекапы перезаписываемых файлов они не умеют, тем более не умеют выяснять необходимость бекапа по дате последней модификации файла. Как их при этом убедить оставаться на выбранной fs – непонятно: а если я копирую / целиком, но естественно не хочу копировать всякие там /dev, /sys, /proc и тп – нафига они нужны в другом месте?
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 16:23:31.006666
|
|
|
BigIron
Сообщений: 898
Оценки: 0
Присоединился: 2007-05-13 18:53:43.593333
|
Соглашусь отчасти, и как пример можно взять тот универсальный язык, что люди пользуют. Как правило это минимальный набор терминов (в среднем в типовом обиходе для каждой НАИБОЛЕЕ сложной области, люди используют не более 10 тыс. целых терминов распределенных в среднем в 100 библиотек 200 куч и 4-50 терминов на элемент…..)
Теперь же по факту, да возможно в штатной реализации этих приложений это и так, зато вот я в своей навигации по семантическйо системе использую отнюдь не шеллоподобную оболочку, иначе запаришься искать нужную категорию(надо все сразу видеть - тогда работа идет быстрее). Ессно, как уже говорил - на нижнем уровне там 4-50 терминов на элемент, то-есть как-раз то - что умещается в одно из окошек на экране. И ессно есть большая разница между панелизованным и забинденным интерфейсом, ессно еще учитывая кол-во биндов и их возможности. Имхо тут ситуация скорее такая - типовые коммандеры обладают массой недостатков, но хочу заметить что сам интерфейс все-же имеет "целевое окно", точно так-же как и шелл имеет свое. Минус коммандер-интерфейса: сложно передавать большое число мер так, чтобэ это было понятно, посему лично я задумываюсь все-же делать коммандер для граф-ориентированного интерфейса, когда можно трехмерную структуру разворачивать , вертеть, переходить(представляешь себе такое с шелл интерфейса? А чтобы быстро найти что надо? а теперь если тебе нужно обьединить 50 веток из 20 разных деревьев?).
Одно жаль - у зрения всего три меры….. впрочем мер всегда мало, посему приходится пользоваться устоявшейся системой ограничений, а кто-то вот даже через типовуху "перешагнуть" не может, хотя посчитав(взвесив) усилие необходимое для этого действия/результат, думаю все-же большинство пришло-бы к соответствующим выводам, но к сожалению никто не отменил "массовую культуру"(не забывая про ее свойства распространения в "одушевленном пространстве").
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 16:56:52.893333
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: BigIron
лично я задумываюсь все-же делать коммандер для граф-ориентированного интерфейса, когда можно трехмерную структуру разворачивать , вертеть, переходить(представляешь себе такое с шелл интерфейса?
да. представляю. надо просто внести в sh поддержку Списков. Синтаксис правда, может оказаться перегруженным, но можно синтаксис и с нуля придумать.
Командный интерпретатор – это руль офигенный. *nix-шелл лишь один из таких интерпретаторов.
Видеть граф в трёхмерном пространстве – это хорошо, не требуется никаких навыков, чтобы в голове представить, но неудобно с точки зрения автоматизации работ. Очень неудобно. Вся информация, по возможности должна быть в текстовом виде, тогда её можно обрабатывать стандартными утилитами, преобразовывать по желанию.
Граф? Конвертаем в lisp'овую запись списков, грузим в лисп, обрабатываем, и выкидываем обратно, в текстовом же виде, чтобы продолжить обработку: загнать, например, в wget или в stdin telnet'а, в тот же imagemagik, или тупо записать в файл. Скопировать и показать на форуме.
Собственно да. Это наверное самый удачный подход: вместо того, чтобы делать из bash непонятно что, нужно воспользоваться стандартным *nix'овым принципом "каждая программа должна делать только одно дело". Не обязательно лисп брать для обработки Списков, но, просто лисп для этого специально создавался. А для графов пока ничего не разработали адекватного, с чем было бы удобнее работать чем с лиспом.
А вот после этого, если в голове вообще никак не укладывается без графического представления, можно написать тупое opengl приложение, которое будет читать из stdin текстовое представление графа, и рисовать его в отдельном окошке. Получиться три сравнительно простых утилитки: bash, графопроцессор и графовизуализатор, каждую из которых по отдельности (или все вместе если надо) очень даже неплохо можно будет подстроить к задаче. Причём графовизуализатор нисколько не мешает работать bash и графопроцессору. При желании bash можно выкинуть из списка – это будет иметь смысл если графопроцессор будет уметь конвеерно обрабатывать графы, объявлять всяческие циклы/функции, делать job-control и тд.
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-27 18:50:26.330000
|
|
|
blonx
Сообщений: 1150
Оценки: 0
Присоединился: 2006-04-01 03:28:42
|
Лично мне по душе worker, одно время тоже чего только не перепробовал, -остановился на нем. Попробуй, может приглянется.
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-28 11:47:01.366666
|
|
|
BigIron
Сообщений: 898
Оценки: 0
Присоединился: 2007-05-13 18:53:43.593333
|
Сразу отмечу,что тема по контексту уже сильно отклонена от оригинала….
quote:
ORIGINAL: rgo
да. представляю. надо просто внести в sh поддержку Списков. Синтаксис правда, может оказаться перегруженным, но можно синтаксис и с нуля придумать.
Командный интерпретатор – это руль офигенный. *nix-шелл лишь один из таких интерпретаторов.
Я долго вертелся, пытался, но пока-что особо удобного ничего так и не случилось….
Поэтому на данный момент пользую commander-like интерфейс, поскольку видно сразу и точку(и сопровождающие ее корреляторы) и связи.
С графами точно будет удобнее. Заодно убедился что новая по свойствам фс - это еще не все, обвязки додури……
Кстати мне, с точки зрения выведения множества графов удобнее тем, что я вижу дерево(а оно ведь меняется с достаточной регулярностью почти до неузнаваемости - это "взвесь") моя лишь задача линковать/отлинковывать и если необходимо что-то коренным образом клонировать и накладывать ограничения. В данном случае мышеелозительный интерфейс думаю один, что позволяет делать это быстро(просто тащим точки в сектор или рвем связи/уничтожаем точки, или выделяем сектор…).
quote:
ORIGINAL: rgo
Граф? Конвертаем в lisp'овую запись списков, грузим в лисп, обрабатываем, и выкидываем обратно, в текстовом же виде, чтобы продолжить обработку: загнать, например, в wget или в stdin telnet'а, в тот же imagemagik, или тупо записать в файл. Скопировать и показать на форуме.
Еще одна маленькая проблема, графы то надо обрезать, ибо вся система представляет из себя один связанный кластер, поэтому вывести все на экран просто не представляется возможным!
Одно хорошо, можно хоть все дерево прочитать одной ф-цией, наложив систему ограничений для уменшьения кол-ва данных.
Из вероятных реализаций - выводить только "локальный контекст", хотя если честно и контексты иногда бывают весьма обьемными.
quote:
ORIGINAL: rgo
Собственно да. Это наверное самый удачный подход: вместо того, чтобы делать из bash непонятно что, нужно воспользоваться стандартным *nix'овым принципом "каждая программа должна делать только одно дело". Не обязательно лисп брать для обработки Списков, но, просто лисп для этого специально создавался. А для графов пока ничего не разработали адекватного, с чем было бы удобнее работать чем с лиспом.
Если честно, я на лиспе не писал, у меня совершенно иные заботы, а оптимизацией могут неплохо и уже готовые НС заниматься(надеюсь в недалеком будущем имея большие вычислительные мощности займусь, заодно модуль еще один допишу).
Насчет "программа должна делать одно дело" - тут даже сложно сравнить, среда другая(хотя смотря о какой речь правда), ибо в среде кластеров - "принцип" уже не программа, а скорее один из методов(активных корреляторов), накладывающихся по ходу обработки….
В любом случае - моя забота сейчас, сделать интерфейс для временной коррекции(в дальнейшем уже такого тотального контроля не надо будет, поскольку будут обученные системы стабилизации весов, а пока и сам не всегда до конца понимаю, как некоторые области оставить в зоне обратной связи…).
quote:
ORIGINAL: rgo
А вот после этого, если в голове вообще никак не укладывается без графического представления, можно написать тупое opengl приложение, которое будет читать из stdin текстовое представление графа, и рисовать его в отдельном окошке.
Вот это пока проблема, никогда не писал на базе opengl, надо читать….
(вроде ничего косо не ляпнул, башка туго соображает, я ща "грипповирус отлавливаю" :( )
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-28 21:03:21.160000
|
|
|
bsw
Сообщений: 33
Оценки: 0
Присоединился: 2007-12-20 17:59:22.450000
|
разговор ушел немного от темы
а вот для лазанья по файлухе и работы с файлами никаких Commander-like прог не надо - все делается быстрее и удобней в BASH'e (ИМХО)
|
|
|
|
|
RE: Альтернатива win commander - 2007-12-28 22:18:28.533333
|
|
|
Samotnik
Сообщений: 399
Оценки: 0
Присоединился: 2007-09-30 12:22:09.700000
|
Смотрю, тут флейм недетский пошёл…
Сам я пользую ls/cd, и иногда - mc (бывают случаи, когда это довольно удобно)
Тем не менее, знаю много юзеров, для которых ls/cd непод'ёмен (как минимум, вначале), и графический commander-подобный интерфейс - единственное, что может их спасти.
Чего там. Я и сам начинал с krusader'а (это был ещё mandrake 9). Давно это было…
|
|
|
|
|
|
