Clifm 1.24

На самом деле, разумеется, проще вынуть из него карту памяти, но это слишком легко.

Ну-ну... А если она припаяна? Вот у меня в самсунге терабайт на борту. И как вынуть?

Не, на это мы пойти не могём! Аптека за углом.

Спасибо погромистам за развлекуху! А можно, я этим говном не буду пользоваться, у меня есть MC?

Никто не сомневается в том, что вы умеете работать в шелле, здесь неумеющих наверное мало. Но хочу вам посоветовать не делать этого из-за возможных и обидных ошибок. Если вы с таким не сталкивались, то это дело времени. Человек не может быть постоянно полностью сосредоточенным, что-то отвлекло, задумался, показалось (и такое бывает) – ввел, нажал и через мгновение себя ругаешь.

Аргумент хороший, но я с шеллом работаю сколько себя помню и норм.

но я с шеллом работаю сколько себя помню и норм

Это ваше дело, со мной такой казус случался. Просто не посмотрел где я нахожусь (в pushd-стеке) и вместо одного каталога удалил 20, хорошо, что была резервная копия всего

это скорее эмулятор терминала уже

Класс, до этого поста я считал что TUI и CLI являюстя 100% синонимами. Хотя явно различие между типами REPL и ТекстовоОконных программ прослеживалось.

Почитал про CliFМ, потом еще статей, существует недвумсмысленная формализация. TUI содржит элементы пользовательского интерфейса (окна, кнопки) реализованые псевдографикой, и подразумевает работу с мышкой.

Что не удивительно.

• CLI - Command Line основан на вводе команды.
• TUI - как и GUI только управляющие элементы через текст.

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

В жизни я это, конечно, использовать не буду, но как концепцию потыкать можно.

P.S. Собственно, CLI-based FM у нас уже есть, называется shell+coreutils, хотя по мелочи туда есть, конечно, что добавить. Поэтому да, прикладной смысл сабжа от меня немного ускользает.

P.P.S. Хотя впрочем, одна польза от проекта уже есть – просветительская: часть комментаторов открыла для себя разницу между CLI и TUI. Это уже что-то.

В Vi нет встроенного файлового менежера. Это просто редактор, там чуть ли подсветски синтаксиса нет. В Vim есть.

Сейчас под псевдонимом Vi в системах стоит Vim, Vi и Vim стали синонимами.

Не, я не издеваюсь, юзкейс этих текстовых файловых менеджеров какой? В чем профит? Может я чего не понимаю?

CliFM это DSL для манипулирования файлайми. Аналогичный мини-языку Vim для работы с текстом.

СliFM:

• diff 5 6
• =x<TAB>
• @gzip<TAB>
• ...

Vim: Vim как командный язык.

В нормальном режиме Vim представляет собой мощный командный язык для текстовых преобразований:

• d - удалить
• y - скопировать
• p - вставить
• 2w - переместиться на два слова вперёд
• ci( - изменить содержимое внутри скобок

Собственно, CLI-based FM у нас уже есть, называется shell+coreutils, хотя по мелочи туда есть, конечно, что добавить.

Пикантность ситуации в том, что с 1980 года уже гарантированно все есть.

Vi+Awk+Sed+Sh+C

В теории:

Все можно реализовать. Alias не нужны, в PATH добавляется ~/bin каталог куда складываются исполняемые скрипты.

Perl «не нужен», его можно заменить связкой Awk+Sed+Sh.

Двигаемся дальше, что-то важное, а! Vim «не нужен», можно ползоваться Vi и выходить в CLI через Ctrl+Z, и манипулировать с несколькими экземплярами через fg.

На практике:

Создаются новые инструменты, новые DSL, которые ускоряют работу. Nushell как пример.

Во время написаня вам коммента, и распрашивая https://chat.qwen.ai/ про «мини-языки» у меня произошло открытие.

Давно работаю с Vim, в курсе ciw, cid комманд для редактирования слова или его удаления когда находишся в середите этого слова.

Но сегодня болтая на LOR я откыл для себя целый пул комманд ci. А именно: ci(, ci{, ci<, ci", ci'.

Можно менять данные внтури содержимого, находясь на открывающей или закрывающей скобке. Можно писать ci), ci}, ci> можно ci(, ci{, ci< - разницы нет.

<one>
{two}
(three)
#four# - не работает
%five% - не работает
"six"
'seven'


<yes>
{yes}
(yes)
"yes"
'yes'

Это Вы все к чему? Шелл — тоже язык. Мы вообще выражаем свои мысли на каких-то языках. Применять мне этот язык зачем?

По-моему, известный «The UNIX-HATERS Handbook» советовал ввести в vi свое имя в качестве команды и посмотреть, что будет. :) А может быть, эта шутка откуда-то еще....

Я помню два случая, как я шеллом повредил систему.

Один раз я удалил $home, было это примерно 10 лет назад. Я тогда впервые работал с мейкфайлами и делал секцию «clean». В принципе, так все делают и вероятность накосячить у всех примерно одинакова, поэтому тут намного полезнее иметь регулярные бекапы, хотя это не всегда возможно.

Второй раз был недавно, решил я редактировать множество файлов одновременно с помощью sed. Ну и удалил всё содержимое этих файлов, лол. Там было около 30 скриптов для подключения к бд, которые были созданы в полуручном режиме. Бэкапов не было, поэтому пришлось заново их создавать. Тут виноваты обе стороны: я, не прочитавший ман, и интерфейс sed (флаг -n), имеющий смысл в своей доменной области, но который позволяет легко выстрелить себе в ногу, потому что любой человек всё-таки ожидает применять операцию уничтожения выборочно, а не по умолчанию. Это был эксперимент, так что не обидно, но после этого я массовые изменения буду делать только в текстовом редакторе, где есть Undo (кстати, можно даже тем же sed’ом, только через стандартные потоки и буферы редактора, а не напрямую на файлах).

Удивлен, что никто еще yazi не упомянул, который вроде как компромисс между шеллом и mc. И от стрелочек там ушли, и в терминале типа ghostty даже картинки и pdf можно превьюить.

Сочувствую Вашему горю. Но это хороший пример того, как делать не надо.

Я тогда впервые работал с мейкфайлами и делал секцию «clean».

Унеcти $HOME make clean'om — это почти патч Бармина! У меня бы не получилось, даже с первого раза!

и интерфейс sed (флаг -n),

Так sed изначально потоковый. Вход передает на выход. Отладься в потоке, а потом будешь редактировать inplace.

массовые изменения буду делать только в текстовом редакторе, где есть Undo

Удачи тебе заменить кодировку руками в двадцати XML-файлах.

Обсуждали уже это поделие недавно. Тоже не нужно :)

Удачи тебе заменить кодировку руками в двадцати XML-файлах.

Если можешь предоставить файлы, измерим удачу (посмотрю как быстро это получится).

Edit: хотя достаточно описания проблемы с кодировкой

Ну я sed’ом и grep’ом почти не пользуюсь, только в скриптах, когда важна их posix-нативность (я бы так сказал про скрипты). В основном же (99%), в юзерспейсе, встроенными средствами pwsh (не логин-шелл, просто инструмент), там regex привычней, он заменяет и остальные утилиты из для работы с текстом и форматами, в основном это json, xml, csv, toml, yaml и ini, т.е. то с чем я сталкиваюсь в домашних условиях.

Да не важно какие файлы. Надо сделать 20-30-50 однотипных действий над файлами разного размера. Заменить в XML utf-16 на utf-8 и перекодировать iconv'ом — это частный пример. Чаще приходится вон книжки в fb2 перекодировать из win1251 и переименовывать в соответствии с title.

yazi

И от стрелочек там ушли

Никуда там от стрелочек не ушли.

yazi — это скорее аналог ranger или nnn, нежели компромисс между шеллом и двухпанельным ФМ. Обычный не двухпанельных ФМ.

Под виндой да, что там есть еще кроме pwsh? А юниксах — извините. Ни капли свой земли врагам не уступим! :)

