Нужна помощь в написании скрипта.

[ZyX]

дело не в for, а в звёздочке:
1. она _может_ раскрыться не полностью, и на практике лично я такое наблюдал.
2. перед звёздочкой надо по уму проверить, не является-ли каталог пустым. Иначе в этой вполне штатной ситуации звёздочка не раскроется, и если она в КС, то сама звёздочка и передастся, а если она в for in *, то передастся пустая строка.

$

for f in *; do echo "i='$i'"; done i='' echo * *

3. поведение звёздочки почти не регулируемое. В частности она не отличает каталоги от файлов, не понимает, что симлинк это не обычный файл, и не видит скрытых файлов.
4. Звёздочка выдаёт не просто список файлов, а отсортированный список. Практически всегда это не нужно. Какой смысл тратить ресурсы на ненужную сортировку? (если каталог большой, то ресурсы не малые, ибо сортировать надо "на месте", а это O(N*log(N)) по времени, и ещё O(N) по памяти).

А с вашим любимым find-ом, кстати, будет куча проблем с симлинками.

вот как раз с find никаких проблем и не будет: есть там опции -P, -L, и -H, которые позволяют мне обрабатывать симлинки именно так, как _мне_ это нужно. А не как звёздочка, которая (не)раскрывается так, как _она_ хочет.

Конечно, к вашему варианту это не относится, тк вы предусмотрительно написали '-type f'. Но просто обычно выкидывать симлинки - не самое лучше, чем можно заниматься на АФ что можно придумать. Все-таки.

ну не нравится такое поведение - поменяйте. К вашему распоряжению кроме упомянутых H,L,P есть ещё xtype & follow. Для звёздочки всего этого нет, и не будет...

Что интересно, всё это есть в zsh:
1. Если вы имеете ввиду файлы, начинающиеся с точки, то на это есть GLOB_DOTS, временно устанавливаемая с помощью (D): * выведет все файлы, не начинающиеся с точки, *(D) — вообще все.
2. Если использовать настройку NULL_GLOBS, то в пустом каталоге она раскроется в пустой список (по умолчанию это ошибка, предотвращающая запуск команды вообще, хотя можно сделать и как в bash). Локально это устанавливается с помощью (N), комбинация с (D) позволяется: *(ND).
3. Тоже есть методы обхода: про скрытые файлы я сказал в п. 1., ограничится только каталогами можно с помощью (/), но если нужно сделать что‐то вроде «каталоги перед файлами», придётся иметь дело с (oe)/(o+) и shell код внутри/свою функцию выше.
4. Сортировка убирается с помощью (oN).
5. Чтобы сделать -L, придётся привлекать (e)/(+) и писать shell код внутри/свою функцию выше, но это возможно.
6. -xtype/-follow соответствует применению (-) для всех последующих квалификаторов.

zsh здесь медленнее, да. Но со звёздочкой можно сделать то, что find и не снилось, хотя кое‐где с find то же самое будет удобнее.

Так что прежде, чем говорить «нет, и не будет», попробуйте zsh. *(D/) набирается гораздо быстрее, чем find -type d, используется легче, а на сколько мс это будет медленнее отрабатывать на моих задачах без разницы.

[drBatty]

ZyX
все это так. Но мы про bash. ваши примеры познавательны, но у меня сработают только дома, в продакшене - увы.

[drBatty]

1. Если вы имеете ввиду файлы, начинающиеся с точки, то на это есть GLOB_DOTS, временно устанавливаемая с помощью (D): * выведет все файлы, не начинающиеся с точки, *(D) — вообще все.

нет. Я имею ввиду то, что в некоторых случаях command * обрабатывает не все файлы, которые _должна_ обрабатывать. А .* она и не должна.
И нигде в мануалах я не нашёл того, что command * _не_ имеет ограничения на количество файлов. А вот, ЕМНИП, для xargs это явно прописано. И действительно, даже когда * у меня не сработала, вариант с xargs отлично справился.

zsh здесь медленнее, да. Но со звёздочкой можно сделать то, что find и не снилось, хотя кое‐где с find то же самое будет удобнее.
Так что прежде, чем говорить «нет, и не будет», попробуйте zsh.

