LINUX.ORG.RU
решено ФорумAdmin

bash -c ' echo {}"

 ,


1

2

Добрый вечер! Имеется файл и именем ~@#$%^-_(){}’`.mp4 Хочу вывести путь к этому файлу через команду:

find ./ -name "~@#$%^-_(){}\'\`.mp4" -exec bash -c 'FILE=$(echo {} ) ' \;

И получаю ошибку:

bash: -c: line 0: unexpected EOF while looking for matching `''
bash: -c: line 1: syntax error: unexpected end of file

Я понимаю, что можно и без bash -c вывести и будет порядок, но мне нужно писать скрипт с буфером обмена используя | и т.д. Как экранировать эти символы " ’ и ` " в echo или printf или может быть ещё чём-то я не знаю



Последнее исправление: SaintAnd (всего исправлений: 2)

Ответ на: комментарий от wandrien

Спасибо!

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

SaintAnd
() автор топика
Ответ на: комментарий от wandrien

У меня просто этих файлов будет чрезвычайно большое количество. Миграция видеофайлов скоро будет назначена.

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

Есть мысли как обойти это ограничение?

SaintAnd
() автор топика
Ответ на: комментарий от SaintAnd

Так с -L1 он будет запускать по одной штуке bash для каждого файла, так что от числа файлов длина строки вызова не зависит.

Если это не то, что требуется, то проще сделать так:

https://stackoverflow.com/questions/8677546/reading-null-delimited-strings-through-a-bash-loop

wandrien ★★
()
Ответ на: комментарий от anc

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

на Си зачастую быстрее

Угу. Забудешь сделать free и получишь утечку. А сделаешь двойной free - получишь Bus error в самом неожиданном месте. Так что Си тоже не панацея и тоже нужно порой отлаживать так же как и баш скрипты.

iron ★★★★★
()
Ответ на: комментарий от iron

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

потом понял что написать тот же «скрипт» на Си зачастую быстрее чем наваливать друг на друга шелл-костыли и потом отлаживать их.

Может вы просто не знаете шелл?

anc ★★★★★
()
Ответ на: комментарий от iron

И ещё внезапные выпадения в кору. Ну и на C не быстрее, этож больше букавок, сконпеляй... нафига мне для обычного cp $from $to писать лишние букавки в виде int main( int argc.... и т.д. ? Даже если для копирования и то можно ошибиться... Это скорее вантуз подход, а не KISS.

anc ★★★★★
()
Ответ на: комментарий от anc

И ещё внезапные выпадения в кору.

Корки - это еще фигня. Загрузил lldb, сделал бэктрейс и понял где лажа. А вот при двойном free() кораптится случайная область памяти и потом какая-нить переменная или функция начинает жить своей жизнью. А если эта функция во внешней библиотеке - то вообще весело. И отдебажить такое порой бывает очень сложно. Да, есть valgrind, который порой выручает. Но к сожалению, далеко не всегда.

iron ★★★★★
()
Ответ на: комментарий от iron

Корки - это еще фигня.

Вообще не фигня когда они рандомны, типа раз в месяц падает с коркой и ты об этом не знаешь.

Да, есть valgrind, который порой выручает.

И ещё как выручает!

anc ★★★★★
()
Ответ на: комментарий от pihter

Проще написать на том, что лучше знаешь - вот правильный ответ :)

Написать-то да, но вот «место имения» написанного может немного расходится с тем «что ты лучше знаешь». :)

anc ★★★★★
()
Ответ на: комментарий от anc

Вообще не фигня когда они рандомны

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

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

iron ★★★★★
()
Ответ на: комментарий от iron

Главное то, что в корке ты имеешь состояние проги на момент падения.

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

anc ★★★★★
()
Ответ на: комментарий от iron

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

Это уже не прога, это скорее какое-то поделие мальчика Васи из 7-го Г.

anc ★★★★★
()
Ответ на: комментарий от anc

Это уже не прога, это скорее какое-то поделие мальчика Васи из 7-го Г.

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

iron ★★★★★
()
Ответ на: комментарий от anc

Эт когда в ведрах был «неправильный результат» ?

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

iron ★★★★★
()
Ответ на: комментарий от anc

нафига мне для обычного cp $from $to писать лишние букавки в виде int main( int argc.... и т.д.

Для cp $from $to не помешает написать «лишние» кавычки и лишние два дефиса перед именами файлов. Ну и проверить, что указанные $from и $to не испортились где-то раньше из-за непредвиденных в них пробелов и бажного шелл-кода. А так да, реализовывать просто копирование файлов на Си обычно незачем. Но это как раз тривиальный случай.

Это скорее вантуз подход, а не KISS.

Это навешивание ярлыков ничего не меняет.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 4)
Ответ на: комментарий от anc

Можно пример?

Вот мой баг репорт касаемо утечки mbuf в подсистеме TCP/RACK ярда фри, на которую я наткнулся еще во времена 12.2-STABLE. Даже дошло дело до того, что я переписывался по мылу с разработчиком этой подсистемы, отправлял ему корки и накладывал его патчи. В итоге бага тогда не была пофикшена, так как ни я, ни разраб не могли ее стабильно воспроизвести. В 13-й фряхе уже вродь не текло. Но юзать RACK в проде как-то не было желания.

iron ★★★★★
()
Ответ на: комментарий от iron

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

Но юзать RACK в проде как-то не было желания.

А зачем ставить в прод непроверенные штуки? Насколько я почитал оно только в 12 версии появилось т.е. это тестовый функционал.

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

А вот дампить и отправить разрабу не могу, так как там могут быть приватные данные. На тестовой системе этот баг не проявлялся, только в проде под высокой нагрузкой. У меня вообще была проблема с воспроизведением баги. Такое ощущение, что оно зависело от фазы луны. В любом случае, это уже не актуально, так как на 13 вродь как все работает.

А зачем ставить в прод непроверенные штуки?

Потому, что при моем юз кейсе оно сущуственно увеличивало производительность определенных сетевых операций. Я бы по фану просто так бы не поставил на прод.

iron ★★★★★
()
Ответ на: комментарий от firkax

Что приватного в имени файла и номере строки откуда аллокация была сделана?

Если бы определили в какой именно строке утекают mbufs - уже бы пофиксили. В ядре дофигище мест где аллокейтятся mbufs. Как в подсистеме RACK так и вне ее. И утечка могла быть где угодно.

iron ★★★★★
()
Ответ на: комментарий от iron

Так я и говорю: дописать в структуру mbuf отладочные метаданные - файл и строку где его (конкретный буфер) аллоцировали. Это может смотреться страшно (якобы система утонет в отладочных данных), но на деле это всего лишь 8-12 байт (само имя файла не надо хранить, там указатель на константный литерал, а номер строки это просто целое число). И дамп именно этих метаданных (точнее статистику сколько откуда аллоцировано, думаю там будет один лидер с большим отрывом, который и виноват) и отослать.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)