Почему *не* анализируют 'ls' (и что сделать вместо этого)?

Ваша проблема состоит в том, что Вы берете оболочку для того, каково это не: язык программирования. Оболочка перед всем интерпретатор командной строки. Сценарии оболочки являются сценариями. Это Вы реализуете логику, алгоритм Вашей проблемы в синтаксисе оболочки, затем Вы идете по неправильной дороге.

Существуют очевидные проблемы в Вашем коде как неупомянутые переменные. Но в целом, это просто чувствует себя ужасным для выполнения такого количества команд (поскольку оболочка является инструментом к командам выполнения, не языки программирования) только для нахождения пропорции символов кроме A и T в файле.

Кроме того, awk использует числа плавающие на 64 бита внутренне. Вы уверены, что Вам нужно больше точности, чем это. Если те числа должны использоваться чем-то, что имеет больше точности, чем которая, разве Вы не можете использовать это что-то, чтобы сделать все это?

Для ответа на вопрос Вы сделали бы:

$ echo 1 3 | awk -vRS= '{("echo scale=300\\;" $1 "/" $2 "|bc -l") | getline; print}'
.3333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333333333333333333333333333333333333333333\
33333333333333333333333333333

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

Немного менее глупое для приближения к нему, если бы Вы все еще хотите использовать awk, было бы:

echo 1 3 | awk 'BEGIN{print "scale=300"}{print $1"/"$2}' | bc

То время, только один awk и один bc команда.

Для меня довольно очевидно, что Вам нужен реальный язык программирования здесь (жемчуг, рубин, Python приходят на ум). Можно назвать интерпретатор для того языка программирования из сценария оболочки, но только однажды: всего одного вызова должно быть достаточно, чтобы сделать все это.

213
05.08.2019, 13:13
8 ответов
[1111941] Я в этом совсем не уверен, но давайте предположим, что вы [1112284] могли бы [1112285], если вы готовы приложить достаточно усилий, надежно разобрать вывод [1112286]ls[1112287] даже перед лицом "противника" - кого-то, кто знает написанный вами код и сознательно выбирает имена файлов, предназначенных для его взлома.

Даже если бы вы могли это сделать, [1112288] все равно было бы плохой идеей [1112289].

Bourne shell не является хорошим языком. Его не следует использовать для чего-либо сложного, если только экстремальная переносимость не важнее любого другого фактора (например, [1112645]autoconf[1112646]).

Я утверждаю, что если вы сталкиваетесь с проблемой, когда парсинг вывода [1112292]ls[1112293] кажется пути наименьшего сопротивления для скрипта shell, это убедительно говорит о том, что что бы вы ни делали, это [1112294] слишком сложно для shell[1112295], и вы должны переписать все это на Perl или на Python. Вот ваша последняя программа на Python:

В ней нет никаких проблем с необычными символами в именах файлов -- вывод [1112296]output[1112297] неоднозначен точно так же, как и вывод [1112298]ls[1112299] неоднозначен, но в "реальной" программе это не имеет значения (в отличие от демо-версии, подобной этой), который будет использовать результат [1112300]os.path.join(subdir, f)[1112301] напрямую.

  1. Не менее важно, и в разительном контрасте с тем, что вы написали, это все равно будет иметь смысл через шесть месяцев, и будет легко модифицироваться, когда вам понадобится, чтобы сделать что-нибудь слегка другое. В качестве иллюстрации предположим, что вы обнаружили необходимость исключить точечные файлы и бэкапы редакторов, и обрабатывать все в алфавитном порядке по имени basename:
