В bash есть ассоативные массивы (словари), ни пизди!
$ declare -A ary
$ ary[hello]=world
$ echo ${ary[hello]}
Но для скриптинга в сколько-нибудь серьёзном масштабе баш всё равно подходит чуть более, чем никак.

>>1113259 (OP)
Боже, спаси и сохрани!

Пожалуйста, никогда не используйте ш для скриптов, бога ради.

Спаси господь ваши души!

>>1113452
Ты лучше говори, что использовать.
Что говно и так известно более или менее.
Ну используют в каком-нибудь qbs для скриптования JS, но, знаешь, легче как-то нихуя не стало.

>>1113472
Процессами рулить. Пайпы, экзит коды, параллельный/последовательный запуск, ssh, автоматическое гашение чайлдпроцессов в trap. Если нужно что-то посчитать или обработать - пишешь на питоне, но в питоне процессы не спавнишь, а даёшь ему поедать stdin/cmdline и срать в stdout/exitcode. Потом это всё склеиваешь башем.

>>1113485
Или на руби.

>>1113259 (OP)
Анончики, есть у кого-то хороший справочник по bash'у ?

>>1113716
Тоже задавался этим вопросом, полезней всего оказалось прочитать ман (https://www.gnu.org/software/bash/manual/bashref.html) и наставить в нем закладок. За операторами сравнения и правилами развертывания переменных постоянно приходится лазать.

>>1113721
Скобка прилипла, нутыпонел

>>1113721

> За операторами сравнения и правилами развертывания переменных постоянно приходится лазать.

Для баша нормальный линтер не завезли?

>>1113721
Спасибо

>>1113716
>>1113721
man bash
info bash

>>1113485
Стало нужно разделить лог-файл по 100M, не разрывая записи по частям. Пришлось делать на Питоне.

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

>>1113749
Не нужен. Превратится во всякие бесконечные exec('program', 'arg').

>>1113724
Откуда у тебя линтер на произвольном серваке, болезный?

>>1113759

Линтер на соснольку прикрутить - сорт оф изврат, но думаю возможно; но речь не о этом - линтер здорового человека подключается как плагин для текстового редактора.

>>1113748
о, ты классный и питон - мощь
split -C

>>1113748
https://pastebin.com/8X2m2yzM
Сколько строк на питоне вышло?

>>1113778
на моем баше вышла 1 строка..
на твоем по видимому нужно больше

>>1113779
Да-да, выучил стандартный набор утилит. Молодец у мамы сегодня.

>>1113782
не ну конечно пыхтеть городя лесенки из циклов и ifов на баше гораздо веселее

>>1113784
Ну вот захотелось попыхтеть, ну что ты как не родной.
+ Что если нужно разбить по количеству символов, а не байт?
+ Что если в системе не установлен split?

>>1113749
Были, как с нуля - powershell, так и прикручиванием сбоку - xonsh.
>>1113758
Всё не так грустно http://amoffat.github.io/sh/

>>1113716
http://mywiki.wooledge.org/BashPitfalls

А скажите-ка честно, не кажется ли вам, что пора уже выкинуть coreutils/GNU software и написать этому барахлу замену?

>>1114667
Что с ними не так? Работает - не трогай.

>>1113770
Записи многострочные, вряд ли split их поймёт. Параметр -t не очень помогает.

>>1113778
Примерно столько же (ещё не дописал, лол). Суть такова: считываем файл, разбиваем на записи регулярным выражением, считаем размер строк, и, покуда не превышает, пишем в файл. Потом открываем новый файл и пишем дальше в него.

>>1114667
Выкинуть не выйдет, но попробовать заменить стоит. Нужно только грамотно спроектировать, и чтобы не было заметно большой разницы.

ОП

>>1114943
В принципе, можно просто написать какую-нибудь утилиту, которая заменит собой сразу несколько других утилит. Всё то же самое - разбиение файлов с различными условиями, обработка регулярных выражений и тому подобное. и получим в итоге перл

*ОП

>>1114667
Ну я бы попробовал что-нибудь новое. Например меньше заучиваний и RTFM в пользу интуитивности. Меньше абракадабры с символами. Меньше всякой ерунды вроде fi, esac. Больше всякого для работы со строками. Возможно даже альтернативные нетерминальные версии с нормальным копированием на ctrl+c. Нормальный встроенный парсер cmdline вместо убогости getopts.

>>1113758
Если использовать готовые языки, то да.
илсЕ
Если использовать специализированный язык, в котором внешние программы и пути вызываются без скобок, то нет.
илсЕ

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

>>1114997
А как это будет выглядеть?

ОП

>>1114942
>Записи многострочные, вряд ли split их поймёт. Параметр -t не очень помогает.
повторюсь, тк ты тупенький
split -C

>>1115037
только сплит будет частью конвеера, но все равно это будет 1 строка..

>>1114971
>Меньше абракадабры с символами.
нормальные люди не работают на шелле со строками, хотя это и можно делать..
правильный путь - юзать баш для работы с файлами, а содержимое файлов обрабатывается отдельными текстовыми процессорами типа sed, awk и кучи другого
в винде же из cmd вызывались макросы на jscript написанные для обработки строк, хотя на cmd и есть весь набор трюков для работы со строками

>>1115047
Дык sed/awk это ещё большая абракадабра как по мне. Я бы вообще инлайнил прямо в язык шелла какой-нибудь питон/луа, да хоть тот же жс, примерно как делают asm-вставки для сишного кода.

>>1115037
Как split -C разберёт, где начало многострочной записи, а где конец? Он должен иметь какое-то представление о формате, в котором записи находятся. Записи обрубать нельзя.

>>1115057
sed годная тема, на самом деле. Если возможностей его регулярных выражений не хватает, то можно запустить perl с какими-то ключами и получить всю мощь его регулярок.

Офигеваю с этого. Пользуюсь и офигеваю.
$(echo ${files}|tr ' ' '\n')

Имена файлов хранятся в массиве
@
${array[@]} выдаёт имена файлов одной строкой
@
Команда, которой их нужно передать, принимает их последовательно
@
command <(for i in ${array[@]}; echo $i; done)
@
2018-й год

Какой редактор/IDE может поддерживает навигацию по функциям? Eclipse по идее умеет, но его нормально настроить, чтобы в нём вообще работать можно было - тот ещё ад.

IF
@
FI

>>1115413
CASE
@
ESAC

>>1115618

DO
@
DONE

>>1115622
Название книги в магазине
@
Изучай bash
@
По бугурт-тредам

Кто-нибудь подобную няшу использовал?
https://github.com/tdenniston/bish
https://github.com/BYVoid/Batsh

>>1114850
Много чего не так, почти всё устарело как для 2018 года.

Не стандартизированы подходы к парсингу командлайн параметров. Где-то -of=outfile, где-то --file outfile, где-то просто outfile. Разве это нормально?

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

Элементарные вещи считаются опциональной роскошью: буфер обмена со слотами быстрого доступа и историей, история директорий, регэкспы а не вайлдарды, быстрый интерактивный фаззи-сёрч по индексу файловой системы.
Превьюшки. Ничего бы концептуально не сломалось от отображения картинок в прямоугольных блоках mn знакомест.

Уродливые сокращения типа однобуквенных параметров (-p), операторов [ -e ... ] - это пережитки. Будь в баше нормальный автокомплит можно было бы нажимая столько же символов набирать читаемые команды. Буфер со списком автодополнений под строкой с промптом, автокомплит по пробелу - и тебе уже не надо запоминать флаги.

Ещё меньше надо было бы запоминать если бы в конфигурационные утилиты был добавлен интерактивный режим, наподобие виндового netsh.


Лично меня люто бесит когда какая-то консольная окаменелость из 70-х транкейтит длинные поля для того, чтобы впихнуть таблицу в 80 символов.
В браузере длинные строки конечно тоже транкейтится, но я могу увеличить размер окна, или выделить этот кусок текста мышкой, скопировать, и скопируется строка полностью. А в консоли я могу о таком только мечтать. Всех всё почему-то устраивает.

Даже веб-макаки давно осознали, что смешивать данные с их графическим представлением нехорошо.
Графические рюшечки, цвета, локализация, обрезка под ширину экрана - это то, что должно происходить один раз, непосредственно перед отображением. А в конвейере между командами должны бегать чистые структурированные данные в канонической форме. Ну чтобы всякие ls, find, ps, lsof, и пр. выплёвывали валидный CSV. И соответственно чтобы были утилиты, понимающие CSV, - что в первой строке имена колонок, умеющие эскейпить и анэскейпить, и т.д.

Говоря о структурированных данных я имею в виду не объекты в ООП понимании. Достаточно признать, что списки, списки записей/таблицы, мапы, деревья, графы - это объективная реальность, и сделать их first-class citizen, создать набор инструментов для полноценной работы с ними. List editor, tree navigator, graph editor - такого уровня абстрации.

Представь, ты редиректишь вывод ls в интерактивный table viewer открывается что-то типа панели двухпанельного файлового редактора, в этой панели ты можешь сортировать файлы, добавлять и снимать выделение по маске. А потом нажать энтер и отфильтрованый список полетит дальше в конвейер. Совсем необязательно ограничиваться файлами, записи могут быть любыми, записи из БД, процессы, ...
Табличный редактор (консольный эксель), мне тоже кажется логичной вещью, но почему-то не осилили.

Кстати почему текущая директория должна быть одна? Если бы это был полноценный стек, тогда mv и cp могли бы иметь синтаксис попроще, отправляя файлы в предыдущую директорию.
И почему текущая локация это обязательно директория, а не файл, урл, команда или список произвольных объектов?
Ничто ведь не мешало бы работать с ФС на манер JQuery - иметь массив текущих объектов, и функции для перехода внутрь, выхода наружу, фильтрации, выполнения операций над этими объектами.
Я бы с удовольствием сохранял вебмки так:
cd https://2ch.hk/b/res/<webm_thread>.html
cd https://.\.webm
cp * ~/webms/

>>1115955
Половину из этого можно реализовать сторонней утилитой, которая просто дополнит этот мир. Про хранение данных непременно в CSV - а может сразу в JSON или YML или ещё в каком вырвиглазе (в консоли будет именно вырвиглаз). Годные мысли здесь есть, потом прокомментирую, если хватит желания.

может ли питон служить заменой консольной хуйни для красноглазиков? могу пользоваться на уровне vim, grep и прочей базы, баш учить не хочу

если да, то что можно почитать на этот счет?

>>1115955
Думаю нужно не столько с флагами возиться, сколько прокачать find до уровня конструкции языка. Вот аналогия jQuery/xpath мне нравится. В конце концов, что браузерный дом дерево, что файловая система дерево.

Насчёт униформности данных, в шелле всё есть потоки байт, при выводе в терминал ещё и распознающиеся текущей локалью символы (хотя надо бы уже utf8 без лишних пре). Максимально универсально. Я бы затребовал от каждой утилиты иметь ключ к примеру --json, для чисто машинной обработки. CSV сильно ограниченный формат. YAML всё-таки для человекописных конфигов, а не для обмена. Плохо что json не потоковый в отличие от ксв, зато позволяет работать с деревьями и куда более самодокументируемый. Вывод в терминал в текущем виде меня в целом устраивает, к тому же он относительно хорошо работает через сеть.

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

>>1116071
В питоне сложные вещи делаются просто, а простые - сложно. Но вот сам посмотри:

import subprocess
print(subprocess.call('ls', '-l').stdout)

при том что stdin/stderr отцеплены, в баше же

ls -l

и всё. Какой-нибудь

ls -l | grep lol

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

>>1116084

спасибо, а где можно почитать вот про именно такой питон?

>>1116084
А почему нельзя использовать os.system()?

И есть ещё IPython

>>1116100
Там куча легаси в питоне, которую никто не удалит, так как это стдлиба и много кода уже на ней завязано. Даже я ошибся, надо уже не subprocess.call, а subprocess.run.

Ну вот и попробуй пописать башскрипты в ipython. ls в grep направить, и записать результат в файл.

>>1116084
Можно сделать няшную обёртку оператора | (bitwise or)

>>1116108
Хорошо. Как мне тогда сделать пайп из stderr в stdin? Как мне записать stderr/stdout в два разных файла/сабпроцесса?

>>1116111
Я не вдавался пока в подробности, просто вижу, что отсутствие удобных в использовании библиотек вовсе не означает невозможность написать их.

>>1116113
Конкретно в питонах, без препроцессинга, как я и говорил уже выше в треде >>1113758
Лучше посмотреть как минимум в сторону языков с бесскобочным вызовом функций.

>>1116081
>Ходить по урлам не поддерживаю.
Познакомся с xidel - http://www.videlibri.de/xidel.html
Там по сути именно такой подход - список урлов является текущим состоянием, и он пропускается через цепочку фильтров и трансформаций.
И это работает охуенно.
Если добавить к этому всему интерактивность, с пошаговым выбором и выполнением ступеней конвейера, выйдет очень мощный инструмент.

>>1116136
Выглядит неплохо, но где собственно cd?
https://asciinema.org/a/96613?theme=monokai&size=medium&autoplay=1&speed=1.5

Ещё я немного не понимаю, зачем мне собственно ходить по урлам. Если очень хочется - можно примонтировать что-то удалённое как файловую систему и просматривать обычными ls/cd/cat/less. Даже часть апи ядра выставлена в виде файлов. От шелла нужно только запуск программ, работа с файлами и собственно кручение-верчение пайпами между процессами и экзиткодами.

>>1116151
Одна из причин почему на перле так много можно сделать в одну строку в том, что там есть дефолтная переменная $_ ( https://perlmaven.com/the-default-variable-of-perl ).
Она позволяет во многих случаях пробросить результат одной команды на вход другой неявно.

$PWD похожа на урезанную $_, с тем ограничением, что в неё можно сохранять только путь.

Это хорошо работает для связки cd-ls. Если бы текущий путь надо было писать каждый раз заново, или явно сохранять в переменную то можно было бы сойти с ума.

Но для других связок это работает не так хорошо.
Например я работаю с REST-сервисом, и хочу сделать GET, модифицировать данные, и заPOSTить их обратно.
Мне приходится писать урл в команде два раза.
Это неудобно и сводит с ума. Конечно есть выход - написать специализированный шелл, работающий с REST. В этом шелле будет не $PWD, а $PWU - present working URL, и это заметно облегчит работу.

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

Есть и другая причина, по которой пишут новые шеллы - поддержка других языков, например python, js, sql. Но это избыточный труд. REPL, интегрированный с текстовым редактором, всегда лучше. Просто переключаешь синтаксис автокомплита и интерпретатор с баша на другой. И имеешь все прелести полноценного текстового редактора, а не очередной обрубок.

>Если очень хочется - можно примонтировать
Просто взять и примонтировать в общем случае нельзя.
Не всё укладывается в файловую иерархию. Например я ввожу поисковый запрос в гугле - откуда и куда я попадаю? Или вот я хочу найти все аудиозаписи, помеченные "tag1", но без "tag2" - какой путь соответствует этому контексту? Чтобы интерактивно разложить список контактов в чате по группам - тоже монтировать список контактов в ФС?

>>1117051
Обычно я просто тесты пишу в таких случаях. Вообще рест уже устарел, уже графкул и там нельзя ls/cd, там скорее упрощённый SQL. Исключение — это если ты пилишь какую-то популярную платформу, у которой уже миллионы пользователей что вряд ли.

> запрос в гугле
> найти все аудиозаписи
> список контактов в чате
Ну да, какого хрена баш не умеет котиков нейронками распознавать? Давно пора, 2к18 на дворе!

>>1117108
Если я не могу в консоли эффективно поменеджить свою тегированную аудиоколлекцию, или сделать запрос в гугле, то стоит задуматься, правдива ли легенда, что доминирование GUI-интерфейсов вызвано безголовостью 95% юзеров, а выбор павер-юзера это всегда консоль.
Может это консольные инструменты отстали от графических и не отвечают вызовам времени?

Одно из явных преимуществ GUI это реюзабельные компоненты, вроде текст инпут, grid или tree. У юникс-дедов такого не было, никаких фреймворков, минимум библиотечных функций. Они хуячили for-ами и радовались.

Недавно решил из любопытства посмотреть, как tree и pstree выводят древовидную структуру.
Оказалось, что вывод в обоих случаях навелосипежен:
https://fossies.org/dox/pstree-2.39/pstree_8c_source.html (PrintTree)
https://github.com/execjosh/tree/blob/master/tree.c (indent, r_listdir в unix.c)
В tree даже есть несколько режимов вывода, включая json и html, но этот функционал конечно же реализован под конкретные нужды, делать абстрактную реюзабельную версию автор не стал.

Поразила воображение функция patmatch в https://github.com/execjosh/tree/blob/master/tree.c
До этого я по наивности был уверен, что уж для матчинга вайлдкардов-то библиотечная функция есть.
Но нет, видимо древние программисты считали что DRY - это для слабаков.

Конечно же появляются замечательные инструменты для работы с о структурированными даными -
https://stedolan.github.io/jq/tutorial/ , https://csvkit.readthedocs.io/en/1.0.2/ , фреймворки и компоненты для построения интерактивных приложений - https://github.com/junegunn/fzf , https://github.com/jonathanslenders/python-prompt-toolkit
Они прекрасны, но это как склепать стартап на коленке, а потом написать фреймворк для его разработки. Поздно, теперь всё надо только всё переписывать.

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

Посоны. Задам тупой вопрос, но все же. Насколько я понимаю, после for двойные скобки - это не те двойные скобки, которые позволяют выполнять арифметические операции. Так почему решили их использовать после for, а не одинарные?

>>1117458
Я тут поразмыслил ещё. Во-первых я даже и не знаю существуют ли потоковые парсеры JSON Нашёлся YAJL. Во-вторых, это нужна аж целая типизация и валидация схем чтобы состыковать друг с другом две утилиты в пайп. Можно конечно на авось, ну прямо как сейчас в баше, пробовать руками на живую и надеяться на лучшее, но как-то не круто.

С другой стороны, файловая структура вполне представима в виде подмножества XML. Например не нужны текстовые ноды, теги directory, file, symlink, атрибуты тегов = атрибуты файлов. Берёшь себе XPath и не нужны никакие find/ls/grep/wildcards/glob.

Пацаны

есть вывод параша вида
xAgarsc68J~iEzbOTuCpLQ1QUnyRY~BZAYbNxOAMviiXdLuatdd3sSRdVveuKyBwKUYNvrFJilFfZv7OmO1S91SLUBuzD~gYJ4mB4fQJHsk3qQO0S6lKgvbny~DrH~dE~QdL11A9rGq60sM_WPUZOn3LRXI6PFtLuzfbDtK3~_DP~1Is5U2TAii5iRLfK1As3oIwLletsquPc0k09Qeez2I89IRPEJiDQa5y14i15kxhmBlJ1wPC9xFVZzTyFDkYm2wLscN0kuYO3i_yZ7jmL5NhGDV9YWo7DFwmBb~mCpSAJBi95eK2g6rP057af91xb50rgskszmiGot2rBfzVqaVZ9JtKZJ5BtuZaa6MsZdt5RGaY0Oj2yqpkG~Lqhp5XP1UEt8YypSpV0oLOQTcOo58O~HI~_6HO1z7qxTdWNVAfziqsD8xHBK4buflspJh6E1sIGp0PP7lmRrdSJGukP6fGkb8dx4fdbsEqEqgFAIKOdHfMY45AFFxZTSxewcTv18cmJ3NWpwP1RuTIKIJnErHK1Y7boBoS8SNbXu69pHBlQhC4XN7dx~7uOKZbcHL5mQ3pKCRK1wfpYiUsqxmquICYYlvAwENgnZAYCWNfyClPL4FNdhV_KO44G0hnsDmBD6WN7jfAOb4U~lgWMHTOIH5NWZtqv~zsNL2Q~Q3X_P3vHLO3_iLfa57yDK4Bqc61yP63ABwsD8YDxxICK1YnNJpJAOd2TdTw~eQv12RaH3w7X4ScLLA_ITpTC_~LkuLrC4UCZqLZNSDrdnv~7SQWrMZdUN0RDSlITM49gvcjrTAPJtttEqtPK11_vyfYbX2zmOlBTDfjUsO8INlE_pmdei7HjaSI5hSxk4Hn747FRgGFW3zpVnaRAHnqhx8VmlDt5q2y3ZA0sEAP274vudv6xzzQ01m0MQt8QYYdmiRByWUfRG8mT~bEtht6nHxxRBImkT7Pg3~tpymbH5N_WdL_yucJxYfaRKkRtdjpMYmuy_IZtPk8OsDpNPEu1vdZBO9Fn0nt0Ggym9H4D9XGAo6afIasLasLGRYqMZUZiY3dFUNO14GFm9Xl2fmtGva0j7oqE

как нарисовать красивую гистограмму частоты употребления различных символов?

>>1118635
Через uniq составь данные, в потом смотри https://stackoverflow.com/questions/123378/command-line-unix-ascii-based-charting-plotting-tool

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

вроде разобрался - там баг на пнг. просто сконвертировал в tiff.

>>1113259 (OP)
Advanced Bash Scripting Guide - тру для обучения?
Или есть альтернативы на рабском?

>>1128815
Вполне сойдет, только начинай читать все таки с. beginners, не приумножай свои возможности

блять, как же я горю со скриптовых языков

Есть много файлов .ext.
К каждому из них применяется медленная однопоточная программа
for file in .ext
echo Processing $file ...
do program arg1 arg2 ...
done
Ох как надо распаллелить это дело в том смысле, что несколько потоков будут идти по списку файлов и вызывать несколько экземпляров program для обработки отдельных.
Как сделать это в bash - ума не приложу. Лезть в GNU Parallel страшно, я-то даже xargs боюсь.
Всё-таки придётся? Ну или как это можно по-другому обыграть? А в GNU Parallel-то можно будет?

>>1170433
Капчую с гейфона, под рукой нет возможности проверить. Ты полез слишком глубоко и не владеешь в должной мере башем. Зачем тебе городить цикл, когда проще будет

find . -type f -name .ext -exec program -arg1... {} ;\ & done

>>1170466
Соответствующая строка почти работает.
find .$ext -print0 | xargs -0 -I{} -P $thrnum magick convert -quality $quality -resize $width "{}" ./$dir/"$(basename "{}" .$ext).jpg"
Но basename не отрабатывает, в итоге я получаю файлы .$ext.jpg в конце. Да и следующая строка не работает как надо в этом же плане:
mkdir $dir; gfind *.$ext -print0 | xargs -0 -I{} cp "{}" ./$dir/"$(basename
'{}' ".$ext").jpg"
Т.е. опять исходное расширение не убирается.
Не понимать.
Если что, для определённого заранее file следующее работает, как ожидается:
magick convert -quality $quality -resize $width "$file" ./$dir/"$(basename "$file" .$ext).jpg"

>>1170641
Звёздочки просраны, это не может не бесить.
find •.$ext -print0 | xargs -0 -I{} -P $thrnum magick convert -quality $quality -resize $width "{}" ./$dir/"$(basename "{}" .$ext).jpg"

mkdir $dir; gfind •.$ext -print0 | xargs -0 -I{} cp "{}" ./$dir/"$(basename
'{}' ".$ext").jpg"

