dreik 04.03.2009 00:42
0byte — Альтернативы MC?
Хоть в целях и задачах и сказано, что цель проекта - рассказать, но ведь все темы не опишешь и всегда найдёт дурак(в данном случае я), которого интересует нечто странное ;=)Хочется некой альтернативы "стандартному" mc (midnight commander). Список требований достаточно прост с одной стороны, но странен с другой:
portable - являться некоторым набором файлов, которые можно просто скопировать на соседнюю машину и получить теже самые настройки
GUI - лично мне достаточно console(mc) варианта, но если будет доп опцией, кому-то ведь может и понадобиться.
возможность просто редактирования комманд (F2 menu)Поясню зачем лично мне это надо. Я далеко не *nix специалист, но в то же время приходится очень много работать с достаточно специфичным linux дистрибутивом имя которому VMware ESX server, куда поставить внешние пакеты отдельная тема на почесать репу. Особенно когда речь идёт о production серверах.
Некоторые стандартные процедуры я уже заскриптовал.
Но, во первых, вспоминая о том, что я всё же изначально виндузятник(читай хочется чего-нить более привычного), а так же беря во внимание и то, что есть коллеги у которых знания *nix систем в разы хуже моего, а им тоже необходимо что-то делать, то соот-но передо мной стоит задача сделать так, чтобы им было просто и удобно. Обучать же их пользоваться коммандной строкой или же писать в wiki инструкцию на каждый случай жизни(в т.ч. инструкцию о том как отредактировать файлы с помощью vi) - не есть правильный путь, imho.
Посему всё таки сабж.
Заранее благодарю.
Username 04.03.2009 00:49 #
+ 2 -
хм. Ну в плане настроек - я думаю, копирование из домашнего каталога папки .<INSERT_NAME_HERE> на другую машину сохранит все настройки, причем почти для любой проги.
К сожалению, portable вынесено пунктом 1 не просто так. Это, увы и ах, mandatory требование, т.к. того же самого mc на ESX серверах нет. А доставлять его, гм, не то чтобы хотелось..
В любом случае СПАСИБО!
В любом случае СПАСИБО!
ну скомпили в любую папку с относительными путями вот те и портабле. а запускай как $HOME=`pwd` или $HOME=куда_надо и будет тебе благо. правда компилять придется по любому под твою систему, ибо с переносимостью бинарей между разными дистрами линуксами проблемы (из-за разных версий либ и т.п.)
вроде это решается так:
make --prefix=/way/what/we/needed
make install
а еще есть chroot =>
make --prefix=/way/what/we/needed
make install
а еще есть chroot =>
можно и так, я просто то что первое в голову пришло то и написал...
а вообще для портабельности можно ещё и статическую линковку при сборке заюзать...
а вообще для портабельности можно ещё и статическую линковку при сборке заюзать...
На мой личный взгляд раз "приходится очень много работать с достаточно специфичным linux дистрибутивом", то пусть как раз и учатся работать в коммандной строке. imho если с чем-то много работаешь - научись как правильно и эффективно это делать.
К сожалению не знаю портабл версий программ под linux, очевидный, на мой взгляд, выход - взять сурсы любого (читай "который понравиться") файлового менеджера и поправить так, чтобы настройки сохранялись в активную директорию (та же, где и программа) - это сделать не очень сложно.
К сожалению не знаю портабл версий программ под linux, очевидный, на мой взгляд, выход - взять сурсы любого (читай "который понравиться") файлового менеджера и поправить так, чтобы настройки сохранялись в активную директорию (та же, где и программа) - это сделать не очень сложно.
На мой личный взгляд раз "приходится очень много работать с достаточно специфичным linux дистрибутивом", то пусть как раз и учатся работать в коммандной строке. imho если с чем-то много работаешь - научись как правильно и эффективно это делать.
Боюсь что это тема для отдельной дискуссии более похожей на холивар. Но поверьте, зачастую не эффективно учить людей делать не свою работу, когда в большинстве случаев они помогают в случае моей перегрузки по другим задачам. Или же вообще в случае отсутствие у меня какого бы то ни было доступа к серверам и соот-но я им фактически по буквам диктую каждую комманду, если задача хоть чуть-чуть отличается от того что описано в wiki.
выход - взять сурсы любого (читай "который понравиться") файлового менеджера и поправить так, чтобы настройки сохранялись в активную директорию (та же, где и программа) - это сделать не очень сложно.
согласен, выход, но не для меня в силу отсутствия необходимых знаний :)
Кстати как то туманно пост называется. Автор ищет портабельный mc а назвал Альтернативы MC.
Недавно упоминавшийся на welinux DoubleCommander вроде бы подходит под все указанные требования.
Использование консоли и редактирование файлов в vi - это, имхо, самый правильный путь для nix админа (вы ведь с коллегами - админ?). Ибо эти инструменты есть практически в каждом nix дистрибутиве, а такого привычного двухпанельного файлового менеджера может не оказаться. И если вы не сможете настроить новый сервер, поскольку не приучены пользоваться стандартными для Юникса инструментами, то все это может кончится весьма плачевно.
1. По телефону команды неудобно говорить, IM im и еще раз IM или емайл наконец. Требуйте чтобы в точности комманды были набраны. Моя матушка грохнула /var/ во первых потому что я придурок, во вторых потому что вместо
sudo rm -rf /var/log/* она написала с sms sudo rm -rf /var log/* (нужно было получить какое-то место ато она даже сеть не могла запустить)
2. Удаленно лучше передавать комманды. ну чем в самом деле поможет GUI или mc когда нужно сделать dd if=/dev/sda of=/root/botsect bs=512 count=1 ? Если "синенькие" нужны для успокоения глаз, то вашему коллеге нужно побеседовать с психологом, я серьезно, без издевки.
3. mc на сервере не нужен. вообще внедрение вспомогательного объекта управления может быть полезно только если этот объект экономит 10-20% рабочего времени. В случае mc - если это происходит, то нужно автоматихировать процесс, я с трудом представляю себе зачем вообще администратору вверх-вниз по каталогам лазить и задумчиво нажимать f5, insert
4. menu - откройте для себя bash (!=bash.org.ru) он позволяет делать простые интерактивные вложенные меню.
из всего вышеперечисленного я могу сделать только один вывод, посылки к обоснованию существования софта неполны, истиные причины умалчиваются по некоторым причинам, возможно психологическим или имеющим отношние к бизнесс-процессам.
короче.
Зачем тебе MC на сервере ?
sudo rm -rf /var/log/* она написала с sms sudo rm -rf /var log/* (нужно было получить какое-то место ато она даже сеть не могла запустить)
2. Удаленно лучше передавать комманды. ну чем в самом деле поможет GUI или mc когда нужно сделать dd if=/dev/sda of=/root/botsect bs=512 count=1 ? Если "синенькие" нужны для успокоения глаз, то вашему коллеге нужно побеседовать с психологом, я серьезно, без издевки.
3. mc на сервере не нужен. вообще внедрение вспомогательного объекта управления может быть полезно только если этот объект экономит 10-20% рабочего времени. В случае mc - если это происходит, то нужно автоматихировать процесс, я с трудом представляю себе зачем вообще администратору вверх-вниз по каталогам лазить и задумчиво нажимать f5, insert
4. menu - откройте для себя bash (!=bash.org.ru) он позволяет делать простые интерактивные вложенные меню.
из всего вышеперечисленного я могу сделать только один вывод, посылки к обоснованию существования софта неполны, истиные причины умалчиваются по некоторым причинам, возможно психологическим или имеющим отношние к бизнесс-процессам.
короче.
Зачем тебе MC на сервере ?