191
27.01.2020, 19:28
[1120439]На эту ссылку много ссылок, потому что информация полностью точна, и она там уже очень долгое время.[12218]ls[1121077] заменяет непечатаемые символы на символы глобуса да, но этих символов нет в реальном имени файла. Почему это имеет значение? 2 причины:[12219]Если вы передаете это имя файла программе, то этого имени файла на самом деле не существует. Чтобы получить реальное имя файла, нужно расширить глобус.[12220]Глобус файла может соответствовать более чем одному файлу.[12221]Например:[12222]Обратите внимание, что у нас есть 2 файла, которые выглядят точно так же. Как вы собираетесь их различать, если они оба представлены как [1121082]a?b[1121083]?[12223]Автор называет это искажением имён файлов, когда ls возвращает список имён файлов, содержащих shell globs, а затем рекомендует использовать shell glob для получения списка файлов![12224]Здесь есть разница. Когда вы получаете глобус обратно, как показано на рисунке, этот глобус может соответствовать более чем одному файлу. Однако, когда вы выполняете итерацию по результатам, совпадающим с глобусом, вы получаете обратно точный файл, а не глобус.[12225]Например:[12226]Заметьте, как вывод [1121086]xxd[1121087] показывает, что [1121088]$file[1121089] содержал необработанные символы [1121090]\t[1121091] и [1121092]\n[1121093], а не [1121094]? [1121095]. [12227] Если вы используете [1121096]ls[1121097], то вместо этого вы получаете следующее:[12228] "Я все равно собираюсь выполнить итерацию, почему бы не использовать [1121098]ls[1121099]?"[12229] Ваш пример, который вы дали, на самом деле не работает. Похоже, что он работает, но это не так.[12230]Я имею в виду следующее:[12231]Я создал каталог с кучей имён файлов:[12232]Когда я запускаю ваш код, я получаю следующее:[12233]Куда делись остальные файлы?[12234]Давайте попробуем вместо этого:[12235]Теперь давайте используем реальный глобус:[12236]С bash[12237]Вышеприведенный пример был с моей обычной оболочкой, zsh. Когда я повторяю процедуру с bash, я получаю другой совершенно другой набор результатов с вашим примером:[12238]Тот же набор файлов:[12239]Радикально отличающийся набор результатов с вашим кодом:[12240]С оболочкой glob он работает отлично:[12241]Причина, по которой bash ведет себя таким образом, восходит к одному из пунктов, которые я сделал в начале ответа: "Глобус файла может совпадать с несколькими файлами".[12242]ls[1121101] возвращает один и тот же глобус ([1121102]a?b[1121103]) для нескольких файлов, поэтому каждый раз, когда мы расширяем этот глобус, мы получаем каждый файл, который с ним совпадает.[12243]Как воссоздать список файлов, которые я использовал:[12244]Шестнадцатиричный код из них - это символы UTF-8 NBSP.[1120496]
184
27.01.2020, 19:28
[1120503] Давайте попробуем немного упростить: [12247] Видите? Это уже неправильно. Есть 3 файла, но Бэш сообщает 4. Это потому, что набор [1121110]set[1121111] получает глобусы, генерируемые [1121112]ls[1121113], которые расширяются оболочкой перед передачей в набор [1121114]set[1121115]. Поэтому вы получаете:[12248]или, если хотите:[12249]Вышеуказанное было запущено на [1121116]bash 4.2.45[1121117]. [1120510]
54
27.01.2020, 19:28
[1128927] Возможно ли в некоторых случаях разобрать выходные данные [1129478]ls [1129479]? Конечно, идея извлечения списка номеров inode из каталога является хорошим примером - если вы знаете, что ваша реализация [1129480]ls[1129481] поддерживает [1129482]-q[1129483], и поэтому каждый файл будет выдавать ровно одну строку вывода, и все, что вам нужно - это номера inode, разобрать их из вывода [1129484]ls -Rai1q[1129485] - это, конечно же, возможное решение. Конечно, если бы автор раньше не видел совета типа "Никогда не разбирать вывод ls", он, наверное, не стал бы думать об именах файлов с новыми строками в них, и, наверное, оставил бы в результате "q", и код в этом краевом случае был бы слегка разбит - так что даже в тех случаях, когда анализ вывода [1129486]ls[1129487] целесообразен, этот совет все равно будет полезен. [12140] Более широкий смысл заключается в том, что когда новичок в скриптинге shell пытается выяснить (например) какой самый большой файл в каталоге, или какой самый последний измененный файл в каталоге, его первый инстинкт - разобрать вывод [1129488]ls[1129489] - понятен, потому что [1129490]ls[1129491] - это одна из первых команд, которые узнает новичок.[12141] К сожалению, этот инстинкт неверен, и этот подход нарушен. Более того, к сожалению, он слегка нарушен - в большинстве случаев он будет работать, но не работает в крайних случаях, которые, возможно, могут быть использованы кем-то, кто знает код.[12142]Новичок может подумать о [1129492]ls -s -s | sort -n | tail -n 1 | awk '{print $2}'[1129493], как о способе получить самый большой файл в каталоге. И это работает, пока у вас нет файла с пробелом в имени.[12143]OK, так как насчет [1129494]ls -s | сортировать -n | tail -n 1 | sed 's/[^ ]* *[0-9]* *//'[1129495]? Работает нормально до тех пор, пока у вас не появится файл с новой строкой в имени.[12144]Помогает ли добавление [1129496]-q[1129497] в аргументы [1129498]ls[1129499] при появлении новой строки в имени файла? Это может выглядеть так, пока у вас не будет 2 разных файла, которые содержат непечатаемый символ в одном и том же месте имени файла, и тогда вывод [1129500]ls[1129501] не позволит вам различить, какой из них был самым большим. Хуже того, для расширения "?" он, вероятно, прибегнет к shell'у [1129502]eval[1129503] - что вызовет проблемы, если он попадет в файл с именем, например, [12145] помогает ли [1129504]--quoting-style=shell[1129505] (если ваш [1129506]ls[1129507] даже поддерживает его)? Нет, до сих пор отображаются ? для непечатаемых символов, так что до сих пор непонятно, какое из множества совпадений было самым большим. [1129508]--quoting-style=literal[1129509]? Нет, то же самое. [1129510]--quoting-style=locale[1129511] или [1129512]--quoting-style=c[1129513] может помочь, если вам нужно просто однозначно распечатать имя самого большого файла, но, вероятно, нет, если после этого вам нужно что-то сделать с этим файлом - это была бы куча кода, чтобы отменить кавычки и вернуться к реальному имени файла, чтобы можно было передать его, скажем, gzip.[12146]И в конце всей этой работы, даже если то, что у него есть, безопасно и правильно для всех возможных имен файлов, это было бы нечитаемо и недоступно, и это можно было бы сделать гораздо проще, безопаснее и читабельно на питоне, перле или рубине. [12147] Или даже используя другие оболочковые инструменты - с верхушки моей головы, я думаю, что это должно сделать фокус: [12148] И должно быть по крайней мере таким же портативным, как [1129514] --quoting-стиль [1129515].[1128946]
16
27.01.2020, 19:28
[1113057] Причина, по которой люди говорят [1113406] никогда [1113407] не делать что-то, не обязательно, потому что это абсолютно позитивно не может быть сделано правильно. Мы можем сделать это, но это может быть сложнее, менее эффективно как в пространстве, так и во времени. Например, было бы прекрасно сказать: "Никогда не стройте большой бэкэнд электронной коммерции в x86 сборке"[12152]Так что теперь к рассматриваемому вопросу: Как вы показали, вы можете создать решение, которое разбирает ls и дает правильный результат - так что правильность не является проблемой.[12153]Разве это сложнее? Да, но это можно спрятать за вспомогательной функцией.[12154]Так что теперь к эффективности: [12155]Space-efficiency: Ваше решение опирается на [1113408]uniq[1113409] для отфильтровывания дубликатов, следовательно, мы не можем генерировать результаты лениво. Таким образом, либо [1113410]O(1) [1113411] против [1113412]O(n) [1113413], либо оба имеют [1113414]O(n) [1113415].[12156]Временная эффективность: В лучшем случае [1113416]uniq[1113417] использует хэшмап подход, поэтому мы все еще имеем [1113418]O(n)[1113419] алгоритм в количестве закупленных элементов [1113420]O(n)[1113421], вероятно, хотя это [1113422]O(n log n)[1113423]. [12157] Теперь реальная проблема: Хотя Ваш алгоритм все еще выглядит не так уж плохо, я был очень осторожен в использовании приобретенных элементов [1113424] [1113425], а не элементов для n. Потому что это действительно имеет большое значение. Скажем, у вас есть файл [1113426]\n\n[1113427], в результате чего получится глобус для [1113428]??[1113429], так что сопоставьте каждый 2-символьный файл в листинге. Забавно, если у вас есть другой файл [1113430] \n\r[1113431], который также приведет к [1113432]??[1113433], а также вернет все 2-символьные файлы... смотрите, к чему это приведет? Экспоненциальное, а не линейное поведение, безусловно, квалифицируется как "худшее поведение во время выполнения"... в этом разница между практическим алгоритмом и алгоритмом, о котором вы пишете статьи в теоретических журналах CS.[12158]Все ведь любят примеры, правда? Ну вот. Сделайте папку под названием "test" и используйте этот питоновый скрипт в той же директории, где находится папка.[12159]Единственное, что это сгенерирует все продукты длиной 3 на 7 символов. По школьной математике это должно быть 343 файла. Ну, это должно быть очень быстро для печати, так что давайте посмотрим:[12160]Теперь давайте попробуем ваше первое решение, потому что я действительно не могу заставить эту[12161]вещь здесь работать на Linux mint 16 (что, я думаю, говорит о многом для удобства использования этого метода). [12162]Как бы то ни было, так как вышеприведенный метод фильтрует результат только после его получения, более раннее решение должно быть, по крайней мере, таким же быстрым, как и более позднее (в этом случае нет никаких хитростей inode, но они ненадежны, так что вы бы отказались от корректности).[12163]Так сколько времени займет[12164]? Ну, я действительно не знаю, нужно время, чтобы проверить имена файлов 343^343 - я скажу вам после тепловой смерти Вселенной.[1113084]
32
27.01.2020, 19:28

