В любом случае, мне не нужны переменные. Мне не нужны изменения в текущей сессии шелла, мне не нужно их сохранять, мне не нужны длинные сложные конструкции которые могут сломаться в любом месте и не в том где проблема возникла.
Ну что же ты такой тупой? Речь о простейшем добавлении в ваш скрипт чуть-чуть еще одно чтение. Несложное. Можно даже одно чтение на скрипт, но может вам завтра понадобится проверить этот ввод на предмет — давать ли это введенное для wget или пользователь захотел выйти из скрипта.
Ну извините, это ещё не факт кто тут тупой. Требования к задаче вполне конкретные и прозрачные, других вводных быть не может. $(read -r var;echo $var) (комментарий)
За пределами функции переменных не будет, так же, как и в случае с $(). Но работать по идее должно быстрее, а главное — можно не упихивать всё в одну строку, а сделать читаемо.
Ну извините, это ещё не факт кто тут тупой. Требования к задаче вполне конкретные и прозрачные, других вводных быть не может.
Только полный тупица может уверять, что задача должна быть решена без возможности расширения.
Выйти из скрипта кстати прекрасно работает в данном случае, если в сабшелле что-то интересное придётся прописать trap int break только и всего.
sigint - это не выход, это прерывание, одно дело, когда скрипт выполнил успешно итерацию, другое дело, когда его прервали посредине того же wget-а. Выход у интерактивного скрипта обычно делается так: в промте пишем: «Введите URL или q для завершения работы». Отсюда и вытекает проверка ввода, а следовательно - переменной.
Только while true и выход через ^C отличная юзер-френдли логика для приложения, какие-нибудь меню с «введите q чтобы выйти» тут не нужны.
Только полный тупица может уверять, что задача должна быть решена без возможности расширения
Только полный тупица будет тратить время на задачи, которые ему решать не нужно _и никогда не станет нужно_, и будет в этом процессе значительно повышать уязвимость к ошибкам (чтобы их потом исправлять и исправлять).
Я пишу скрипты не первый год, я знаю о чём говорю. Хорошо написанный скрипт работает десятилетиями и не требует изменений, чем он проще, тем лучше.
ну можно функцию в сабшелле вызывать, тогда всё нормально
Чему нормально? У вас нет никакой нормальности, только полный идиотизм.
Одно дело, когда резульатт будет в REPLY, другое дело, что оно будет в буферах ввода-вывода, которые вы не очистите, если вы об том печётесь.
и эта переменная имя функции?
Нет, это в других языках такое, в shell передача результата в виде строки без глобальных переменных весьма занятна и стоит взглянуть ради общей эрудиции.
Мне никогда не приходилось думать о переносимости, если мне надо я возьму bash, если захочу возьму zsh. У каждого скрипта есть требования к системе. Данный снипплет мне нужно выполнять везде, поэтому я хочу без внешних команд и спрашиваю заранее. Если я смогу набрать его по памяти без возможности ошибиться, ещё лучше.
Какие буферы, где? Вы бредите? Почему они должны меня беспокоить? И почему я тогда не вижу их в памяти когда смотрю? Мой код работает, работает чисто и без ошибок, и не создаёт лишего шума. Пока придумайте хоть один ответ. Аноним предложил уже 2 решения, от вас же 0 пользы.
Это дополнительные команды вместо простого аккуратного сабшелла на месте аргумента. Я хочу без переменной и коротко, просто хочу. Вызывать сабшелл это классический приём, он не засоряет память и вообще всё хорошо, мне хватает производительности. Не нужно думать за меня, я хочу без переменных, меня устраивает вариант с head за неимением лучшего.
Хорошо, спасибо, я положу это в скрипт который буду вызывать когда мне не нужно набирать вручную. Меня устраивает такое решение. Оставим head для случаев когда он уместен, я тоже не совсем хочу спавнить кучу процессов.
unset не удаляет встроенные перменные, а только очищает, потому просто REPLY= - будет и аналогично и быстрее. А вообще, как уже 10 раз сказано - полный идиотизм.
Ну ещё 40 раз скажи, может кто не понял. ТС спрашивает, как сделать то-то и то-то. Я отвечаю.
Мне не сложно, могу ещё раз сказать: то что спрашивается — идиотизм, так делать не надо. То что вы отвечаете и даже при идиотской постановке ТЗ тоже зачастую не верно. Вполне возможно, что ваши ошибки возникают от попыток решений вот таких постановок задач — какой кривулиной побыстрому решить идиотскую задачу.