Шуллер. Изначально было Double Commander 0.9.0 (комментарий) и в процессе тот факт, что при удалении фм выдает предупреждение а rm нет, вы же вместо того что бы согласиться с этим фактом, сначала возразили что rm тоже выдает предупреждение и далее приплели что выдает при правах 000.

desktop environment или среда рабочего стола

Что это за абстракция такая шиндузячая? Что ты в неё вкладываешь?

Обновлялся дистрибутив

И что это есть такое? У меня оно сводится к смене репозитория, например.

the bugfix release

Double Commander 0.9.1

Случаи индивидуальные, я много чо делаю. Вот недавно страницы из DjVu выдирале в жпег. Гит шатаю, в /etc чот ковыряю, апдейты разгребаю, к сервакам подрубаюсь, процессы прибиваю, картинки по ссылкам на говнохостинги открываю, слова на GT засылаю, хуизы дёргаю, музло запускаю, по проектам чот грепаю, из CSV-шек и JSON-ов чот считаю, файлы плейнтекстовые смотрю, курлой всякое дёргаю, мультимедию конвертирую, ну и так далее, дохрена всякого, короче.

Благодарю. На самом деле это очень похоже на то, что делаю я, и мне тем более непонятно, ведь с ФМ многое из этого делать легче...

Запуск команд и в ФМ и в консоли одинаков. Но те же страницы в жпеге или сдёрнутые курлой файлы надо куда-то сохранить, переименовать, и в консоли это копипаст мышой или протабывание имени, а в ФМ-е — одна кнопка. Греп, мы уже выясняли, в ФМе местами проще, ведь там можно и задать маску и строку поиска, без тормозов **/ хака и без длинной команды. Плейнтекст-файлы просматривать тоже в ФМ проще: заглянуть в десяток файлов можно методом F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз...

Нашле проблему, можешь вообще сделать скрипт, который генерирует в /tmp рандомную директорию и автоматом туда монтирует. Тогда и проблема чистки отпадает.

Да! Именно! Так с годами можно насобирать скриптов, делающих то... что в ФМ есть из коробки! Так ради чего стараться-то, почему не взять готовое в ФМ?

Простота — враг продуктивости; навыки продуктивной работы требуют непростого обучения.

Наоборот, лень — двигатель прогресса! Иначе все до сих пор писали программы на ассемблере. А что, зачем изучать что-то более простое, зачем экономить время разработки, если можно страдать и всё писать на сложном ассемблере?

Для полутора шаблонных задач, а с остальным что делать?

Так я как раз и пытаюсь сказать, что это не полторы, а большинство шаблонных задач работы с файлами. По сути в ФМ — это такой апгрейд консоли, с готовыми плюшками и хоткеями для многих задач. Почему б ими не воспользоваться?

Похоже, всё сводится к «консоль я знаю, и мне её достаточно, а менять свои привычки... да ну его, мне итак неплохо». Ну что ж, такая точка зрения тоже имеет право на жизнь.

переименовать

Зачем? сразу указываешь нужное имя.

местами проще

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

F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз…

Извращения; пихнуть пачкой в less и листать по :n/:p проще. А лучше вообще на одну кнопку замапить.

почему не взять готовое в ФМ?

Потому что это «готовое» неюзабельно и толком не расширяемо.

лень — двигатель прогресса

Не совсем; лень должна быть стимулом, чтобы выйти из зоны комфорта с целью лениться ещё больше в будущем. Если на стимул её не хватает — из лентяя вместо творца получается аморфное существо, которое без погонщика способно только пиво сосать да пузо чесать перед зомбоящиком.

а большинство шаблонных задач работы с файлами

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

По сути в ФМ — это такой апгрейд консоли

Мхех, типичный аргумент GUI-пропагандистов, ему уже десятки лет. Только он инвалид, потому что GUI на самом деле — деградация в сторону упрощения освоения, но не улучшения продуктивности.

Похоже, всё сводится к «консоль я знаю, и мне её достаточно, а менять свои привычки… да ну его, мне итак неплохо»

Как это коррелирует с тем, что я много лет пользовалесь двухпанельниками и в итоге ушле с них?

Плейнтекст-файлы просматривать тоже в ФМ проще: заглянуть в десяток файлов можно методом F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз...
лень — двигатель прогресса!

Именно! Есть люди, которым не лень нажимать десять раз одно и тоже. Есть те, которым лень. Они задумаются, как это автоматизировать. И тут знание шелла может очень помочь. А в ФМ они так и будут дальше нажимать F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз...

Сабж же не только под линукс... (да, я большую часть времени провожу в Windows, что поделать)

По сути в ФМ — это такой апгрейд консоли, с готовыми плюшками и хоткеями для многих задач.

ФМ — это даунгрейд шелла, заменяющий возможность бесконечного многообразия в комбинации небольшого количества команд для создания нужного тебе действия на полтора десятка хоткеев для полутора десятков шаблонных действий.

Единственное, что, возможно, более удобно в ФМ, чем в шелле, так это пялиться на большое количество файлов. И единственный юзкейс для этого, как уже писалось выше по треду, — это разгребание файлопомойки. В остальных случаях ФМ просто не нужен, так как ничем не улучшает работу в шелле. Скорее мешается. Я когда-то давно потому и перестал mc использовать, что он мне при работе с файлами никак особо не помогал, а при попытке воспользоваться из него шеллом довольно сильно мешал.

Похоже, всё сводится к «консоль я знаю, и мне её достаточно, а менять свои привычки... да ну его, мне итак неплохо». Ну что ж, такая точка зрения тоже имеет право на жизнь.

Как видишь, я тоже пользовался двухпанельными ФМ, сначала в ДОСе, потом в линуксе. И, как и Moondancer, отказался от ФМ. Может это твоя точка зрения односторонняя, а не наша? Насколько хорошо ты знаешь шелл, чтобы сравнивать его с ФМ?

Но в линуксе системного нет. К сожалению.