Предисловие "Stated Intention Address"

#!/bin/sh
session=${1:-unnamed}
tmux new -d -s "$session" "bash"
tmux split -t "$session" -h "bash"
tmux select-pane -t "$session" -L
tmux split -t "$session" -v "irb"
tmux select-pane -t "$session" -U
tmux split -t "$session" -h "python"
tmux attach -t "$session"

и первоначальное обоснование ответа

†[1115810], обновленное в 2015-05-18

  • mikeserv (OP), указанное в последнем обновлении к его вопросу: [1115411] "Я действительно [1115812] считаю это позором[1115813], хотя я впервые [1115814] задал этот вопрос, чтобы указать на источник дезинформации, [1115815] и, к сожалению, самый возмущенный ответ здесь в значительной степени вводит в заблуждение."

    Ну, ладно; я чувствую, что было довольно стыдно, что я потратил столько времени, пытаясь понять, как объяснить мой смысл, только для того, чтобы найти [1115413], что [1115414], когда я перечитывал вопрос. В итоге этот вопрос оказался "[генерирует] обсуждение, а не ответы"[1115415]‡[1115416] и в итоге взвесил [1115417]~18K текста[1115418] (только для ясности), что было бы долго даже для записи в блоге.
  • Но StackExchange - это не твой мыльница, и это не твой блог. Тем не менее, на самом деле, вы использовали его, как минимум, как часть и того, и другого. В итоге люди тратили много времени, отвечая на Ваши "To-Point-Out", вместо того, чтобы отвечать на реальные вопросы людей. На данный момент я буду отмечать вопрос как не очень подходящий для нашего формата, учитывая, что в ОП четко сказано, что он вообще не был задуман как вопрос.

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