magick convert -quality $quality -resize $width "$file" ./$dir/"$(basename "$file" .$ext).jpg"

xargs не помещает в переменную shell'a имя файла, просто подставляет вместо строки -I.
Непонятно, однако, почему не работает ./$dir/"$(basename "file" .$ext).jpg".
Ведь вместо file должно оказаться его имя.

Короче, кратко суть проблемы.
Пусть file="a b.c"
ext=".c"
> $ echo $file | xargs -Itest echo "$(basename "test" .$ext)"
> a b.c
Говно, хотелось "a b".
> $ echo $file | xargs -Itest echo ${test%.$ext}
>
Говно, тут вообще пустой вывод.
Был вариант от find передавать аргументы куда-нибудь в вырезалку расширения через пайп, но для вырезания расширения надо в переменную забивать, а переменные юзать в многопотоке очково.
да и там -print0 с аргументом -0 xargs хорошо сочетается, с другими элементами могут быть проблемы.

>>1170641
>>1170643
Сорри, мэйт, но в этом ковырятся чет нет желания, ты максимально как-то усложнил всё. Ещё и описываешь таким слогом, что мозг ебется.

>>1170819
Время устроить здесь бложик с жалобами по поводу того, что xarg в выражения типа $(command test) не подставляет, хотя -I test задано.
Понимаешь, у меня find считывает список файлов с расширениями, заставить find обрезать всё после последней . невозможно.
Он через конвеер идёт в xargs, в котором -Ismth, т.е. smth - имя файла.
И оно передаётся проге нормально как аргyмент: "smth". Но у проги вывод задан в ./$dir/"$(basename "smth" .$ext).jpg", где $dir заранее задан и создан.
Но вот команда basename не работает.
Она, на удивление, не отрезает расширение, т.е. возвращается исходное имя с расширением, конкатенированное с .jpg.

