Скрипты, которые парсят вывод ls, должны быть сломаны (а их авторы — умерщвлены посредством медленного потрошения).

Как же всё-таки полезно читать оригиналы вместо низкокачественных переводов на ЛОРе:

«ls now quotes file names unambiguously and appropriate for use in a shell, when outputting to a terminal».

Единственное, где может сломаться «совместимость», так это в голове у пользователя и у тех двух костыляторов, которые зачем-то парсят терминальный вывод ls.

Эти скрипты не сломаются. stdout != tty.

А, там детект tty. Жаль.

Когда хейтят Unixway логичнее всего думать, что хейтят виндузятники.

полезно читать оригиналы

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

Я хейчу костылирование в режиме «тяп-ляп лишь бы заработало». Если ты называешь это словом unixway, то у меня для тебя плохие новости.

Я говорю про перенаправление вывода одной программы на ввод другой. Вот это Unixway. И тут уже не важно какие это программы. Даже если первой является ls. А вывод ls может обрабатываться по-разному. Например, так:

$vxtst = `ls *\.v???\.* 2>/dev/null | wc -l`;

$strtv = `ls | sed 's/^.*\\.v//;s/\\..*\$//' | head -n 1`;

djvm -c $2 `ls $1/*.djvu`

В дополнение к команде base64 была добавлена команда base32

Ну прямо невероятно нужная и полезная фича. И как мы без этого жили?

почему?

Чайник Рассела, вот апелляция к возрасту это стыдоба.

А я говорю про использование подходящих инструментов для задачи и про неиспользование в скриптах утилит с нестабильным человекочитаемым выводом.

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf "%s\n" *?

Потому что ls — это утилита с человекочитаемым выводом, который никто не обещал не изменять.

Потому что делать ls <pattern> примерно настолько же избыточно, как и засовывать котов в трубу, т. к. тебе нужно не вывести информацию о файлах, а тупо напечатать аргументы, разделяя их переводами строк. Для этого есть printf(1).

Да он дурной, не обрашай внимания.

Как у тебя бомбит-то. Лёд приложи, полегчает. Или к врачу сходи.

Как скажешь, фантик

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf «%s\n» *?

Шелл есть не всегда. Иногда есть причины в программе на C использовать команды такого рода вместо системных вызовов.

И оправдание «никто не обещал» не применимо к данному случаю: и без всяких обещаний было понятно, что без особых причин вывод ls менять никто не будет — в конце концов даже для людей, не для скриптов, тех кто просто пользовался командой ls день ото дня, не особо приятно любое беспричинное измение её поведения, ибо оно логично требует признания, что до этого вывод ls был неидеален, с чем уважающий себя пользователь Линукса не согласится.

Зачем в этих примерах тяжеловесный ls

Не так уж он и тяжеловесный. Потеря каких-нибудь 0.003s слабо отражается на производительности. И если уж экономить на таких спичках, то только после выпиливания более тяжеловесных монстров: графических браузеров с JavaScript'ом, офисных пакетов, Java,... и т.д. На них явно теряется на порядки больше системных ресурсов и времени.

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf «%s\n» *?

Шелл есть не всегда. Иногда есть причины в программе на C использовать команды такого рода вместо системных вызовов.

Ты сам-то понял, что сказал? :]

• я говорю про printf(1), а не про printf(3)
• даже printf(3) всё равно не системный вызов
• речь вообще не про Си
• покажи мне систему, в которой нет шелла и нет /bin/printf, но есть /bin/ls
• я изначально говорил про шелл-скрипты, с какой радости ты начал рассматривать системы, в которых нет шелла?

Откуда у вас всех привычка приводить совершенно нерелевантные сравнения тёплого с мягким и выдавать их за аргументы?

Потеря каких-нибудь 0.003s слабо отражается на производительности.

Ага, а если в цикле?

И если уж экономить на таких спичках, то только после выпиливания более тяжеловесных монстров <...> На них явно теряется на порядки больше системных ресурсов и времени.

Логическая ошибка класса «а у вас негров линчуют». Торможение шелл-скрипта, в котором в цикле вызывается ls вместо printf, никак не связано с торможением «тяжеловесных монстров», которых вообще в системе может не быть.

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

Ты говорил про парсинг вывода ls и что его можно заменить на printf «%s\n» *. Это неверно, потому что парсить вывод ls надо нетолько в скриптах, но и, например, в программе на C. Но в программе на C нет printf «%s\n» *. Ну то есть конечно можешь вызвать «sh -c printf «%s\n» *» вместо «ls», но это ещё больший костыль, чем парсинг ls.

Ага, а если в цикле?

А если нет? ls в цикле - частный случай. А Вы рубите с плеча глобально. Мол, прописал ls в скрипт или софтину - пройди на потрошение за костыль. Даже если цикл никто и не собирался прикручивать.

Представь себе — чтобы вызвать из программы на Си /bin/ls с паттерном, всё равно нужно воспользоваться шеллом, потому что сам по себе ls не умеет раскрывать звёздочки :]

Это уже не говоря о том, что _в программе на Си_ нужно использовать glob(3) и readdir(3), а за костылирование с консольными утилитами — отрывать руки.

до появления книгопечатания(Гутенберг это вот всё) - каждым переписчиком

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

большинство же проекций Библии в реальный мир обязаны быть дефектными.

ну а уж если копать в сторону источника Q https://en.wikipedia.org/wiki/Q_source . . .

ps. вообще познавательно для ознакомления книги пророков (где каждая 3-4 странички)