пожалуйста, простите за остающиеся неровные края; я уже потратил на это слишком много времени... вместо того, чтобы напрямую цитировать ОП (как это было изначально задумано), я попытаюсь подвести итог и перефразировать.[1115819][1115422][1114890] [1114891] [1115423] [1115820] [1115854] [в значительной степени переработанный по сравнению с моим первоначальным ответом]

после рассмотрения, я считаю, что неправильно понял акцент, сделанный в ОП на вопросах, на которые я ответил; однако, вопросы, затронутые в [1115856], были [1115857] подняты, и я оставил ответы в значительной степени нетронутыми, так как я считаю, что они должны были быть в деталях и касаться вопросов, которые, как я видел, поднимались в других контекстах, а также советов для начинающих.

В оригинальной заметке спрашивалось, почему в различных статьях давались советы, например, "Не разбирайте [1115428]ls[1115429] вывод" или "Никогда не разбирайте [1115430]ls[1115431] вывод" и так далее.

Мое предлагаемое решение вопроса заключается в том, что примеры такого рода утверждений являются просто примерами идиомы, сформулированной несколько иначе, в которой абсолютный квантификатор соотносится с императивом [например, не [никогда] Х", "[следует] всегда Y", "[следует] никогда не Z"], чтобы сформировать заявления, предназначенные для использования в качестве общих правил или руководящих принципов, особенно когда они даются новым субъектам, а не рассматриваются в качестве абсолютной истины, несмотря на очевидную [1115432] форму [1115433] этих заявлений".

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

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

И, таким образом, к рассматриваемой теме: на мой взгляд, только потому, что эксперт может нарушить это правило, не получая при этом полной отдачи, я не вижу никакого оправдания для того, чтобы сказать новичку, что "иногда" нормально разобрать вывод [1115434]ls[1115435], потому что: [12138] это не [12139]. Или, по крайней мере, конечно, это неправильно для новичка.[12140]Ты всегда кладешь пешки в центр; в открывающем одну шашку, один ход; замок при первой же возможности; рыцари перед епископами; рыцарь на ободке мрачный; и всегда следи за тем, чтобы твой расчет был виден до самого конца! (Упс, простите, устаю, это для шахматного стекаОбмена.)[12141]Правила, Значит быть разбитым? [12142]При прочтении статьи на тему, на которую нацелены или которую, скорее всего, прочтут новички, часто можно встретить такие вещи:[12143] "Вы не должны [1115828]никогда [1115829] делать X."[12144] "Никогда не делайте Q!"[12145] "Не делайте Z."[12146] "Нужно всегда делать Y! "[12147]"C, несмотря ни на что."[12148] Хотя эти утверждения, безусловно, кажутся констатирующими абсолютные и вечные правила, это не так; вместо этого это способ констатации общих правил [так же известный как "руководящие принципы", "эмпирические правила", "основы" и т.д.], который, по крайней мере, возможно, является одним из подходящих способов их изложения для новичков, которые могли бы читать эти статьи. Однако только потому, что они заявлены как абсолютные, эти правила, безусловно, не связывают профессионалов и экспертов [которые, вероятно, были теми, кто обобщал такие правила в первую очередь, как способ записи и передачи знаний, полученных в ходе работы над повторяющимися вопросами в их конкретном ремесле]. Эти правила, безусловно, не покажут, как эксперт будет решать сложную или нюансированную проблему, в которой, скажем, эти правила противоречат друг другу; или в которой опасения, приведшие к правилу, в первую очередь, просто не применяются. Эксперты не боятся (или не должны бояться!) просто нарушать правила, которые, как им случается, не имеют смысла в конкретной ситуации. В своем ремесле эксперты постоянно балансируют между различными рисками и проблемами, и часто вынуждены использовать свое суждение, чтобы сделать выбор в пользу нарушения такого рода правил, вынуждены балансировать между различными факторами и не могут просто полагаться на таблицу правил, которым нужно следовать. Возьмем [1115450]Гото [1115451] в качестве примера: по вопросу о том, являются ли они вредными, ведутся длительные, повторяющиеся дебаты. (Да, не используйте [1115452]когда-либо [1115453] gotos. ;D)[12150]A Modal Proposition[12151]Странная особенность, по крайней мере, на английском языке, и я представляю себе на многих других языках общие правила, заключается в том, что они излагаются в той же форме, что и модальное предложение, но при этом эксперты в той или иной области готовы дать общее правило для той или иной ситуации, зная при этом, что они нарушат это правило, когда это будет необходимо. Очевидно, поэтому эти утверждения не должны быть эквивалентны одним и тем же утверждениям в модальной логике.[12152]Поэтому я говорю, что они должны быть просто идиоматическими. Вместо того, чтобы действительно быть "никогда" или "всегда", эти правила обычно служат для кодификации общих указаний, которые, как правило, уместны в широком диапазоне ситуаций, и что, когда новички слепо следуют им, скорее всего, приведут к гораздо лучшим результатам, чем новички, решившие пойти против них без веских на то оснований. Иногда они кодифицируют правила, которые просто приводят к некачественным результатам, а не к откровенным неудачам, сопровождающим неправильный выбор, когда новичок идет против правил. [12153] Таким образом, общие правила не являются абсолютными модальными предложениями, которые кажутся на поверхности, а скорее являются коротким способом дать правило со стандартной шаблонностью, что-то вроде того, что подразумевается ниже: [12154]Если у вас нет возможности сказать, что это руководство неверно в конкретном случае, и доказать себе, что вы правы, тогда ${RULE}[12155]где, конечно, вы можете заменить "никогда не разбирать [1115456]ls[1115457] вывод" на ${RULE}. :)[12156]О да! Что за [1115858]О [1115859] Разбор [1115860]ls[1115861] вывод?[12157]Ну, так что, учитывая все это... я думаю, вполне понятно, что это правило хорошее. Прежде всего, настоящее правило следует понимать как идиоматическое, как объяснялось выше... [12158] Но более того, не просто нужно быть очень хорошим специалистом по скриптингу оболочки, чтобы знать, может ли оно быть нарушено, в каком-то конкретном случае. Также, это требует столько же навыков, чтобы сказать, что вы получили его [1115460] неправильно [1115461], когда вы пытаетесь его сломать при тестировании! И я уверенно говорю, что очень большая часть вероятной аудитории таких статей (дающих советы типа "Не разбирайте вывод [1115462]ls[1115463]!") [1115464] не может делать такие вещи [1115465], а те, у кого есть такой навык, скорее всего, поймут, что они разобрались с этим сами и все равно проигнорируют это правило. [12159] Но... просто посмотрите на этот вопрос, и как даже те, у кого, вероятно, есть такой навык, подумают, что это плохой знак; и сколько усилий автор вопроса потратил, только что добравшись до точки текущего лучшего примера! Я гарантирую вам, что 99% людей, которые там находятся, получат неправильный ответ, и с потенциально [1115466] очень [1115467] плохими результатами! Даже если метод, о котором принято решение, окажется хорошим, пока он (или другая) [1115468]ls[1115469] идея разбора не будет принята IT/разработчиками в целом, не выдержит много тестирования (особенно теста времени) и, в конце концов, не перейдет в статус "общей методики", скорее всего, многие люди могут попробовать его и ошибиться. ...с катастрофическими последствиями.[12160] Итак, повторю в последний раз...., что [1115470], особенно в данном случае[1115471], [1115472], что[1115473] именно поэтому "[1115474] никогда[1115475] не разбирает [1115476]ls[1115477] вывод!" - это, несомненно, [1115478] правильный[1115479] способ его выражения.[1114936]. [1114937][1115480][1115834][1115862][UPDATE 2014-05-18: разъяснено обоснование ответа (выше) на комментарий из ОП; следующее добавление в ответ на добавления ОП к вопросу со вчерашнего дня][1115863][1115835][1115481][1114938] [1114939] [1115482] [1115836] [UPDATE 2014-11-10: добавлены заголовки и реорганизовано/рефактурировано содержание; а также: переформатирование, перезапись, уточнение и гм... "лаконичный"... я намеревался просто очистить, хотя это и превратилось в небольшую переделку. я оставил его в печальном состоянии, поэтому в основном пытался придать ему какой-то порядок. я действительно считал важным в значительной степени оставить первый раздел нетронутым; поэтому там было только два незначительных изменения, излишнее "но" было удалено, а "это" подчеркнуто. ][12161]† Первоначально я предполагал, что это будет лишь уточнение моего оригинала; но в отношении других добавлений я принял решение после размышлений[12162]‡ см. [1115484]https://unix.stackexchange.com/tour[1115485] для руководящих принципов, касающихся должностей[1114944].
26
27.01.2020, 19:28
[119573]Вывод [1110056]ls -q[1110057] совсем не глобус. Он использует [1110058]?[1110059], чтобы иметь в виду "Здесь есть символ, который не может быть отображен напрямую". Глобусы используют [1110060]? [1110061] для обозначения "Здесь разрешен любой символ".[12182]Глобусы имеют другие специальные символы ([1110062]*[1110063] и [12183] по крайней мере, а внутри пары [12184] их больше). Ни один из них не ускользнет от [1110068]ls -q[1110069].[12185] Если вы обработаете выход [1110070]ls -1q[1110071], то получите набор глобусов и расширите их, а не только получите [1110072]x[1110073] дважды, вы пропустите [1110074][x][1110075] полностью. Как глобус, он не совпадает сам по себе со строкой.[12186]ls -q[1110077] предназначен для того, чтобы спасти ваши глаза и/или терминал от сумасшедших символов, а не для того, чтобы произвести что-то, что можно вернуть в оболочку.[119580].
51
27.01.2020, 19:28
[119462] Ответ прост: Особые случаи [119864]ls[119865] должны перевешивать любую возможную выгоду. Этих особых случаев можно избежать, если не разбирать вывод [119866]ls[119867].

Мантра здесь [119868]никогда не доверяйте файловой системе пользователя[119869] (эквивалент [119870]никогда не доверяйте вводу пользователя[119871]). Если есть метод, который будет работать всегда, со 100% уверенностью, то это должен быть метод, который вы предпочитаете, даже если [119872]ls[119873] делает то же самое, но с меньшей уверенностью. Я не буду вдаваться в технические подробности, так как они широко освещались в [119874]terdon[119875] и [119876]Patrick[119877]. Я знаю, что из-за рисков использования [119878]ls[119879] в важной (и, возможно, дорогой) сделке, где моя работа/представительство стоит на кону, я предпочитаю любое решение, которое не имеет степени неопределенности, если его можно избежать.

Я знаю, что некоторые люди предпочитают [119880]некоторый риск, а не определенность [119881], но [119882]я подал отчет об ошибке [119883].[119467].

41
27.01.2020, 19:28

Теги

Похожие вопросы