Но в линуксе системного нет. К сожалению.

В виндовсе его тоже нет. Есть меню проводника, которое никак не связано с меню ворда, фотошопа или винампа.

Но проводник один. А сколько фм в линуксе????

ФМ — это даунгрейд шелла, заменяющий возможность бесконечного многообразия в комбинации небольшого количества команд для создания нужного тебе действия на полтора десятка хоткеев для полутора десятков шаблонных действий.

Он их и не заменяет. В нём есть шелл (Ctrl+O в mc, F9 в сабже), никто не запрещает им пользоваться.

Насколько хорошо ты знаешь шелл, чтобы сравнивать его с ФМ?

Как оказалось, достаточно хорошо, чтобы указывать Moondancer-у, как не получится сделать рекурсивный поиск, и чем лучше смотреть hex-ы в консоли. :)

Как видишь, я тоже пользовался двухпанельными ФМ, сначала в ДОСе, потом в линуксе. И, как и Moondancer, отказался от ФМ. Может это твоя точка зрения односторонняя, а не наша?

А у меня нет этой категоричности. Я не выбираю что-то одно. Консоль хороша для автоматизации однотипных действий, ФМ — для интерактивности и одноразовых действий. Если мне нужно пересжать пачку .log.gz файлов в .log.xz для экономии места, то я сделаю это в консоли (for i in *.log.gz; do gzip -d "$i" && xz -v "${i%.gz}"; done). Но, чтобы в одном из этих логов найти нужную строку, я не буду набирать zcat, grep, less и табать имя — я нажму F3 и F7 в mc (сабж так не может, очередной минус ему, увы).

И если это не привычки, то мне искренне непонятно, что может человека, знакомого с ФМ, заставить им не пользоваться... Это ж не выбор, ФМ не отбирает консоль. Может быть это — экономия места, или стремление к минимализму, попытка использовать систему с наименьшим числом программ? А, может, вы с Moondancer-ом гентушники или LFS-ники, и для вас каждый апдейт — это пересборка кучи зависимостей, которых у ФМ-ов обычно немало? И поэтому собирать мелкие утилиты вам нравится больше, чем большой ФМ?

Зачем? сразу указываешь нужное имя.

Мало ли... Может стягивались они автоматически (for i in ...) с серверным именем (article1, article2, ...) а я хочу им теперь осмысленные имена дать. В любом случае, могут быть причины для переименования, и в FM это переименование делается парой кнопок.

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

Может быть в каком-то теоретическом общем случае и проще. А на практике в сабже это окно немодальное. В mc оно модальное, но его можно сбросить на панель. И там их можно просмотреть, пометить нужные, скопировать в другой каталог и т.д.

F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз…

Извращения; пихнуть пачкой в less и листать по :n/:p проще. А лучше вообще на одну кнопку замапить.

Увы, в консоли их нельзя пихнуть пачкой в less. Можно только перезапустить команду поиска ещё раз, направив её вывод на вход less-у... Кстати! А как? ;) Ну-ка, покажи пример команды поиска, перенаправляющий результат в less так, что можно листать между файлами по :n/:p? А то сейчас окажется, что в общем случае на баше это фиг напишешь...

Потому что это «готовое» неюзабельно и толком не расширяемо.

Очень расширяемо. Тот же mc отлично «расширен» и из коробки поддерживает кучу архиваторов и форматов файлов. И добавить новый можно дописав в bindings... sh-однострочник!

Не совсем; лень должна быть стимулом, чтобы выйти из зоны комфорта с целью лениться ещё больше в будущем.

Да, так и есть. Именно так и написали ФМ-ы, чтобы лениться и делать в ФМ одной кнопкой то, что в консоли требует кучи разных команд.

GUI на самом деле — деградация в сторону упрощения освоения, но не улучшения продуктивности.

Ну вот с этим я и спорю, ведь многие распространённые задачи, копирование, перемещение, переименование, просмотр пакетов и архивов и извлечение файлов из них — в ФМ делаются одной кнопкой. Продуктивнее просто некуда.

сабж так не может, очередной минус ему, увы

из коробки не может. при желании можно прикрутить шелскрит как archive.sh в mc через файловые ассоциации или плагин

Он их и не заменяет. В нём есть шелл
Это ж не выбор, ФМ не отбирает консоль.

Попытка скрестить ФМ с консолью (как в mc) мне показалась неудачной. Работа с шеллом изнутри mc доставляла массу неудобств.

А если попеременно пользоваться то шеллом, то ФМ, то придётся одновременно держать в голове два весьма разных способа работы и постоянно переключаться между ними. Это неудобно и непродуктивно.

Как оказалось, достаточно хорошо,

Вот тут анонимус писал

Поэтому я серьёзно сомневаюсь, стоит ли запоминать консольные команды и параметры, тратить время на скрипты и алиасы...

Это был не ты? Я из этого сделал вывод, что недостаточно хорошо.

А у меня нет этой категоричности.

У меня тоже нет категоричности. Я же не предлагаю уничтожить ФМ как класс. Для решения простых задач работы с файлами они вполне подходят. Вот только, если я уже владею на порядок более гибким инструментом, шеллом, то пользоваться ФМ просто не вижу смысла.

Я не выбираю что-то одно. Консоль хороша для автоматизации однотипных действий, ФМ — для интерактивности и одноразовых действий.

Рад за тебя. А для меня консоль хороша в том числе и для интерактивности и одноразовых действий. А юзкейс, в котором ФМ для меня лучше шелла, я уже описывал. Если мне часто придётся копаться в чужих файлопомойках (своих я не создаю), то поставлю себе хоть тот же mc.

Но, чтобы в одном из этих логов найти нужную строку, я не буду набирать zcat, grep, less и табать имя — я нажму F3 и F7 в mc

