Как сделать так, чтобы переменная была одна и та же во всём скрипте?

[жучара]

Друзья! Требуется, чтобы переменная my_max была одна и та же во всём скрипте, а значение её пусть меняется

Код: Выделить всё

#!/bin/sh

#Вот эта переменная пусть будет одна и та же для всего скрипта
my_max=2

#Вот я её даже экспортирую
export my_max
echo $my_max 

find | while read LINE
do 
	#Изменяю её значение
	my_max=3
	echo $my_max
	exit
done

#А на самом деле оно неизменно, как было 2, так и осталось!
echo $my_max 
exit

Shell

user@astra:~$ ./foo.sh
2
3
2
user@astra:~$

Код вырожденный. В реальном коде в цикле обрабатывается вывод команды find. Тут дело в том, что из-за команды find запускается ещё один интерпретатор bash и переменная my_max, которая внутри цикла, совсем не та, что снаружи, ибо два интерпретатора- две разных переменных.

Ага, а разве export my_max не решает? Везде пишут:

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

Так себе экспорт, сказать прямо. Не воодушевляет даже:

Код: Выделить всё

#!/bin/sh

#Вот эта переменная пусть будет одна и та же для всего скрипта
my_max=2

#Вот я её даже экспортирую
export my_max
echo $my_max 

find | while read LINE
do 
	#Изменяю её значение
	echo $my_max
	my_max=3
	echo $my_max
	exit
done

#А на самом деле оно неизменно, как было 2, так и осталось!
echo $my_max 
exit

Shell

user@astra:~$ ./foo.sh
2
2
3
2
user@astra:~$

Ну, допустим, экспортировал я переменную в дочерний процесс. А обратно, в родительский как? В общем, грустно это всё. Спасибо, кто откликнется.

[/dev/random]

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

[жучара]

/dev/random, я не знаю, как грамотно сделать.

Код: Выделить всё

find > tmp
while read LINE
do 
	#Изменяю её значение
	echo $my_max
	my_max=3
	echo $my_max
	#exit
done < tmp

так опять без дополнительного файла не обойтись.

[/dev/random]

Если у вас bash, то можно так:

Код: Выделить всё

while read LINE
do
  ...
done < <(find)

P.s. И учтите, что построчное чтение неправильно сработает на файлах с переводом строки в имени. Используйте \0 в качестве разделителя. Соответствующие опции есть и у read, и у find, но в стандарт они не входят. Это значит, что потребуются bash и gnu find.

[olecya]

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

Код: Выделить всё

shopt -s lastpipe

или поместить команду в скобки

Код: Выделить всё

find | (your command \
else command)

Добавлено (15:00):

Код: Выделить всё

#!/bin/bash
my_max=2

shopt -s lastpipe

find | while read LINE
do 
        my_max=3
        break
done

echo $my_max
3

#!/bin/bash
my_max=2

find | (while read LINE
do 
        my_max=3
        break
done

echo $my_max)
3

Добавлено (15:13):

Если вы заметили команда exit у вас завершает работу подоболочки и не влияет на работу программы в целом.
Когда же устанавливаем опцию lastpipe команда exit будет завершать работу самого скрипта, поэтому заменяем ее на break

[жучара]

Если у вас bash, то можно так:

Код: Выделить всё

while read LINE
do
  ...
done < <(find)

P.s. И учтите, что построчное чтение неправильно сработает на файлах с переводом строки в имени. Используйте \0 в качестве разделителя. Соответствующие опции есть и у read, и у find, но в стандарт они не входят. Это значит, что потребуются bash и gnu find.

Даже не знаю, что сказать. Я стал бы использовать этот код везде, где требовалось бы СНАЧАЛА выполнение команды find и только ПОТОМ работа цикла. И ошибся бы.

Shell

use@astra:~$ ls
bar.sh
use@astra:~$ cat bar.sh
# !/bin/bash

while read LINE
do
echo $LINE
done < <(find) > foo
use@astra:~$

То есть скрипт

Shell

bar.sh

считывает содержание текущей папки, а потом в цикле оно перенаправляется в

Shell

foo

+++++++++++++++++++++++++++++++++++++++++++++++

Shell

