$(read -r var;echo $var)

Да, head будет везде. Если уж wget есть, то head точно. Это одна из самых базовых утилит, наравне с cat.

С сабшелом работает. Если использовать переменную, логичнее будет воспользоваться чем-то таким $(read -r var;echo $var) (комментарий)

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

мне не нужны длинные сложные конструкции

Ну что же ты такой тупой? Речь о простейшем добавлении в ваш скрипт чуть-чуть еще одно чтение. Несложное. Можно даже одно чтение на скрипт, но может вам завтра понадобится проверить этот ввод на предмет — давать ли это введенное для wget или пользователь захотел выйти из скрипта.

Ну извините, это ещё не факт кто тут тупой. Требования к задаче вполне конкретные и прозрачные, других вводных быть не может. $(read -r var;echo $var) (комментарий)

Выйти из скрипта кстати прекрасно работает в данном случае, если в сабшелле что-то интересное придётся прописать trap int break только и всего.

Если тебе принципиально, чтобы в текущей сессии шелла не было этих переменных — можно поместить это не в сабшелл, а в функцию:

#!/bin/sh
do_my_shit() {
    read
    echo "REPLY1=$REPLY"
    read
    echo "URL=$REPLY"
    read
    echo "REPLY3=$REPLY"
}
echo -en '1\nurl\n3\n' | do_my_shit

За пределами функции переменных не будет, так же, как и в случае с $(). Но работать по идее должно быстрее, а главное — можно не упихивать всё в одну строку, а сделать читаемо.

Ну извините, это ещё не факт кто тут тупой. Требования к задаче вполне конкретные и прозрачные, других вводных быть не может.

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

Выйти из скрипта кстати прекрасно работает в данном случае, если в сабшелле что-то интересное придётся прописать trap int break только и всего.

sigint - это не выход, это прерывание, одно дело, когда скрипт выполнил успешно итерацию, другое дело, когда его прервали посредине того же wget-а. Выход у интерактивного скрипта обычно делается так: в промте пишем: «Введите URL или q для завершения работы». Отсюда и вытекает проверка ввода, а следовательно - переменной.

За пределами функции переменных не будет

Есть только два но: REPLY - глобальна, возврат из функции строки не прост и всё равно только через переменную.

REPLY - глобальна

ну можно функцию в сабшелле вызывать, тогда всё нормально

do_my_shit(){ read;echo $REPLY; }; while true;do wget `do_my_shit`; echo $REPLY;done

всё равно только через переменную

и эта переменная имя функции?

Только while true и выход через ^C отличная юзер-френдли логика для приложения, какие-нибудь меню с «введите q чтобы выйти» тут не нужны.

Только полный тупица может уверять, что задача должна быть решена без возможности расширения

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

Я пишу скрипты не первый год, я знаю о чём говорю. Хорошо написанный скрипт работает десятилетиями и не требует изменений, чем он проще, тем лучше.

ну можно функцию в сабшелле вызывать, тогда всё нормально

Чему нормально? У вас нет никакой нормальности, только полный идиотизм. Одно дело, когда резульатт будет в REPLY, другое дело, что оно будет в буферах ввода-вывода, которые вы не очистите, если вы об том печётесь.

и эта переменная имя функции?

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

Я пишу скрипты не первый год, я знаю о чём говорю.

Не уверен, насколько портабельно использование базовых POSIX-тулзов, таких как head…

Мне никогда не приходилось думать о переносимости, если мне надо я возьму bash, если захочу возьму zsh. У каждого скрипта есть требования к системе. Данный снипплет мне нужно выполнять везде, поэтому я хочу без внешних команд и спрашиваю заранее. Если я смогу набрать его по памяти без возможности ошибиться, ещё лучше.

Какие буферы, где? Вы бредите? Почему они должны меня беспокоить? И почему я тогда не вижу их в памяти когда смотрю? Мой код работает, работает чисто и без ошибок, и не создаёт лишего шума. Пока придумайте хоть один ответ. Аноним предложил уже 2 решения, от вас же 0 пользы.

«Да и потом, на случай, если враги будут сканировать память, тоже.»

Какие буферы, где?

«Да ваш ввод в памяти интерпретатора будет в 10 местах...»

Аноним предложил уже 2 решения

И оба под стать вашему идиотизму - никуда не годные.

от вас же 0 пользы.

Правильно сказал zvezdochiot, что надо просто забить, чего с идиотом разговаривать. До свидания, всего вам хорошего.

А почему бы просто не unset переменную, если она беспокоит? unset — это встроенная команда шелла.

while true; do echo -n "Enter URL: " ; read ; wget "$REPLY" ; unset "$REPLY"; done

Только сейчас заметил, что ошибку допустил, $ пере REPLY для unset, конечно, не нужен. Вот так будет работать:

while true; do echo -n "Enter URL: " ; read ; wget "$REPLY" ; unset REPLY ; done

Это дополнительные команды вместо простого аккуратного сабшелла на месте аргумента. Я хочу без переменной и коротко, просто хочу. Вызывать сабшелл это классический приём, он не засоряет память и вообще всё хорошо, мне хватает производительности. Не нужно думать за меня, я хочу без переменных, меня устраивает вариант с head за неимением лучшего.

Хорошо, спасибо, я положу это в скрипт который буду вызывать когда мне не нужно набирать вручную. Меня устраивает такое решение. Оставим head для случаев когда он уместен, я тоже не совсем хочу спавнить кучу процессов.

пере REPLY для unset, конечно, не нужен.

unset не удаляет встроенные перменные, а только очищает, потому просто REPLY= - будет и аналогично и быстрее. А вообще, как уже 10 раз сказано - полный идиотизм.

Это дополнительные команды вместо простого аккуратного сабшелла на месте аргумента.

facepalm.jpg

А вообще, как уже 10 раз сказано - полный идиотизм.

Ну ещё 40 раз скажи, может кто не понял.

ТС спрашивает, как сделать то-то и то-то. Я отвечаю. Идиотизм, не идиотизм — это уже отдельный вопрос.

Ну ещё 40 раз скажи, может кто не понял. ТС спрашивает, как сделать то-то и то-то. Я отвечаю.

Мне не сложно, могу ещё раз сказать: то что спрашивается — идиотизм, так делать не надо. То что вы отвечаете и даже при идиотской постановке ТЗ тоже зачастую не верно. Вполне возможно, что ваши ошибки возникают от попыток решений вот таких постановок задач — какой кривулиной побыстрому решить идиотскую задачу.