Если очень нужна интерактивность, то в данном случае можно написать zless <файл> и сделать поиск кнопкой / внутри less'а. С другой стороны, даже в таком одноразовом случае бывает удобно сделать grep/zgrep. Теряя в интерактивности, так можно выиграть в гибкости, чтобы потом с выводом grep'а ещё что-нибудь сделать. И, кстати, зачем ты после каждого чиха пытаешься всунуть | less? Это вовсе не нужно так часто, как тебе кажется.

У меня, кстати, эти zcat, grep, less и прочие слетают с кончиков пальцев не задумываясь. А от одной мысли об унылом десятикратном нажатии на стрелочку становится противно (это не выпад в сторону стрелочек, от десятикратного нажатия на C-n в emacs'е у меня те же ощущения, поэтому я так не делаю). Кстати, помимо прочего, работа с командами шелла ещё и развивает креативность, тогда как от работы в ФМ ничего кроме скуки и уныния я не испытываю.

И если это не привычки, то мне искренне непонятно, что может человека, знакомого с ФМ, заставить им не пользоваться...

Для комфортной работы в шелле нужно (1) знание основных команд (ссылку на POSIX я приводил), (2) умение их эффективно комбинировать и (3) владение слепой десятипальцевой печатью. Если у тебя все эти навыки есть и ты искренне хочешь понять, то попробуй удалить из своей системы ФМ и с месяц активно поработать с файлами только из шелла. После этого приходи, обсудим, что может человека, умеющего в шелл, заставить пользоваться ФМ. :)

лень — двигатель прогресса

Не совсем; лень должна быть стимулом, чтобы выйти из зоны комфорта с целью лениться ещё больше в будущем.

Да, так и есть. Именно так и написали ФМ-ы, чтобы лениться и делать в ФМ одной кнопкой то, что в консоли требует кучи разных команд.

Они-то может и двигали прогресс, когда ФМ писали. А ты-то в ФМ просто тупо ленишься (F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз… и так десять раз, ага). И никакого прогресса. ;)

Плейнтекст-файлы просматривать тоже в ФМ проще: заглянуть в десяток файлов можно методом F3, Esc, вниз, F3, Esc, вниз, F3, Esc, вниз...

Извращения; пихнуть пачкой в less и листать по :n/:p проще. А лучше вообще на одну кнопку замапить.

Увы, в консоли их нельзя пихнуть пачкой в less. Можно только перезапустить команду поиска ещё раз, направив её вывод на вход less-у...

Зачем же ты меняешь условия задачи на ходу? У нас все ходы записаны. ;) Изначально задача была заглянуть в файлы, никакого поиска. И Moondancer вполне её решил: пихнуть файлы в less действительно проще, чем унылые F3, Esc, вниз...

Кстати! А как? ;) Ну-ка, покажи пример команды поиска, перенаправляющий результат в less так, что можно листать между файлами по :n/:p?

Гы. grep string file[123]. | less по вкусу, если вывод длинный. Никакие :n/:p тут не нужны. Не усложняй, ты похоже сам толком не понял, чего хочешь.

GUI на самом деле — деградация в сторону упрощения освоения, но не улучшения продуктивности.

Ну вот с этим я и спорю, ведь многие распространённые задачи, копирование, перемещение, переименование, просмотр пакетов и архивов и извлечение файлов из них — в ФМ делаются одной кнопкой. Продуктивнее просто некуда.

Кнопки «сделать всё зашибись» не существует. Функциональность кнопок ограничена и фиксирована. Как и их количество. И рано или поздно их начинает не хватать — тут-то GUI-программа и превращается в тыкву.

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

Кстати говоря, IT-корпорациям, конечно, выгоднее давать «тупым юзерам» рыбу, а не удочку. По понятным причинам.

Эмбракоделов это тоже подутомило, начиная с Delphi 10.3 Rio переменные можно объявлять по ходу пьесы.
http://docwiki.embarcadero.com/RADStudio/Rio/en/Inline_Variable_Declaration

В FPC такого нет и не известно, будет ли.

Дополню.
Судя по рассылке разработчиков, не будет.

So are inline variables coming soon?
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

We have already decided internally that this feature is where we draw the line. We won't implement it and we are also inclined to say «patches *not* welcome» for that.

Попытка скрестить ФМ с консолью (как в mc) мне показалась неудачной. Работа с шеллом изнутри mc доставляла массу неудобств.

А мне, наоборот, вариант mc, как надстройки над шеллом, нравится больше, чем doublecmd, в котором шелл запускается отдельно. В mс у меня общий шелл во всех каталогах, с общей историей, алиасами и функциями. А в doublecmd я не могу присвоить результат в переменную в одном каталоге, а потом использовать эту переменную в других.

Поэтому я серьёзно сомневаюсь, стоит ли запоминать консольные команды и параметры, тратить время на скрипты и алиасы...

Это был не ты? Я из этого сделал вывод, что недостаточно хорошо.

Я. И я действительно считаю, что их не нужно запоминать. Ведь можно комфортно работать в ФМ, не запоминая их. Подробности ниже.

Если очень нужна интерактивность, то в данном случае можно написать zless <файл> и сделать поиск кнопкой / внутри less'а.

Можно. Но даже zless <файл> набирать дольше, чем нажать F3 и F7.

С другой стороны, даже в таком одноразовом случае бывает удобно сделать grep/zgrep. Теряя в интерактивности, так можно выиграть в гибкости, чтобы потом с выводом grep'а ещё что-нибудь сделать.

Да нет там такого. Нельзя «потом что-нибудь сделать» с уже выполненной командой. Можно только отредактировать и перезапустить весь однострочник ещё раз. А потом ещё раз отредактировать и перезапустить. И ещё раз. И ещё раз.

И, кстати, зачем ты после каждого чиха пытаешься всунуть | less? Это вовсе не нужно так часто, как тебе кажется.

В консоли почти никогда не знаешь, сколько строк сейчас высыпется на экран. Проще на всякий случай добавить |less, чем получить простыню, которая затрёт какой-нибудь ценный файлнейм в скроллбеке.

