В руководствах Bash упоминается, что команда "unset name[N]" выполняет удаление элемента массива, например:https://www.gnu.org/software/bash/manual/html_node/Arrays.ht...
The unset builtin is used to destroy arrays.
unset name[subscript] destroys the array element at index subscript.https://tldp.org/LDP/abs/html/arrays.html
unset colors[1] # Remove 2nd element of array.
https://www.opennet.ru/docs/RUS/bash_scripting_guide/c12790....
unset colors[1] # Удаление 2-го элемента массива.
Данное описание не соответствует действительности, так как элемент массива для корректного удаления необходимо заключить в кавычки '..'
Для конкретного примера:
unset 'colors[1]'
Если не использовать кавычки, то bash попытается сделать расширение имени и заменит "unset colors[1]" на "unset colors1". Проверить это можно выполнив:
> touch colors1
> bash example_25_3.sh
URL:
Обсуждается: https://www.opennet.ru/tips/info/3177.shtml
А где этот загадочный example_25_3.sh взять?
зочем ? на баше скрипты ни пишут, только sh
Кто не пишет? Среднестатистический Anon пишет.
Умные аноны не пишут же.А статистика в среднем печалит - вы кстати посмотрите, за кого они голосуют...
Это когда для развлечения. А пишут на развитых инструментах. Ограничение себя неразвитыми - знак неудобных особенностей. В том или ином.
Умные перекладывают всё, что можно, на awk, sed, numfmt и т.д., оставляя оболочке только установку конвеера.
Собственно пример. Не скажу что работает как часы - у меня только на одном компе нормально.
https://unixforum.org/viewtopic.php?f=12&t=150895
Вы удивитесь, но в 90% скриптов .sh в качестве интерпретатора установлен /bin/bash и в большинстве систем /bin/sh ссылается на /bin/bash ;-) Да и само расширение sh не обязательно должно быть, так как без специальных включалок/отключалок ядро заходит в файл читает первую строчку и смотрит что там указано пытаясь выполнить указанный интерпретатор ....Если поставить включить поддержку форматов, то можно к примеру на 32бит запускать arm и x64 да и всё что душе угодно.... было бы указано что и чем есть...
> Если поставить включить поддержку форматов, то можно к примеру на 32бит запускать arm и x64 да и всё что душе угодно.... было бы указано что и чем есть...Будьте любезны, подскажите как на i386 железе без средств виртуализации запустить x86-64 приложение?
>> Если поставить включить поддержку форматов, то можно к примеру на 32бит запускать arm и x64 да и всё что душе угодно.... было бы указано что и чем есть...
> Будьте любезны, подскажите как на i386 железе без средств виртуализации запустить x86-64
> приложение?Поясните пожалуйста где Я говорил о том что это будет без средств виртуализации ??? по сути дела что бы запустить любую иную архитектуру на машине должен будет стоять binfmt-support и qemu-static- который будет выступать в роли интерпретатора и позволит выполнять всё что нужно... почему так: потому что большая часть кода иной архитектуры будет интерпретироваться и за счёт этого будет низкая производительность ...
> в качестве интерпретатора установлен /bin/bash и в большинстве систем /bin/sh ссылается на /bin/bash ;-)нет. твой локалхост на убунте не большинство систем
>> в качестве интерпретатора установлен /bin/bash и в большинстве систем /bin/sh ссылается на /bin/bash ;-)
> нет. твой локалхост на убунте не большинство системВот как раз админы локал хостов что угодно могут ставить xD
> зочем ? на баше скрипты ни пишут, только shpulseaudio-ctl, bashmount, imgurbash2
Джентельмены верят друг другу на слово.
Автор так-то указал ссылку в тексте.
"программистов", чьи скрипты не проходят через
https://sourceforge.net/projects/checkbaskisms/нужно пороть.
гоните их, насмехайтесь над ними.
борьба с башизмами -- это что-то из времен, когда баш не был предустановлен на каждом утюге?# checkbashisms.perl
# (C) Copyright 1998-2003 Richard Braakman, Josip Rodin and Julian GilbeyСовременные скрипты следует прогонять через современные линтеры, viz. ShellCheck.
> баш не был предустановлен на каждом утюге?аргумент не очень веский.
винда предустановлена на 90% продаваемых ноутбуков, и дальше что ?
Портабельность - это то, что требует аргументов. Отсутствие портабельности - это состояние по-умолчанию, и аргументов не требует. Любая программа по умолчанию непортабельна, а переход на портабельность требует анализа и аргументов: нужна ли она на самом деле, какая с этого выгода, нельзя ли портабельность отдать на откуп даунстриму, чтоб апстрим не заморачивался ноль-процентной экзотикой и т.д. Причем ответы на эти вопросы следует получить не один раз, а задаваться ими буквально для каждого скрипта.Так что жду твоих аргументов, почему с "башизмами" нужно бороться. Зачем нужно, кому нужно, какая с этого выгода и далее по списку.
Для утюгов - только dash, и это при условии, что для coreutils есть место. Иначе busybox.
И ещё, к сожалению, писать без башизмов почти невозможно, если у вас bash по дефолту и вы пользуетесь "info bash". Потому что некоторые из башизмов занесены в раздел Basic Shell Features - brace expansion, process substitution (должно быть в Bash Features). А опция --posix только отключает POSIX-несовместимости, поддержка расширений никуда не девается.Единственный вариант писать без них - тестировать на dash, руководствуясь man dash.
Ну или вот сам стандарт: https://pubs.opengroup.org/onlinepubs/9699919799/toc.htm
Он же: https://standards.ieee.org/standard/1003_1-2017.html
> Специфичные особенности удаления элементов массивов в BashИнтересно, чем отличаются "особенности" от "специфичных особенностей"? Более специфично особенным заголовком для статьи?
В русском переводе Advanced Bash-Scripting Guide, на который явно ссылается автор топика, заголовок обсуждаемого примера переведён как "Некоторые специфичные особенности массивов".Другое дело, что в оригинале это "Some special properties of arrays". Но это Вам к изначальному переводчику или внести свой вклад в исправление и актуализацию перевода.
> В русском переводе Advanced Bash-Scripting Guide, на который явно ссылается автор топика,
> заголовок обсуждаемого примера переведён как "Некоторые специфичные особенности массивов".
> Другое дело, что в оригинале это "Some special properties of arrays". Но
> это Вам к изначальному переводчику или внести свой вклад в исправление
> и актуализацию перевода.Спасибо за разъяснения. Значит должно было быть "Некоторые особенные свойства массивов".
Интересно. Натыкался на подобное поведение с переменными.Если я правильно понимаю, то в переводе уже поправили. А в оригинал заслали правку? Не факт, что в следующий раз перевод буду читать.
Для доступа к элементам массива ВСЕГДА используйте полную запись ${colors[1]}. А лучше вообще не нужно использовать массивы в bash т.к. будет что-то типа этого: ${colors[${index}]}. Если нужны массивы используйте для этого, что-нибудь более подходящее, ИМХО.
https://www.gnu.org/software/bash/manual/html_node/Arrays.ht...When using a variable name with a subscript as an argument to a command, such as with unset, without using the word expansion syntax described above, the argument is subject to the shell’s filename expansion. If filename expansion is not desired, the argument should be quoted.
Во-первых, что за такая операция "удаление элемента массива"? Сам придумал?
Во-вторых, доступ к элементам массива в БАШЕ осуществляется через ...
вот так: unset ${colors[1]}, более того, это тоже моветон,
в БАШЕ к элементам лучше обращаться по индексам: unset ${array[@]:1:1}
unset colors[1] удаляет значение переменной с именем colors[1]
Хотя пофиг, интересен тайный смысл "удаление элемента массива"? Где профит?Проход по массиву пока есть элементы тоже бред, с лишней операцией удаления.
Как хранилище нужных данных? Так почему не проверять на нужность
перед добавлением в массив, а не удалять после?Во время выполнения скрипта память не освобождается, это не ассемблер.
> в БАШЕ к элементам лучше обращаться по индексам: unset ${array[@]:1:1}А вот это уже черезжопа. "Как в мире возможно", чтобы _нормальное_ обращение по инжексу было моветоном?
bash "[@]:1:1" - даже гугл такого не знает