Синтаксис у него — застрелиться! Уж лучше Tcl какой... :)

Погоди, он же на Шарпе написан! Это мне на на юникс все это говно микрософтовское системы дотнет тащить? Не, не уговорите!

Под виндой да

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

Ну а синтансикс… За 20 лет использования, еще с первой версии под ХР, я уже обустроился, это и псевдонимы и функции, в интерактивном режиме не длиннее bash-пайпов, но ООП, все объект.

Если посмотреть на Windows PowerShell (5.1), которая больше не будет развиваться и получать обновления, и это точно, то PowerShell 7+, которая на .Net, а не на Net.Framework, это два разных продукта, хоть и похожих. Обратная совместимость ускользает, как только начинаешь применять новые типы, методы и операторы. Даже базовые синтаксические конструкции притерпели значительные изменения.

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

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

Отладься в потоке, а потом будешь редактировать inplace.

Я вспомнил как всё было.

Если сразу работать с ~20 файлами, то отладиться в потоке не получится. Нужно смотреть как работает поиск на каждом файле. Так и получилось, что я написал сперва sed '/^PGPASS/ p' bin/*. А он же по умолчанию все строки печатает. Ну значит надо добавить -n.

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

Времени на этот вопрос не было, потому что работающий поиск занял всё пространство в глазах и голове. Хорошо, теперь пишем замену: sed -n '/^PGPASS/ s/old/new/' bin/*. На данный момент стандартный вывод этой команды даст пустоту. Ну и настало время сделать in-place: sed -n -i '' '/^PGPASS/ s/old/new/' bin/*. Всё, файлы очищены. А нужно было убрать -n.

Сложно сказать, какой из этого можно вынести урок, кроме того что это плохой UI. Кажется, что in-place замена и использование stdout в процессе для отладки - просто конфликтующие задачи и нужно вместо stdout использовать что-то более близкое к in-place (например, буферы текстового редактора).

все это говно микрософтовское системы дотнет тащить?

Нет, но можно, обычный дистрибутив уже собран, дотнет внутри, а не снаружи. А уж тащить или нет, это вам решать. Есть отдельно dotnet, как среда разработки и выполнения, в pwsh только второе, хотя можно вставлять блоки кода C# и F# (под винду что-то еще из этого семейства).

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

Я не против

for f in (f1,f2,f3) ; do sed "s/^PGPASS/ p' bin/g" $f > $f.out  ; done

Смотришь в f*.out

Применять мне этот язык зачем?

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

И уже субъективная оценка: кому-то нравится один язык, кому-то другой. CliFM, как мини-командный язык, имеет все предпосылки, чтобы кому-то понравиться. Как сейчас модно говорить «зайти».

Вероятно кому-то зайдет. Пока это единственное объяснение для существования данной утилиты. Внятных юзкейсов так никто и не рассказал.

Внятных юзкейсов так никто и не рассказал.

Еще один файловый мендежер. Есть mc, lf, ranger, thunar и clifm.