У меня, кстати, эти zcat, grep, less и прочие слетают с кончиков пальцев не задумываясь. А от одной мысли об унылом десятикратном нажатии на стрелочку становится противно

Это — самообман. Точнее, нет, желание автоматизировать рутинные действия — это нормально. Но его надо распространять на всё, а не только на одинаковые нажатия. Ведь на самом деле мы хотим быстрее/легче достичь цели, а не достичь её более разнообразным и запутанным путём. Поэтому между 10-кратным нажатием на F3/«вниз» и 100-кратным нажатием на 26 разных кнопок логичнее всё-таки выбрать F3.

Для комфортной работы в шелле нужно (1) знание основных команд (ссылку на POSIX я приводил), (2) умение их эффективно комбинировать и (3) владение слепой десятипальцевой печатью.

Хорошо. Отбросим вопрос продуктивности, и рассмотрим только вопрос комфорта. Для комфортной работы в ФМ нужно знать десяток хоткеев, они решат 90% задач, а для оставшихся 10% надо знать десяток шелл-команд, параметры можно не запоминать — в этих редких 10% случаев их можно посмотреть и в мане.

А для комфортной работы в шелле нужно знать несколько десятков команд умножить на десяток параметров для каждой команды, чтобы не лезть в ман на каждой строчке. Это покроет 90% задач, а для оставшихся 10% задач нужно всё равно лезть в ман, чтобы найти нужный параметр.

Вот и выходит, что 90% задач и там и там решаются сразу. И 10% задач решаются после просмотра мана. Но в ФМе для комфортной работы помнить приходится меньше!

Зачем же ты меняешь условия задачи на ходу? У нас все ходы записаны. ;) Изначально задача была заглянуть в файлы, никакого поиска. И Moondancer вполне её решил: пихнуть файлы в less действительно проще, чем унылые F3, Esc, вниз...

Ну да, у нас есть десяток файлов, то ли они лежат в одном каталоге, то ли в разных и это результат поиска, но как-то они у нас появились. В ФМ в них можно заглянуть через F3/вниз, не важно, где они. А вот как их пихнуть в less?

Гы. grep string file[123]. | less по вкусу, если вывод длинный. Никакие :n/:p тут не нужны. Не усложняй, ты похоже сам толком не понял, чего хочешь.

Не-не, это не я. Так и я могу. Мне интересно как их пихнуть в less так, чтобы по :n/:p листать. И интересно мне это потому, что в mc, как оказалось, это сделать можно, и листать там проще!

Кнопки «сделать всё зашибись» не существует. Функциональность кнопок ограничена и фиксирована. Как и их количество. И рано или поздно их начинает не хватать — тут-то GUI-программа и превращается в тыкву.

Ха! Не в тыкву, а в консоль! ФМ — это удобное представление и хоткеи, которые в одно нажатие делают то, что в консоли требует десятков команд. ФМ без всего этого — это и есть консоль, строка для ввода команд.

Тут как в той истории: можно дать голодному рыбу, чтобы он наелся один раз, а можно дать ему удочку

Это не тот случай. У нас это дать удочку и шлюпку, когда можно дать рыболовный катер с эхолотом, набором спиннингов, холодильником и туалетом.

А мне, наоборот, вариант mc, как надстройки над шеллом, нравится больше, чем doublecmd, в котором шелл запускается отдельно.

О doublecmd vs mc тут речи вообще не идёт, как уже кто-то заметил выше по треду. :) Я говорю, что мне оба варианта с ФМ неудобны.

Это был не ты? Я из этого сделал вывод, что недостаточно хорошо.

Я. И я действительно считаю, что их не нужно запоминать. Ведь можно комфортно работать в ФМ, не запоминая их.

То есть, ты их запоминать не хочешь, тебе комфортно в ФМ, поскольку его хватает для твоих задач. Ну ок, тут спорить не с чем.

Заметь, мне вполне понятно, как и почему тебе или ещё кому-то может быть удобно что-то делать в ФМ и неудобно в командной строке. А вот ты не понимаешь, как мне или ещё кому-то может быть удобнее всё, что может ФМ, делать в командной строке, о чём и пишешь:

И если это не привычки, то мне искренне непонятно, что может человека, знакомого с ФМ, заставить им не пользоваться...

Хочешь понять — вперёд, я тебе уже описал алгоритм действий:

Для комфортной работы в шелле нужно (1) знание основных команд (ссылку на POSIX я приводил), (2) умение их эффективно комбинировать и (3) владение слепой десятипальцевой печатью. Если у тебя все эти навыки есть и ты искренне хочешь понять, то попробуй удалить из своей системы ФМ и с месяц активно поработать с файлами только из шелла. После этого приходи, обсудим, что может человека, умеющего в шелл, заставить пользоваться ФМ. :)

Ведь на самом деле мы хотим быстрее/легче достичь цели, а не достичь её более разнообразным и запутанным путём.

Человек — не робот. Есть такая наука, эргономика. Она многократно экспериментально проверила и подтвердила тот факт, что однообразные действия для человека гораздо утомительнее, чем разнообразные.

Поэтому между 10-кратным нажатием на F3/«вниз» и 100-кратным нажатием

Ну, тут ты красиво преувеличил. Соотношение будет, всё-таки, не 10/100.

на 26 разных кнопок логичнее всё-таки выбрать F3.

Поэтому и необходимо "(3) владение слепой десятипальцевой печатью". Если этот навык есть, то оказывается, что тянуться десять раз к F3 менее удобно и более утомительно (см. про эргономику), чем напечатать десяток слов. Причём я даже не воспринимаю «напечатать десяток слов» как отдельные нажатия на сколько-то клавиш. Вот честно (хотя, ты же опять скажешь «самообман», чего уж тут).

Чтобы у дальнейшего разговора был хоть какой-то смысл, ответь, умеешь ли ты в слепую десятипалцевую?

Отбросим вопрос продуктивности, и рассмотрим только вопрос комфорта.