это мне ещё info Z Shell надо осилить, tl;dr.
Зачем это надо, если info find я _уже_ осилил, да ещё и find быстрее? И да, info find таки ещё и покороче будет.

а на сколько мс это будет медленнее отрабатывать на моих задачах без разницы.

а это смотря где применять. Посмотрите на subject - подразумевается, что ТС часок помучается, а потом его скрипт будет годами работать без постороннего усилия. И вполне возможно, что этому скрипту придётся обрабатывать не 10 и не 110 файлов...

[t.t]

вариант с rsync-ом не перемещал файлы в нужную директорию

про удаление файлов после копирования rsync-ом я написал в первом своём посте·

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

[drBatty]

вариант с rsync-ом не перемещал файлы в нужную директорию

про удаление файлов после копирования rsync-ом я написал в первом своём посте·

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

ИМХО это всё часть какой-то другой задачи. Возможно там вообще mv не к месту...

[t.t]

ИМХО это всё часть какой-то другой задачи. Возможно там вообще mv не к месту...

Какова бы ни была общая задача, копирование вместо переименования в пределах одной ФС она оправдать не может по определению. Или я что-то подзабыл, и rsync в этом случае жёсткие ссылки использует?..

[drBatty]

Какова бы ни была общая задача, копирование вместо переименования в пределах одной ФС она оправдать не может по определению.

очевидно - да.
но это всё теория. Напомню первый пост:

Есть каталоги /home/vova/out/ и /home/goga/out/, нужен скрипт, котрый бы проверял каталог /home/vova/out/ на наличие в нем файлов (любых, скрытые не нужны) и перемещал бы их в /home/goga/out/. В дальнейшем этот скрипт планирется запускать cron-ом каждые 15 минут.

ИМХО решение с find самое оптимальное. А имеющиеся у нас решения с mv не удовлетворяют условию, т.к. ничего не проверяют(а вдруг файлов нет?). rsync вроде-бы имеет какие-то плюсы, если в source_dir много старых файлов, которые очевидно переносить никуда не нужно, а нужно просто удалить(особенно если в target_dir вообще много файлов). Хотя тут логичнее использовать mv -u.

[t.t]