use@astra:~$ ./bar.sh
use@astra:~$ ls
foo bar.sh
use@astra:~$
use@astra:~$ cat foo
.
./foo
./bar.sh
use@astra:~$

То есть на момент запуска запуска скрипта файла foo в папке не было и в списке его быть не могло. Это в том случае, если предполагать очевидное, что сперва выполняется команда, которая в скобках (find, то есть сперва перечисляются все файлы) и только потом всё остальное. Как бы не так. Файл foo создался ДО выполнения bar.sh (я уж не думаю, что в процессе ) Не знаю, видели ли вы такое поведение программы в момент написания или нет, но для меня это мина замедленного действия. И для этого парня тоже (последний код) Ладно хоть просёк вовремя.

+++++++++++++++++++++++++++++++++++++++++++++++

Получается, либо действительно без дополнительного файле не обойтись, либо как-то так:

Shell

# !/bin/bash

while read LINE
do
echo $LINE
done < <(find ! -name foo) > foo

Коряво, но кто может сделать лучше, пусть сделает лучше.

[/dev/random]

Я стал бы использовать этот код везде, где требовалось бы СНАЧАЛА выполнение команды find и только ПОТОМ работа цикла. И ошибся бы.

Разумеется, ошиблись бы. В man bash ясно написано, что конструкция <(команда) запускает команду в фоне и подставляет вместо себя имя, ссылающееся на пайп, из которого, как из файла, можно читать вывод программы по мере его появления. Кстати, ваш первоначальный код команда | команда тоже запускает эти команды параллельно.

[Bizdelnick]

Я стал бы использовать этот код везде, где требовалось бы СНАЧАЛА выполнение команды find и только ПОТОМ работа цикла. И ошибся бы.

Пайпы имеют маленькую вместимость, то есть если процесс пытается что-то записать в заполненный пайп, он заблокируется до тех пор, пока другой процесс не предпримет попытку чтения из пайпа. Поэтому работа find блокируется на время обработки каждой строки в теле цикла. Подробнее — в man 7 pipe.

[жучара]

Я стал бы использовать этот код везде, где требовалось бы СНАЧАЛА выполнение команды find и только ПОТОМ работа цикла. И ошибся бы.

Пайпы имеют маленькую вместимость, то есть если процесс пытается что-то записать в заполненный пайп, он заблокируется до тех пор, пока другой процесс не предпримет попытку чтения из пайпа. Поэтому работа find блокируется на время обработки каждой строки в теле цикла. Подробнее — в man 7 pipe.

тут вопрос порядка завершения команд. Cкобки же и в Африке скобки. По-моему. То есть, пока (find) не отработает никаких прочих движений. Ну скобки же, что про них читать? А оказалось, что даже файл foo раньше создастся, чем отработает find (перечислит все файлы в текущей директории)

[Bizdelnick]

Cкобки же и в Африке скобки. По-моему. То есть, пока (find) не отработает никаких прочих движений. Ну скобки же, что про них читать?

Простите, так уж вышло, что нет.

[olecya]

То есть, пока (find) не отработает никаких прочих движений.

Можно обойтись без цикла и не ждать пока файнд отработает. Заодно давайте например уберем расширение и поставим свое

Код: Выделить всё

find * -type f -exec bash -c 'echo ${0%.*}.своё' {} \;

Добавлено (18:41):

Или посчитаем количество файлов

Код: Выделить всё

find * -type f -exec bash -c 'echo $#' 1 {} +

[s.xbatob]

find * -type f -exec bash -c 'echo $#' 1 {} +

даже в конструкции -exec ... + можно нарваться: find хоть и накапливает аргументы сколько может, но и тут есть ограничение, и если их много, то утилита из exec может быть вызвана несколько раз

[olecya]

Надо исправиться и оставить меньше шансов для переполнения )))

Код: Выделить всё

find * -prune -type f -exec bash -c 'echo $#' 1 {} +

[Bizdelnick]

find *

А какой смысл в использовании здесь *?

Надо исправиться и оставить меньше шансов для переполнения

Меньше или больше — не имеет значения. Они есть, и сбрасывать это со счетов нельзя.

[olecya]