Вопрос продуктивности мы отбрасывать не будем. Потому что лежать на диване, хоть и непродуктивно, но комфортнее, чем пользоваться шеллом или ФМ. ;)

Короче, дальнейшая дискуссия пойдёт, скорее всего, по кругу. Тебе будут говорить, что у нас есть опыт работы и с тем, и с другим, без ФМ нам удобнее. А ты будешь отвечать, что не веришь, что «у вас самообман». При том что сам, судя по всему, не освоил шелл настолько хорошо, чтобы сказать, что в равной степени умеешь и то, и другое.

у нас есть десяток файлов, то ли они лежат в одном каталоге, то ли в разных и это результат поиска
как их пихнуть в less?

grep -Rl <что ищем> <где ищем> | xargs less

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

Тут я бы сравнил ФМ с катером или шлюпкой (в зависимости от, ФМ разные бывают), а шелл с рыбокомбинатом.

То есть, ты их запоминать не хочешь, тебе комфортно в ФМ, поскольку его хватает для твоих задач.

Не так. Я утверждаю, что запоминать их нет необходимости. Можно, просто не нужно. Потому что в ФМ можно комфортно выполнять ЛЮБЫЕ задачи без них. Да, мне хватает ФМ+консоли для любых задач. И это для меня удобнее, чем консоль без ФМ.

Но если я всё равно пользуюсь консолью, то для чего мне ФМ? А для того, чтобы делать часть задач быстрее. Не все задачи, только часть. Но это — большая часть повседневных задач.

Человек — не робот. Есть такая наука, эргономика. Она многократно экспериментально проверила и подтвердила тот факт, что однообразные действия для человека гораздо утомительнее, чем разнообразные.

Вообще-то, наоборот. Простые однотипные действия можно выполнять часами, при этом слушать музыку, жевать бутерброд и болтать с соседом. А сложные разнообразные действия требуют полного внимания, утомляют намного быстрее, и вызывает больше ошибок. Поэтому с момента изобретения конвейера работы на нём разбивались на простые однотипные задачи.

Ну, тут ты красиво преувеличил. Соотношение будет, всё-таки, не 10/100.

Да, это был просто пример. Но, тем не менее, разрыв значительный, и не в пользу консоли. И приходится писать кучу скриптов и алиасов, чтобы его сократить.

Чтобы у дальнейшего разговора был хоть какой-то смысл, ответь, умеешь ли ты в слепую десятипалцевую?

Да, причём не типичный 7-9-пальцевый в «основной позиции», а 10-пальцевый на полноразмерной 105-клавишной клавиатуре. То есть я могу вслепую нажать на F3, прыгнуть рукой на мышь или курсор, понажимать PageUp/PageDown, и продолжить набор текста не глядя на клавиатуру.

Короче, дальнейшая дискуссия пойдёт, скорее всего, по кругу. Тебе будут говорить, что у нас есть опыт работы и с тем, и с другим, без ФМ нам удобнее. А ты будешь отвечать, что не веришь, что «у вас самообман».

Не, она у нас иначе идёт по кругу. Я спрашиваю, чем плох ФМ, прошу привести пример того, что в ФМ+консоли делать хуже, чем в консоли без ФМ. Я всё жду примера вроде «мне нужно сделать X, в консоли я это делаю <так>, а в ФМ-е мне пришлось бы сделать <так>, а это в два раза дольше/сложнее». То есть пример, который сравнивает одно и то же действие в консоли и в ФМ и показывает, что в ФМ оно хуже.

Или, например что-то вроде «у меня терминал виснет, когда на него выводят цветные символы, поэтому в консоли я работать могу, а в mc не могу - он подвешивает мой терминал». Такой пример был бы понятен. Но вместо этого я в ответ получаю только общие «мне без него удобнее» и «я всё делаю без него быстрее».

Тогда уже я привожу конкретные примеры где ФМ удобнее (копирование с прогрессом, переименование, поиск по маске и содержимому, просмотр соседних файлов, навигация по архивам и пакетам...) и в ответ получаю, что можно не намного хуже делать это в консоли. Не лучше, хуже, но не намного.

Я не пользуюсь ФМ-ом вместо консоли, я использую ФМ И консоль. Никого ж не удивляет, когда для консоли пишут кучу скриптов, чтобы легче работать? И никого не удивляет, когда в консоли используют внешние интерактивные утилиты, смотрят вывод less-ом вместо cat-а, редактируют в vim/emacs вместо sed-а. Так почему же такое неприятие вызывает ещё одна консольная утилита mc, точно так же делающая работу в консоли более продуктивной?

grep -Rl <что ищем> <где ищем> | xargs less

Не будет работать, если в именах файлов есть пробелы. Облом, да? Что ещё хуже, это можно не заметить, потому что часть файлов таки откроется, но не все.

И это уже не первый раз в треде, когда сторонники консоли предлагают частично нерабочее решение. Вот так сложность и неудобство консоли способствует ошибкам. Я уже сомневаюсь, кто из нас знает консоль. :)

Тут я бы сравнил ФМ с катером или шлюпкой (в зависимости от, ФМ разные бывают), а шелл с рыбокомбинатом.

Да. Причём катер управляется из кабины с кучей ручек, педалей и индикаторов, а рыбокомбинат — из чёрной комнаты с дыркой в стене, в которую надо кричать распоряжения и слушать, что крикнут в ответ.

Блин, прямо спор радио vs телевизор...

Но даже zless <файл> набирать дольше, чем нажать F3 и F7.

Кстати, опять же, мне владение слепой десятипальцевой печатью позволяет, набирая zless, не думать о клавиатуре. То есть вот вообще. Задумываться о том, что у меня есть пальцы, клавиши, и нужно этими пальцами эти клавиши нажимать, приходится только если нужно тянуться к F-кнопкам или стрелочкам.

И тут дело даже не в скорости. Хотя не думаю, что ты быстрее перейдёшь к нужному файлу и нажмёшь свои F3 и F7, чем я наберу zless <файл>.