для полноценного экранирования вот что придуманно одним из отцов-основателей https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

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

А есть уже патч к coreutils, который отключает эту поттерингщину?

Есть - GNU Coreutils 8.25 (комментарий)

поттерингщину

Это POSIX, раньше только не по умолчанию было.

Если уж Вы такой специалист по выпиливанию костылей, то может тогда подскажете как убрать костыли отсюда?

FLZLST=`tar tvf $1 | awk '{ print $6 }'`
# pointer to filenames array
CUR_PTR=0
MAX_PTR=`echo "$FLZLST" | wc -l`
# filling array
for fileindx in `seq 1 $MAX_PTR` ; do
        filename[$((fileindx - 1))]=`echo "$FLZLST" | head -n $fileindx | tail -n 1`
done

Работает, только пришлось подправить чуток пару строк:

$ head -n2 /etc/portage/patches/sys-apps/coreutils/coreutils_8.25_ls_literal.patch 
--- src/ls_orig.c   2016-01-14 15:16:23.000000000 +0300
+++ src/ls.c        2016-01-22 01:08:01.174295814 +0300

http://harmful.cat-v.org/cat-v/

до появления книгопечатания(Гутенберг это вот всё) - каждым переписчиком

Я читал, что ошибки вычитывали и неправильные копии уничтожали. В любом случае вбрасывать, что Библия прям _переписывалась_ несколько раз слишком толсто.

источника Q

Был источник Q, или не было источника Q, это не аргумент, что Библия переписывалась.

dd с опцией "--human-readable" преобразует информацию о размере в читаемый формат

Ура!

Половина самописных скриптов, где своя реализация экранирования, сломается тут же на месте.

Зачем тебе ls в скриптах?

Какая макака под кислотой это писала?

readarray -t filename < <(tar -tf "$1")

Не? Вариант с именованными каналами вместо process substitution (для грёбаных микроволновок) тоже возможен.

Спасибо, работает. Про

MAX_PTR=${#filename[@]}

считаю полезным ознакомление с:

1. https://vk.com/doc-32395542_380013642

2.https://psoberoi.github.io/stepanov-civilization/canon.html

ps. ну и Септугианта и Библия Джона ну и наш(РИ) 1868? перевод несколько не идентичные тексты - ибо при переводе всегда дрейфует семантика - и даже сам язык в отличии от текста плывёт со временем.

ps. вообще познавательно для ознакомления книги пророков (где каждая 3-4 странички)

Здравствуйте!

Воспитать человека интеллектуально, не воспитав его нравственно, - значит вырастить угрозу для общества. Рузвельт.

Представь себе — чтобы вызвать из программы на Си /bin/ls с паттерном

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

Это уже не говоря о том, что _в программе на Си_ нужно использовать glob(3) и readdir(3)

Обычно да, но ситуации бывают разные

а за костылирование с консольными утилитами — отрывать руки

Ты слишком зациклен на своей ненависти к «костылированию». Тру-юниксоид должен относиться к костылям с больших уважением. Вся UNIX и всё что из неё растёт есть собрание костылей бай-дизайн.

Нет, я всё равно не понимаю, зачем в программе на Си нужно вызывать ls (с любыми аргументами) и парсить его вывод.

Ок, я могу представить себе ситуацию, в которой нужно быстро и не заморачиваясь обойти какую-либо директорию. Но для таких целей существует find(1), который позволяет указать необходимый формат вывода с необходимыми разделителями.

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

Хоть я и не согласен с утверждением в рамках тривиальных однострочников типа:

 ls | grep -i "foobar" 

Спасибо.

в Юникс среда программирования Пайка+Кернигана отличная глава про пикл и банч.

Молодой монах принял постриг, и в монастыре первым его заданием было помогать остальным монахам переписывать от руки церковные уложения, псалмы и законы.
Поработав так неделю, монах обратил внимание, что все переписывают эти материалы с предыдущей копии, а не с оригинала. Удивившись этому, он обратился к отцу-настоятелю:
— Падре, ведь, если кто-то допустил ошибку в первой копии, она же будет повторяться вечно, и её никак не исправить, ибо не с чем сравнить!
— Сын мой, — ответил отец-настоятель, — вообще-то мы так делали столетиями. Но, в принципе, в твоих рассуждениях что-то есть!
И с этими словами он спустился в подземелья, где в огромных сундуках хранились первоисточники, столетиями же не открывавшиеся. И пропал.
Когда прошли почти сутки со времени его исчезновения, обеспокоенный монах спустился в те же подвалы на поиски святого отца. Он нашёл его сразу. Тот сидел перед громадным раскрытым томом из телячьей кожи, бился головой об острые камни подземелья и что-то нечленораздельно мычал. По покрытому грязью и ссадинами лицу его текла кровь, волосы спутались, и взгляд был безумным.
— Что с вами, святой отец? — вскричал потрясённый юноша. — Что случилось?
— Celebrate, — простонал отец-настоятель, — слово было: «celebrate» а не «celibate»!

ps: celebrate — праздновать, радоваться;
celibate — воздерживаться .

zero помоему надежнее

ls | tr '\n' '\0' | xargs -0 ...

The Hebrew Bible and the Greek New Testament were revised into their present forms by redactionists who may have shared very little with the original authors whom they were editing. Cervantes, with unsurpassed mirth, parodied unto death his chivalric forerunners, while we do not have the texts of Homer's precursors

Нормально. Скоро получим. :)

x86_64 Testing coreutils 8.25-1