Спащу лучше то, что оказало таки нужное действие.
Есть разрешение ext, кол-во потоков thrnum, остальное - юзелесс параметры проги.
ls | grep -F ".$ext" | sed -e 's/\.'"$ext"'$//' | xargs -Ifile -P $thrnum magick convert -quality $quality -resize $width "file.$ext" ./$dir/"file.jpg"

>>1170966
То, что ты хочешь, делается влегкую через parallel, но можно обойтись и xargs'ом, только придется немного изъебнуться:
find <....> | sed -r 'p;s,.+/([^/]+)\.[^/]+$,'"$dir/\1.jpg," | xargs -n2 -P$threads convert -quality $quality -resize $width
Регулярку не проверял, но идею, думаю, ты понял.

Возможно не совсем в тему треда, но есть ли годные книги или ресурсы по VBS? Нужно быстро вкатиться, написать shell-скриптов для гп под винду и укатиться.

>>1171434
По VBS тонны книг и все в той или иной степени годнота. На рутрекере в поиск вбей и выбирай нужную.

От себя хочу добавить, что это уже мертвый язык и лучше бы тебе задрачить powershell. Он проще. В гугле или на рутрекере набери. powershell group policy.

Пока вы тут выдумываете векторный фидонет, люди уже пилят:
http://www.oilshell.org/