Чтобы у дальнейшего разговора был хоть какой-то смысл, ответь, умеешь ли ты в слепую десятипалцевую?

Да, причём не типичный 7-9-пальцевый в «основной позиции», а 10-пальцевый на полноразмерной 105-клавишной клавиатуре. То есть я могу вслепую нажать на F3, прыгнуть рукой на мышь или курсор, понажимать PageUp/PageDown, и продолжить набор текста не глядя на клавиатуру.

Ясно-понятно.

Простые однотипные действия можно выполнять часами, при этом слушать музыку, жевать бутерброд и болтать с соседом. А сложные разнообразные действия требуют полного внимания, утомляют намного быстрее, и вызывает больше ошибок. Поэтому с момента изобретения конвейера работы на нём разбивались на простые однотипные задачи.

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

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

Ага, ты ещё скажи, что работнкики конвейера счастливее, чем, например, инженер, разрабатывающий что-то для этого конвейера.

Счастье — понятие субъективное. Наркоман или кретин (в медицинском смысле) тоже может валяться в углу и быть счастливее инженера.

А хотя... Инженер тоже может неделю не спать и матом крыть всех вокруг, потому что проект итак не укладывается в бюджет, а тут ещё и подрядчики прислали гавно вместо запчастей... А у работников-то этих проблем нет. Так что, да, в этом смысле они счастливее.

если ты готов часами выполнять простые однотипные действия, и тебя это не парит, то мне с тобой разговаривать не о чем.

Смотря из чего выбирать. Если выбирать между 10 минутами однотипных действий и 10 минутами сложной требующей полного внимания работы, то я однозначно выберу однотипные действия — легче, меньше шанс ошибиться, и можно параллельно думать над чем-то ещё. А что выберешь ты? ;)

Человек — не робот. Есть такая наука, эргономика. Она многократно экспериментально проверила и подтвердила тот факт, что однообразные действия для человека гораздо утомительнее, чем разнообразные.

Поддержу, «i like to move it move it» утомляет быстрее, да и при определенном кол-ве однотипных «нажатий» не нулевой шанс пропустить какое-то нажатие. Например два раза «вниз» вместо одного.

Поэтому и необходимо "(3) владение слепой десятипальцевой печатью"

При наборе команд, это не является такой уж сильной необходимостью, точнее прибавка к «скорости выполнения задачи»(приложенных усилий) в конечном итоге будет незаметна. А вот это:

тянуться десять раз к F3 менее удобно

верно, и как раз к минусу «скорости».

у меня терминал виснет, когда на него выводят цветные символы, поэтому в консоли я работать могу, а в mc не могу - он подвешивает мой терминал

Выше я уже писал, работа на неустойчивых/низкоскоростных каналах, enter на большом архиве «он подвешивает мой терминал». Плюс медленное копирование/удаление большого кол-ва фалов (ведь прямо базовый функционал). Еще емнип у mc заливка на ftp через tmp была, хотя тут могу гнать.

Если выбирать между 10 минутами однотипных действий и 10 минутами сложной требующей полного внимания работы, то я однозначно выберу однотипные действия — легче

Тут такая фигня, что при повторе этих же действий соотношение уже окажется 10мин - <10мин т.к. мы уже один раз потратили «10 минут на сложную требующего полного внимания работу». Т.е. вы изо дня в день, из года в год будете «крутить гайку» и тратить все те же 10минут, в то время как тот кто «единожды потратил 10 минут на сложную требующего полного внимания работу» «сэкономленное» время на повторениях этой операции потратит на «слушать музыку, жевать бутерброд и болтать с соседом» в любимом баре и не будет при этом отвлекаться на «крутить гайку».

Выше я уже писал, работа на неустойчивых/низкоскоростных каналах

Это не понятно. По-моему, наоборот, ходить на сервер с высоким пингом через mc/sshfs удобнее, чем через ssh в консоли — меньше действий, а значит меньше и задержка. Да и просмотр/редактирование файлов работает локально и мгновенно, а не через N секунд, когда экран по ssh перерисуется.

enter на большом архиве «он подвешивает мой терминал».

Принято, это баг. Предлагаю написать багрепорт разработчикам, потому что, похоже, до сих пор этого никто не сделал.

Плюс медленное копирование/удаление большого кол-ва фалов (ведь прямо базовый функционал).

По-моему, так же как везде. А почему бы вдруг копирование в mc могло быть медленнее того же rsync-а?

Еще емнип у mc заливка на ftp через tmp была, хотя тут могу гнать.

Вроде, нет. Только редактирование ftp-шных файлов — если по ftp нажать F3/F4, то файл вытянется в tmp, и оттуда отобразится, а при сохранении зальётся обратно.

при повторе этих же действий соотношение уже окажется 10мин - <10мин т.к. мы уже один раз потратили «10 минут на сложную требующего полного внимания работу». Т.е. вы изо дня в день, из года в год будете «крутить гайку»

Во-первых, возможность оптимизации и написания автоматического скрипта в ФМ никто не отменял. В том же mc все ассоциации, фильтры и распаковщики архивов — это такие же скрипты, просто готовые, уже написанные.

Во-вторых, нужен конкретный пример. Потому что в ГУЕ большинство действий, требующих повтора, делаются одной кнопкой. И даже после 10 минут сложной работы, сделать их на следующий день в консоли менее чем одной кнопкой не получится.

enter на большом архиве «он подвешивает мой терминал».

Принято, это баг. Предлагаю написать багрепорт разработчикам, потому что, похоже, до сих пор этого никто не сделал.

Апдейт: нет, не баг. В mc можно прервать открытие архива хоткеем Ctrl+G.

Эх... Единственный минус в ФМ нашли, и тот не состоялся.

