Помощь студенту

хотя бы на греп :)

Кстати очень крутая штука — jq. Это в одном флаконе grep и sed, заточенный специально под парсинг json.

Я теперь, пожалуй, буду все конфиги для скриптов сувать в json и парсить этой штукой.

Я теперь, пожалуй, буду все конфиги для скриптов сувать в json и парсить этой штукой.

Да благославит тебя зефирный человек!

Ну давай, финальный вариант, оформленный по правилам выложи, чтоб одногруппники твои ответ здесь нашли :)

У тебя не описка случайно? Я понимаю задачу примерно так:

Пишу скрипт, который должен вывести список файлов из директории, в которых содержится определенный текст. На вход дано: имя директории и текст. Man’ы по grep и find прочитаны, но не принесли успеха.

Верно?

Novichek не существует, это выдумки ми6

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

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

declare -a raw_files;
declare -a filtered_files;
declare -a result_files;

Это, очевидно, объявления массивов. Но вот это

for FILE in "${raw_files[@]}"

Что такое ${raw_files[@]}? Почему в кавычках? Почему raw_files[@] в фигурных скобках? Зачем [@] в конце? Почему нельзя, как в нормальных языках,

foreach var FILE in raw_files

Слушайте, я вот не ТС

Так я эту криптоту не для тебя а для ТС писал.

Почему нельзя, как в нормальных языках,

А когда shell был нормальным языком?

Так я эту криптоту не для тебя а для ТС писал.

Дык, я подобное нередко в bash скриптах встречаю. Ну, $raw_files - это, я так понимаю, переменная. А кавычки и фигурные скобочки какой сакральный смысл в баше имеют? Есть какая-нибудь статья по использованию именно кавычек и всех возможных скобок в скриптах?

А когда shell был нормальным языком?

Ок, принимается, тяжёлое наследие прошлого.

Пишу скрипт, который должен вывести список файлов из директории, в которой содержится определенный текст. На вход дано: имя директории и текст. Man’ы по grep и find прочитаны, но не принесли успеха.

Значит эта профессия совсем не для тебя.

Почему в кавычках?

Лучше пусть будут, если там имена файлов c пробелами могут быть, а то получишь имён файлов чуть больше, чем надо и частями

Почему raw_files[@] в фигурных скобках?

Так надо

Зачем [@] в конце?

Так надо

Почему нельзя, как в нормальных языках

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

А кавычки и фигурные скобочки какой сакральный смысл в баше имеют?

Обильный. И кто-то зачем-то (ну зачем-же) сделал, что можно и $var (не нужно) и ${var}

Есть какая-нибудь статья по использованию именно кавычек и всех возможных скобок в скриптах

есть, но длинная

От злыдни! Надо ж было такую шляпу с пробелом подложить! А вот это не понял

echo; echo '"$arr[@]"'
for i in "$arr[@]"; do echo "$i"; done

Что он хотел сказать lorem[@]? Что lorem[@] - массив? Почему он [@] в конец присобачил?

Что он хотел сказать lorem[@]?

типа $arr это просто первый элемент

Referencing an array variable without a subscript is equivalent to referencing with a subscript of 0.

а без фигурных скобочек [@] просто текст, который и выводит echo

кавычки

обычно нужны, чтобы строки с пробелами не распидорасило, без кавычек они будут как несколько аргументов (а в кавычках - одно целое)

фигурные скобочки

Ещё чтобы отделить имя переменной, типа

i=hello
echo ${i}world

А когда shell был нормальным языком?

Ок, принимается, тяжёлое наследие прошлого.

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

А вообще тоже интересно посмотреть какой-нибудь простой мануал мини-справочник про баш/шелл

Так в чём проблема? Их море. В т. ч. в сети. Например https://ruvds.com/doc/bash.pdf.

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

Знаете, я писал много .BAT-файлов без такой фигни. Хотя и встречал совершенно невообразимые батники от MS. Но, как правило, можно было писать без таких заморочек. Естественно, в .BAT не было и половины возможностей баша, но, чесслово, я бы на месте авторов внедрил их в более простом виде, а ля powershell.

Всё хорошо, но в этой статье нет упора на кавычки. Там пишут

echo "The current directory is:"

А почему нельзя написать

echo The current directory is:

А нипочему. Можно. И таких тонкостей в баше тыщща. Как например разница между [] и [[]]

Естественно, в .BAT не было и половины возможностей баша

Об этом и речь. И даже то, что было, в command.com было ужасно. Вспомнить тот же errorlevel.

я бы на месте авторов внедрил их в более простом виде, а ля powershell.

Тут сравнивать не готов. Наверно дело привычки. Но PowerShell появился несколько лет назад, а Unix Shell появился в начале 70-х, и все shell’ы — наследники того sh от Борна, похожие на него и обратно совместимые.

echo The current directory is:

Это не тонкость, а очевидная вещь. В кавычках — одна строка, даже если разделена пробелами, а без кавычек — каждое слово строка. То же самое, кстати, и в command.com.

Как например разница между [] и [[]]

А двойные скобки как раз для тех, кто не любит кавычки. :-)

Тогда вы сами себе противоречите, говоря, то

Тяжёлое наследие прошлого тут ни при чём

то

Но PowerShell появился несколько лет назад, а Unix Shell появился в начале 70-х,

А так, всё верно