А какой смысл в использовании здесь *?

Смысл в моей первой строчке. Исключить скрытые файлы
А вторая что бы поддержать единый стиль.

Меньше или больше — не имеет значения. Они есть, и сбрасывать это со счетов нельзя.

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

[Bizdelnick]

Я перестраховалась если бы в директории были скрытые файлы без расширения

Не распарсил. Причём здесь «расширение»?

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

И снова не уловил мысль. Скрипт — это программа. Программа либо работает корректно, либо нет. И надо писать программы так, чтобы они работали корректно в любых условиях, а не чуть чаще, чем могло бы быть.

[s.xbatob]

Для тех кому не интересно можно просто пройти мимо

Да, неинтересно! Для таких задач sh вообще лучше не использовать: много возни и куча подводных камней. Лучше озаботиться изучением какого-либо нормального скриптового языка.
Только проходить мимо тех, кто даёт вредные советы, да ещё и с граблями, так хорошо замаскированными, — нельзя

[olecya]

Bizdelnick, Ну чтобы распарсить достаточно просто в терминале запустить две строчки
в текущей директории где есть скрытые файлы начинающиеся с точки без расширения

Код: Выделить всё

find * -type f -exec bash -c 'echo ${0%.*}.своё' {} \;
find -type f -exec bash -c 'echo ${0%.*}.своё' {} \;

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

То есть, пока (find) не отработает никаких прочих движений.

find *
А какой смысл в использовании здесь *?

Смысл был в другом, в правой части выражения, не более

Код: Выделить всё

exec bash -c 'echo ${0%.*}.своё' {} \;

в остальном можете подставлять все что угодно по вашему смыслу.
Вторая строчка была приведена только лишь для того если кто то не знаком с данной
конструкцией мог заинтересовавшись опытным путем установить что позиционные параметры
начинаются с переменной $0 а переменная $# определяет количество только с $1
Не хотелось бы думать но если это тролинг тогда однообразно

find *

Какой здесь смысл в утилите find ?
Я что нечаянно села на ваше место?

[Bizdelnick]

Ну чтобы распарсить достаточно просто в терминале запустить две строчки
в текущей директории где есть скрытые файлы начинающиеся с точки без расширения

Я по-прежнему не понимаю, что Вы подразумеваете под «файлами, начинающимися с точки без расширения». Это во-первых. Во-вторых, если Вы запустите эту команду в каталоге, в котором количество не начинающихся с точки файлов таково, что не влезает в командную строку, ничего хорошего из этого не выйдет.

Не хотелось бы думать но если это тролинг тогда однообразно

Это не троллинг. Вы привели команду, которая может работать некорректно, и я пытаюсь донести это до Вас и тех, кто читает тему.

[s.xbatob]

Смысл был в другом

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

[olecya]

Только ваши комментарии ко всему этому отношения не имеют.

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

[s.xbatob]

поделилась кусочком своих знаний

спросите — поделюсь. Но отвечать невпопад не буду. Да ещё и с анитсоветами.

[olecya]

Прошу всех кому есть что написать в мой адрес переходить по этой ссылке.
Буду рада ответить.
помойница для вне темовых обсуждений

[жучара]

То есть, пока (find) не отработает никаких прочих движений.

Можно обойтись без цикла и не ждать пока файнд отработает. Заодно давайте например уберем расширение и поставим свое

Код: Выделить всё

find * -type f -exec bash -c 'echo ${0%.*}.своё' {} \;

мне нужно было перечислить все файлы и запихать их имена в файл dst которого на момент начала задачи не было. То есть так:

Shell

user@astra:~$ ls
aaa bbb ccc ddd
user@astra:~$
user@astra:~$ find * -type f -exec bash -c 'echo ${0%.*} >> dst' {} \;
user@astra:~$
user@astra:~$
user@astra:~$ cat dst
aaa
bbb
ccc
ddd
user@astra:~$

Ну допустим. Но тогда, с учётом имеющихся у нас знаний, почему он сам себя не пишет? После первого же echo aaa >> dst должен был создасться файл dst и find его должна была последним найти и его имя в него и занести. Я так понимаю, вся эта конструкция была задумана, чтобы мы не делали так, что сперва получаем список файлов, а потом их заносим в файл:

Можно обойтись без цикла и не ждать пока файнд отработает.

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

[olecya]

Потому что в этой конструкции происходит все совсем по другому
Перед тем как выполнится команде файнд облочка подставляет вместо шаблона астериск все файлы в текущей директории
в вашем случае так

Код: Выделить всё

find aaa  bbb  ccc  ddd -type f -exec bash -c 'echo $0 >> dst' {} \;

я убрала удаление расширений, оно здесь бесполезно

Добавлено (18:26):

Вот если вы сделаете вот так будет все по другому

Код: Выделить всё

find -exec bash -c 'echo $0' {} \; >> dst

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

[жучара]

Потому что в этой конструкции происходит все совсем по другому
Перед тем как выполнится команде файнд облочка подставляет вместо шаблона астериск все файлы в текущей директории
в вашем случае так

Код: Выделить всё

find aaa  bbb  ccc  ddd -type f -exec bash -c 'echo $0 >> dst' {} \;

я иногда перечисляю с помощью find все все файлы в корневой директории. И использую -exec grep (может, не совсем правильно, но не суть). Файлов реально немало, я иной раз по запарке примонтирую файловую систему ntfs на 60 гигов] с файлами ...летней наработки и забуду отмонтировать. И эти все файлы вот так вот перечисляются? Без какого-либо переполнения? С абсолютными путями? Ну не знаю...

[Bizdelnick]

После первого же echo aaa >> dst должен был создасться файл dst и find его должна была последним найти и его имя в него и занести.

Должен не после первого, а после того, как буфер пайпа заполнился. То есть может и раньше, конечно, но не обязательно.
Чтобы избежать неожиданностей, просто сохраняйте файл в другом каталоге. Как вариант, можно вывод find сохранить в переменной, но это не самый лучший способ, если список файлов окажется очень большим.

Добавлено (18:42):

И эти все файлы вот так вот перечисляются? Без какого-либо переполнения?

Если Вы используете \;, то нет, команда вызывается отдельно для каждого файла. Если вместо этого использовать +, то ей за раз будет передаваться по столько файлов, сколько ОС позволяет упихнуть в командную строку.

P. S. grep умеет рекурсивно обходить каталог, find для этого не нужен. См. опции -R и -r.

[жучара]

После первого же echo aaa >> dst должен был создасться файл dst и find его должна была последним найти и его имя в него и занести.

Должен не после первого, а после того, как буфер пайпа заполнился. То есть может и раньше, конечно, но не обязательно.
Чтобы избежать неожиданностей, просто сохраняйте файл в другом каталоге. Как вариант, можно вывод find сохранить в переменной, но это не самый лучший способ, если список файлов окажется очень большим.

Добавлено (14.02.2020 18:42):

И эти все файлы вот так вот перечисляются? Без какого-либо переполнения?

Если Вы используете \;, то нет, команда вызывается отдельно для каждого файла.

Какая команда?

Shell

man find
...
-exec command ;
...
The specified command is run once for each matched file.
...

вы это имели ввиду?

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Тогда я переспрошу: сперва после запуска команды, например
find * -type f -exec bash -c 'echo ${0%.*} >> dst' {} \;

вместо звёздочки подставляется сиксилиард имён файлов
find имя_0...имя_сикслиард-1 -type f -exec bash -c 'echo ${0%.*} >> dst' {} \;

А потом команда bash -c 'echo ${0%.*} >> dst' выполняется сиксилиард раз?

Ну допустим. Но сиксилиард-то имён как сюда влезает?
find имя_0...имя_сикслиард-1 -type f -exec bash -c 'echo ${0%.*} >> dst' {} \;

[Bizdelnick]

вы это имели ввиду?

Да, и ещё чуть ниже написано про -exec command {} +.

вместо звёздочки подставляется сиксилиард имён файлов

Не подставляется. Допустимая длина командной строки ограничена, шелл её не превысит.

[olecya]

только файлы из ТЕКУЩЕЙ директории. У вас в текущей сиксилиард лежит? (надо запомнить сиксилиард)

Добавлено (20:06):

по моему getconf знает максимальные величины