По-моему, наоборот, ходить на сервер с высоким пингом через mc/sshfs удобнее, чем через ssh в консоли — меньше действий, а значит меньше и задержка. Да и просмотр/редактирование файлов работает локально и мгновенно, а не через N секунд, когда экран по ssh перерисуется.

С точностью до наоборот. При всех описанных вами действиях файлики/список-файликов надо загрузить на локальную машинку/выгрузить обратно на удаленную. На фоне этого перерисовка экрана на удаленной машине это копейки байтиков.

Принято, это баг. Предлагаю написать багрепорт разработчикам, потому что, похоже, до сих пор этого никто не сделал.

Уже ответили, оказывается можно прервать не только килом.

По-моему, так же как везде. А почему бы вдруг копирование в mc могло быть медленнее того же rsync-а?

Потому что это хрень видимо «высчитывает» весь список файликов перед началом копирования, нажмите F5 на каталоге в котором дофейхуа фаликов и посмотрите как она «радостно» потупит вначале. А с удалением вообще беда.

Во-первых, возможность оптимизации и написания автоматического скрипта в ФМ никто не отменял.

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

Во-вторых, нужен конкретный пример.

Моя же цитата, чуть поправленная, в прошлый раз не дописал, но сути это не меняет:

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

В фм «F3, etc...» это те самые «N минут однотипных действий» от которых посинеешь. Но выполнимо? Выполнимо же.

Апдейт: нет, не баг. В mc можно прервать открытие архива хоткеем Ctrl+G.

Век живи, век учись.

Давайте перечислим хорошие файл менеджеры!

Из графического я считаю лучший Dolphin, остальное говно.

Из консольного юзнаю MC, и вот недавно про Dpuble Commander узнал. Заинтересовался, какие еще консольные менеджеры есть, оказалось несколько есть, но они тоже говно. Выходит под консоль хорошего только 2 - MC и Double Commander? Причем непонятно какой лучше и почему.

Выходит под консоль хорошего только 2 - MC и Double Commander?

Под консоль — только MC. Double Commander — это клон Windows Commander-а (aka Total Commander), он — графический, с возможностью запуска из него консоли и консольных команд.

С точностью до наоборот. При всех описанных вами действиях файлики/список-файликов надо загрузить на локальную машинку/выгрузить обратно на удаленную. На фоне этого перерисовка экрана на удаленной машине это копейки байтиков.

Может мы о разных вещах говорим? Тут дело не в количестве байтов, а в пинге. Есть машина, до неё длинный канал и пинг больше секунды. Я жму ssh somehost, и получаю консоль, в которой каждое нажатие отобразится только через 1-2 секунды. По сути команды я набираю вслепую, затем жду секунду, чтобы они отобразились, жму Enter, и жду вывод. Правятся команды так же: вслепую бежать курсором влево, ждать секунду пока курсор отрисуется, исправлять, ждать пока исправление отрисуется, Enter, ждать пока вывод отрисуется. И так по каждой команде. Посмотреть файл? Каждый PageUp/PageDown в less ждём пару секунд. Отредактировать файл? Каждая кнопка в vim - та же пара секунд.

Теперь как это выглядит в ssh over mc: жму Ctrl+\ (hotlist) выбираю хост, жму Enter, жду пару секунд, и я на нём — вижу список файлов, имена, размеры, могу выбрать любой из них, нажать F3, и через пару секунд увидеть весь файл, мгновенно скроллить его, делать по нему поиск и т.д. То же и с редактированием — задержка будет только в момент сохранения, а всё остальное — мгновенно. Разве так не удобнее?

Потому что это хрень видимо «высчитывает» весь список файликов перед началом копирования, нажмите F5 на каталоге в котором дофейхуа фаликов и посмотрите как она «радостно» потупит вначале. А с удалением вообще беда.

Но и rsync делает то же самое? Да и в чём, собственно, беда? Нам в любом случае нужно было обойти все файлы, какая разница, обойдём мы их все в начале, или позже?

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

В такой строгой постановке, когда сразу известно, где лежит тег, и сколько надо строк до и после — задача сразу решается grep-ом с параметрами, которые, если даже я не помню, можно глянуть в мане. То есть я в ФМ-е захожу в нужный каталог и набираю grep ... Это вопрос 30 секунд, а не 10 минут.

Но пример хороший, напомнило мне о похожем случае: нужно найти в логах, какое событие могло вызвать подвисание программы. Известно примерное время подвисания, но не известно, какое это событие, и даже не известно, в каком из сотни логов искать. В mc заходим в каталог с логами, рекурсивный поиск, регуляркой захватываем плюс-минус час от известного времени, запускаем поиск. Как только нашло первый файл, жмём на нём F3 (он сразу откроет файл на найденной строке, это не прерывает поиск), листаем, читаем, прикидываем в чём может быть дело, затем Esc-вниз-F3, заглядываем следующий, листаем, думаем, снова Esc-вниз-F3, замечаем, что в этом логе тоже есть небольшая дырка в событиях, проверяем в предыдущем, Esc-вверх-F3... а что в логе было перед дыркой? О, похоже, нашли! Запускаем поиск по этому событию и находим ещё два похожих момента, которые не заметили раньше — причина найдена, задача решена.

Каждое действие занимало 1-3 кнопки, не отвлекаясь ни на man, ни на выдумывание как соединить find и grep, а вывод передать в less, как переключаться между файлами, и т.д. И имена найденных файлов мышой тоже копировать не пришлось (кто действительно юзает консоль — знает как часто приходится это делать).

Вот тут действительно работы 10-30 минут, и «однотипные действия» в ФМ очень помогают, ведь 10 раз нажатые F3-вниз заменили 10 набранных в консоли less-ов.

В виндовсе его тоже нет. Есть меню проводника, которое никак не связано с меню ворда, фотошопа или винампа.

Тем не менее Shell Extension даётся как API, которое может быть использовано любыми виндопрограммами (такими как TC и даже Far, несмотря на его консольность — используется). Это достоинство, несмотря на мою неприязнь к проводнику как таковому. В линуксе есть штучки типа xdg*, но то ли они хуже проработаны, чем в винде, то ли прикладные программы не полностью используют их возможности.