Просто я не вижу каких-то серьёзных проблем ни в bash, ни в первоначальной sh и во всех его потомках, коих помимо bash’а — тьма. Конечно, есть необходимость обратной совместимости с тоннами написанных скриптов, накладывающая некоторые ограничения, но в целом Unix Shell на мой взгляд удачна. Разумеется, всё зависит от задач. Если писать на shell большое приложение (что, в принципе, тоже можно сделать), то она для этого не очень подходит, и скорее всего получится код write-only. Но для небольших скриптов на один-два экрана, манипулирующих с файлами или чем-то ещё — самое оно.

...криптотускриптоту...

Хотя...

А кавычки и фигурные скобочки какой сакральный смысл в баше имеют?

Без кавычек фор будет дробить значения по пробелу. А вообще google://bash arrays. Неужели ты думаешь что я такой баш-ниндзя все скрипты так пишу?

Просто я не вижу каких-то серьёзных проблем ни в bash, ни в первоначальной sh и во всех его потомках, коих помимо bash’а — тьма. Конечно, есть необходимость обратной совместимости с тоннами написанных скриптов, накладывающая некоторые ограничения, но в целом Unix Shell на мой взгляд удачна. Разумеется, всё зависит от задач.

+1

Если писать на shell большое приложение (что, в принципе, тоже можно сделать), то она для этого не очень подходит, и скорее всего получится код write-only. Но для небольших скриптов на один-два экрана, манипулирующих с файлами или чем-то ещё — самое оно.

Вот достаточно сложное приложение на bash: https://git.archlinux.org/pacman.git/tree/scripts

В целом терпимо. Писать и читать можно.

В целом терпимо. Писать и читать можно.

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

a1batross, ты там рыбой не подавился? rm -rf / как бы уже давно не работает, так что ничего потенциально опасного в этой команде не было. Но ты ведь даже не попытался разобраться, ведь махнуть банхаммером гораздо проще, да? Ладно zemidius некомпетентный стукач, но от тебя такого не ожидал.

Какая разница, если задача стоит поиздеваться?

Мне пофиг что там внутри, я не запускал.

rm -rf / как бы уже давно не работает

А exec rm -rf /?

Да любой обфусцированный код стирать и всё. Логично же.

Странный вопрос.

Да любой обфусцированный код стирать и всё.

Эй! Не надо удалять мою тему Открывается конкурс дураков на самую нечитабельную программу. Она мне дорога как память.

rm -rf / как бы уже давно не работает

А exec rm -rf /?

Странный вопрос.

Почему странный? Известно, что rm -rf / не работает, потому что эту фигню при запуске от root’а проверяет то ли bash, то ли сама rm, и всё равно спрашивает, несмотря на опцию -f. Но проверяется ли команда exec rm -rf /? Если тебе это известно, то скажи. А если сам не знаешь, то чего странного в моём вопросе? Просто хотел узнать, не запуская на собственном компе от рута. Можно, конечно, создать контейнер, но не настолько животрепещущий это для меня вопрос, чтоб возиться.

то ли сама rm

Сама rm.

Но проверяется ли команда exec…

Если знать, что такое exec, ответ очевидный. Для rm ничего не изменилось: запускается, проверяет аргументы, ругается, прекращает работу.

А там без разницы, я вчера пробовал на LiveUSB Kubuntu 20.04 и то, и другое. Зато работает rm -rf /*, но это все и без меня знают.

Сама rm.

Понятно, буду знать.

Если знать, что такое exec, ответ очевидный. Для rm ничего не изменилось

Безусловно. Но знать ещё надо, кто проверяет: rm или оболочка.

Зато работает rm -rf /*

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

некомпетентный стукач

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

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

$ echo one $(two)     
sh: 2: two: not found
one
$ echo one $(echo two)
one two
$ echo one $[two]
one $[two]
$ echo one ${two}
one
$ two=sss; echo one ${two}
one sss
$ 

А нипочему. Можно.

Язык не освоил, а уже критикуешь, набери в консоли вот эти две команды:
echo "The current directory; is:"
echo The current directory; is:

и почувствуй разницу.

echo The current directory; is:Это понятно. Непонятно, почему не запретили строки без кавычек. Непонятно отсутствие жёсткой типизации. Эх, скриптовые, мать их, особенности.

Вот это непонятно

$ echo one ${two}
one

особенно в свете

$ echo one $(two)     
sh: 2: two: not found

почему $ echo one ${two} не ругается на необъявленную переменную?

Надеюсь, на perl?

На баше

Я сделаю это за 500р напиши мне в телеге @roman_wr

почему $ echo one ${two} не ругается на необъявленную переменную?

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

Причём скорее всего и not found пишется после неудачной попыткизапуска команды.

Вот это непонятно $ echo one ${two} one почему $ echo one ${two} не ругается на необъявленную переменную?

1. По умолчанию баш не проверяет, объявлена или нет переменная. Если ты используешь значение необъявленной переменной, там будет просто пусто. Это поведение можно изменить при помощи «set -o nounset». Тогда будет как раз так, как ты хочешь.

особенно в свете $ echo one $(two)
sh: 2: two: not found

2. Конструкцию $(two) баш понимает как «запустить команду two». Тут нет подстановки значения переменной, вообще нет и не должно быть. Оно было бы, если бы команда выглядела так:

echo one $( ${two} )

Вот в этом случае баш попытался бы выполнить команду, которая содержится в переменной с именем two.

По умолчанию баш не проверяет, объявлена или нет переменная. Если ты используешь значение необъявленной переменной, там будет просто пусто. Это поведение можно изменить при помощи «set -o nounset»

Вот я и говорю: в вашем баше слишком много тонкостей и неочевидностей. Если бы его делали сейчас, он был бы намного понятнее.

слишком много тонкостей и неочевидностей

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

C#, QBasic