А про find я ничего и не говорил. Повторюсь: если мне не изменяет память и rsync действительно _копирует_ данные, то в пределах одной ФС такое решение неоправдано по определению. И по скорости выполнения; и по отказоустойчивости в случае, скажем, нехватки места на ФС; и по нескольким менее значимых параметрам типа износа носителей. Вы пытаетесь это утверждение оспорить? Если да, то не вижу Ваших аргументов; а если нет, то не понимаю, о чём разговор. (:

[drBatty]

что касается rsync, это было не мое предложение, я предложил find. Лично я применяю rsync только удаленно. А мой вопрос связан только с академическим интересом. Спасибо за ответ.

[ZyX]

1. Если вы имеете ввиду файлы, начинающиеся с точки, то на это есть GLOB_DOTS, временно устанавливаемая с помощью (D): * выведет все файлы, не начинающиеся с точки, *(D) — вообще все.

нет. Я имею ввиду то, что в некоторых случаях command * обрабатывает не все файлы, которые _должна_ обрабатывать. А .* она и не должна.
И нигде в мануалах я не нашёл того, что command * _не_ имеет ограничения на количество файлов. А вот, ЕМНИП, для xargs это явно прописано. И действительно, даже когда * у меня не сработала, вариант с xargs отлично справился.

zsh здесь медленнее, да. Но со звёздочкой можно сделать то, что find и не снилось, хотя кое‐где с find то же самое будет удобнее.
Так что прежде, чем говорить «нет, и не будет», попробуйте zsh.

это мне ещё info Z Shell надо осилить, tl;dr.
Зачем это надо, если info find я _уже_ осилил, да ещё и find быстрее? И да, info find таки ещё и покороче будет.

Всё здесь просматривать не надо: львиная часть это автодополнение и всякие странные вещи вроде ztcp, zftp, календарь, часть слабо отличается от bash.

А «find быстрее» только пока не надо сделать что‐то вроде

(Created by format.vim)

GLOBAL=0 for f in * ; do (( ++GLOBAL )) done

Я уже как‐то наизвращался с этим в bash с её «each command in a pipeline is executed in its own subshell». Ещё в bash не работает read -d$'\0', что тоже нехорошо сказывается на взаимодействии с find.

[drBatty]

А «find быстрее» только пока не надо сделать что‐то вроде

я не очень понял, что это, и зачем это надо?

Я уже как‐то наизвращался с этим в bash с её «each command in a pipeline is executed in its own subshell».

опять-таки не понимаю, в чём у вас были проблемы.

Ещё в bash не работает read -d$'\0', что тоже нехорошо сказывается на взаимодействии с find.

это типа xargs -0 ?
тоже непонятно, зачем это нужно. Можно пример из жизни?

[/dev/random]

Я уже как‐то наизвращался с этим в bash с её «each command in a pipeline is executed in its own subshell».

Извращались, извращались... а до того, что это настраивается, не доизвращались.

[ZyX]

А «find быстрее» только пока не надо сделать что‐то вроде

я не очень понял, что это, и зачем это надо?

Имеется ввиду, что мне надо было изменить глобальную переменную основываясь на данных, выдаваемых find (или содержащихся в файлах, им найденных).

Я уже как‐то наизвращался с этим в bash с её «each command in a pipeline is executed in its own subshell».

опять-таки не понимаю, в чём у вас были проблемы.

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

Ещё в bash не работает read -d$'\0', что тоже нехорошо сказывается на взаимодействии с find.

это типа xargs -0 ?
тоже непонятно, зачем это нужно. Можно пример из жизни?

Предполагая, что в именах файлов может быть новая строка, а вам не нравиться идея написания скрипта, который не обрабатывает данную ситуацию, это нужно в любой ситуации когда бы вы написали find ... | while read. Я это всегда решаю с помощью for i in {glob} и наличие у zsh множества различных расширений для этих шаблонов мне сильно задачу облегчает. Конкретных примеров я не назову, так как не могу сказать, где в моих скриптах имеет смысл заменить шаблон на find.

Я уже как‐то наизвращался с этим в bash с её «each command in a pipeline is executed in its own subshell».

Извращались, извращались... а до того, что это настраивается, не доизвращались.

Может и настраивается. Но в zsh — по умолчанию.

[drBatty]

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

может быть вы пытались сделать что-то вроде

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

while read string; do
  read X # это НЕ работает. В смысле читает из file.txt, а не из консоли.
  passwd me # тоже не работает
done < file.txt

а переменные в цикле ничем не хуже тех, что не в цикле.

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

мне не нравится, когда у файлов такие имена. То, что EXT3,4 позволяют любые байты кроме / & \0 вовсе не повод их использовать. С пробелами проблем обычно нет, но вот всякие \n и \r корёжат даже вывод ls. Зачем это надо?

[ZyX]

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

может быть вы пытались сделать что-то вроде

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

while read string; do
  read X # это НЕ работает. В смысле читает из file.txt, а не из консоли.
  passwd me # тоже не работает
done < file.txt

а переменные в цикле ничем не хуже тех, что не в цикле.

Нет, я про

(Created by format.vim)

ABC=1 echo 1 | while read i ; do (( ABC+=i )) echo $ABC done echo $ABC

. Если запускать это в bash, то получите 2, затем 1. Если в zsh, то получите 2, затем 2. А про то, что в этом случае можно использовать < <() я тогда просто не знал (точнее, не знал про <()) (впрочем, идея использования < … после цикла мне всё равно не нравиться: что будет в $i мне надо знать когда я вижу read, а не когда я вижу конец цикла).

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

мне не нравится, когда у файлов такие имена. То, что EXT3,4 позволяют любые байты кроме / & \0 вовсе не повод их использовать. С пробелами проблем обычно нет, но вот всякие \n и \r корёжат даже вывод ls. Зачем это надо?

При чём тут ext*? Это поддерживает, насколько я знаю, даже NTFS, — любая ФС, соответствующая POSIX. И скрипты тоже должны поддерживать пока это не убрали из стандарта.

[drBatty]

Если запускать это в bash, то получите 2, затем 1.

да. на первый взгляд неожиданно. Но таки логично...

При чём тут ext*? Это поддерживает, насколько я знаю, даже NTFS, — любая ФС, соответствующая POSIX. И скрипты тоже должны поддерживать пока это не убрали из стандарта.

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

[/dev/random]

Если запускать это в bash, то получите 2, затем 1. Если в zsh, то получите 2, затем 2.

Поищите опцию lastpipe в man bash.

[Bizdelnick]

в zsh — по умолчанию

А если zsh настроен не по умолчанию?

[ZyX]

в zsh — по умолчанию

А если zsh настроен не по умолчанию?

Именно для этого в начале каждой функции принято писать emulate -L zsh. Насчёт неумолчальной настройки для скриптов: такого быть не должно. .zshrc где все настройки обычно располагаются не загружается для скриптов, а люди, помещающие такого рода настройки в ~/.zshenv или даже в /etc/zshenv, являются сами себе очень злобными буратинами. Да и возможность написать тот самый emulate [-L] zsh никто не отменял.

[ZyX]

Если запускать это в bash, то получите 2, затем 1. Если в zsh, то получите 2, затем 2.

Поищите опцию lastpipe в man bash.

Меня смущает «and job control is not active». То есть я получаю разный результат в интерактивной и неинтерактивной оболочке. Оно мне надо? Я изредка могу и сложный скрипт в одну строку написать.

[/dev/random]

Меня смущает «and job control is not active». То есть я получаю разный результат в интерактивной и неинтерактивной оболочке. Оно мне надо? Я изредка могу и сложный скрипт в одну строку написать.

Заключите всю строку в скобки. Это создаст для команды неинтерактивную подоболочку.

[ZyX]

Меня смущает «and job control is not active». То есть я получаю разный результат в интерактивной и неинтерактивной оболочке. Оно мне надо? Я изредка могу и сложный скрипт в одну строку написать.

Заключите всю строку в скобки. Это создаст для команды неинтерактивную подоболочку.

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

[/dev/random]

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

Разумеется. Но вы же писали:

Я изредка могу и сложный скрипт в одну строку написать.

А в пределах этой "одной строчки" всё будет доступно.

Кроме того, обратите внимание: введите в zsh команду sleep 100 | read foo и попробуйте "заморозить" её через ^Z. Вы получите сообщение: zsh: job can't be suspended. Так вот, это не просто случайный баг. Это следствие вышеописанного поведения zsh. Принципиально несовместимые фичи: либо управление задачами, либо получение переменных из пайпа. Разработчики zsh предпочли в таких случаях отключать управление задачами. Да, в bash тоже есть случаи, когда оно отключается, но их гораздо меньше. И знаете, я предпочитаю, чтобы оно работало как можно в большем числе случаев. Меня и в баше-то случаи его отключения раздражают, а с вашим zsh я бы повесился.

[ZyX]

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

Разумеется. Но вы же писали:

Я изредка могу и сложный скрипт в одну строку написать.

А в пределах этой "одной строчки" всё будет доступно.

Кроме того, обратите внимание: введите в zsh команду sleep 100 | read foo и попробуйте "заморозить" её через ^Z. Вы получите сообщение: zsh: job can't be suspended. Так вот, это не просто случайный баг. Это следствие вышеописанного поведения zsh. Принципиально несовместимые фичи: либо управление задачами, либо получение переменных из пайпа. Разработчики zsh предпочли в таких случаях отключать управление задачами. Да, в bash тоже есть случаи, когда оно отключается, но их гораздо меньше. И знаете, я предпочитаю, чтобы оно работало как можно в большем числе случаев. Меня и в баше-то случаи его отключения раздражают, а с вашим zsh я бы повесился.

Как я понял, это относится только к shell коду, sleep 100 | less ставится на паузу нормально. Никогда не встречал с необходимостью сделать паузу для него, но интересно, про какие случаи вы говорите? Я не говорю, что их нет, но я их не встречал даже в zsh (за исключением разницы между интерактивной и неинтерактивной оболочками, и то в этом случае ничего полностью не отключается, просто нельзя использовать jobs, особенно jobs | smth).