Double Commander — это клон Windows Commander-а (aka Total Commander)

Кстати, что характерно, «оригинал» тоже написан на паскале. Это, конечно, совпадение, но совпадение забавное.

Это про Seksi Commander или про Windows Commander?

Давайте перечислим хорошие файл менеджеры!

MC хватит всем. Те, кто на него бочку катит, просто позеры или не распробовали как следует. Графические в линуксе к сожалению все убоги, а дельфин тянет кде.

Кстати, что характерно, «оригинал» тоже написан на паскале. Это, конечно, совпадение, но совпадение забавное.

Мне казалось, что это не совпадение и что разрабы сознательно выбрали паскаль потому, что Total на нем написан. Но это такое, фантомное ощущение, последний раз я их форум читал очень давно.

640кб тоже.

Я про Windows Commander (который ныне TC).

Про Seksi Commander раньше даже не слышал. Я правильно понял, что DC от него форкнули?

нажать F3, и через пару секунд увидеть весь файл, мгновенно скроллить его, делать по нему поиск и т.д.

Ога, файлик в н-цать Mb, что бы в нем по F3 поискать, не нулевая вероятность что и весь скачать придется, вот тут вы и залипните ожидая результата. Если вам понадобиться контекстный поиск но n-цати таким файликам, вешайтесь ожидая пока они загрузятся. А если канал не стабильный (разрывается), то можете и не дождаться.

Каждый PageUp/PageDown в less ждём пару секунд

Вы опять рассуждаете формулировками fm, типа если мне нужно посмотреть файлик «я буду долго гнать велосипед жать F3,вниз...» вместо использования grep,sed, &etc
Да и если говорить про less то только pgDown, для pgUp есть scrollback

То же и с редактированием — задержка будет только в момент сохранения, а всё остальное — мгновенно.

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

Итого: даже если согласиться с тем, что ваш вариант лучший в части F3, F4, то получаеться это единственные действия которые можно выполнить в фм по вашей схеме, ну хорошо еще удаление добавим. Никаких копирований, архивирований, &etc ибо все эти действия будут перегонять файлики через вашу локальную машинку. Ну и про выполнение команд тоже можно забыть.

Но пример хороший, напомнило мне о похожем случае: нужно найти в логах, какое событие могло вызвать подвисание программы. Известно примерное время подвисания, но не известно, какое это событие, и даже не известно, в каком из сотни логов искать. В mc заходим в каталог с логами, рекурсивный поиск, регуляркой захватываем плюс-минус час от известного времени, запускаем поиск...

Регулярку вы уже написали, в чем разница с grep ?

Как только нашло первый файл, жмём на нём F3 (он сразу откроет файл на найденной строке, это не прерывает поиск)

Так же в чем разница с греп? Нашли нужное, выхлопнули в консоль, поиск не прерываем. И точно так же

листаем, читаем, прикидываем в чём может быть дело

и даже F3 не надо нажимать.

не отвлекаясь ни на man, ни на выдумывание как соединить find и grep, а вывод передать в less, как переключаться между файлами, и т.д.

Ну и зачем в вашем примере find, less и чтение man-а ?

И имена найденных файлов мышой тоже копировать не пришлось (кто действительно юзает консоль — знает как часто приходится это делать)
(кто действительно юзает консоль — знает как часто приходится это делать)

Я видимо что-то делаю не так.

А что лучше - Dolphin или Double Commander? И зачем может понадобиться ставить DC?

Ога, файлик в н-цать Mb, что бы в нем по F3 поискать, не нулевая вероятность что и весь скачать придется, вот тут вы и залипните ожидая результата. Если вам понадобиться контекстный поиск но n-цати таким файликам, вешайтесь ожидая пока они загрузятся.

Зависит от обстоятельств. Иногда скачать и смотреть локально действительно быстрее, чем по несколько секунд ждать поиска. Но файлы, которые надо редактировать, редко бывают большими.

А рекурсивный контекстный поиск, безусловно, будет работать медленнее. Увы, ФМ упрощает не все задачи в мире. Многие, но не все.

А если канал не стабильный (разрывается), то можете и не дождаться.

Если канал разрывается, то я и в консоли вывода не дождусь.

Вы опять рассуждаете формулировками fm, типа если мне нужно посмотреть файлик «я буду долго гнать велосипед жать F3,вниз...» вместо использования grep,sed, &etc

«если мне нужно посмотреть файлик» же! grep/sed не помогут прочитать файл.

Да и если говорить про less то только pgDown, для pgUp есть scrollback

Не только. Если мы прыгнули End-ом в конец файла или использовали контекстный поиск, то PageUp тоже пригодится.

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

Ну да. Одна задержка при открытии, и задержка при сохранении, остальное быстро.

даже если согласиться с тем, что ваш вариант лучший в части F3, F4, то получаеться это единственные действия которые можно выполнить в фм по вашей схеме, ну хорошо еще удаление добавим.

Ещё создание каталогов, переименование/перемещение, но, в целом, да.

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

Да, и, по-моему, это — недоработка. Я понимаю, почему ftp не позволяет выполнять команды, но ssh вполне мог бы это позволять.

Регулярку вы уже написали, в чем разница с grep ?

Я не знаю, что я ищу. Искомое событие было до этого момента, и я не знаю за сколько строк до. Мне нужно найти нужный момент, и от него смотреть вверх, пока я что-то не замечу.

Ну и зачем в вашем примере find, less и чтение man-а ?

find — чтобы найти все файлы по маске, вроде *-201902*.log, grep — чтобы в найденных результатах искать регулярку, less — чтобы открыать каждый из найденных файлов, снова искать ту регулярку (ведь less не умеет открывать на строке, которую нашёл grep), и от неё листать вверх в поисках чего-то подозрительного. man — на случай если я не помню, как запустить grep из find-а.