После двух с половиной лет разработки опубликована (http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063....) новая версия командного интерпретатора GNU Bash 5.0 (http://www.gnu.org/software/bash/), используемого по умолчанию в большинстве дистрибутивов Linux. Одновременно состоялся (http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00064....) релиз библиотеки readline 8.0, применяемой в bash для организации редактирования командной строки.
Значительное изменение номера версии Bash связано с внесением изменений, нарушающих обратную совместимость. В новой версии переработан код, связанный с обработкой ссылочных переменных nameref, что привело к отдельным изменениям поведения при использовании nameref (например, цикл разбора имён nameref внутри функций теперь приводит к определению переменных не в локальном, а в глобальном контексте). Кроме того, по умолчанию переменные BASH_ARGC и BASH_ARGV теперь выставляются только при включении расширенного отладочного режима, что позволило избавиться от проблем с производительностью при передаче скриптами большого числа аргументов. Для работы нового выпуска необходимо наличие свежей библиотеки readline, т.е. для установке Bash 5.0 в дистрибутивах с выпусками readline до 8.0 потребуется переустановка readline или встраивание новой версии библиотеки при сборке Bash.
Из улучшений (http://git.savannah.gnu.org/cgit/bash.git/tree/NEWS?h=bash-5.0) можно отметить:
- Предложены новые переменные окружения: BASH_ARGV0 (принимает значение $0), EPOCHSECONDS (эпохальное время в секундах) и EPOCHREALTIME (эпохальное время с точностью до микросекунд);
- Во встроенную команду "history" добавлена поддержка выборочного удаления записей из БД с историей операций ("history -d start-end") и возможность указания отрицательных значений в качестве смещения первой удаляемой записи относительно конца списка (например, "-1" указывает на предыдущую команду);
- Добавлена опция "localvar_inherit", при установке которой локальные переменные наследуют значение переменный с теми же именами, определёнными в вышестоящей области видимости;
- Добавлена опция "assoc_expand_once", при установке которой оболочка осуществляет раскрытие индексов ассоциативных массивов только один раз;- Включена по умолчанию опция "globasciiranges", допускающая использование масок для определения диапазонов символов ([a-z]);
- Добавлены встроенные реализации команд rm, stat, seq и fdflags;
- Во встроенной команде "wait" обеспечена возможность ожидания замещения последнего процесса и добавлена опция "-f" для ожидания завершения процесса или работы вместо ожидания изменения состояния;
- Добавлена возможность жёсткого определения в файле
config-top.h значений $PATH и $HISTSIZE. Данные значения будут более приоритетными, чем значения из переменных окружения и могут применяться для создания ограниченных окружений;
- При автодополнении ввода теперь не учитывает регистр символов для имён функций и псевдонимов (alias), если в readline выставлен режим completion-ignore-case;- Во встроенной команде "umask" разрешено использование режимов доступа и масок, превышающих восьмеричное значение 777;
- Во встроенной команде "times" в зависимости от настройки локали теперь может выводиться не только точка, но и запятая в качестве разделителя дробных значений;
- Добавлена отключенная по умолчанию и недокументированная опция для включения отправки истории команд в syslog;
- Встроенная реализация malloc переведена на использование mmap для обеспечения запроса блоков, размером больше 128 Кб, и возможности возврата страниц памяти ядру после выполнения mfree;- В качестве индексов ассоциативных массивов теперь могут использоваться строки, состоящие только из символов пробела;- В разряд видимых переведены ранее недокументированные опции localvar_unset и progcomp_alias;
- Переменная "$_" теперь не меняет своё значение, когда shell запускает команду, выполняющую fork.URL: http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063....
Новость: https://www.opennet.me/opennews/art.shtml?num=49917
> Во встроенной команде "umask" разрешено использование режимов доступа и масок, превышающих восьмеричное значение 777Просветите, пожалуйста, как umask может быть больше 777
Обнуляется
01777
Видать, добавили поддержку Sticky bit, Set UID, Set GID, получилось 7777.
как минимум, в линуксе это работать не будет
в реализации системного вызова явно сбрасываются все биты старше 0777: https://github.com/torvalds/linux/blob/master/kernel/sys.c#L...
Скорей всего будет - пример не о том
builtins/common.c
- read_octal: allow octal numbers greater than 777 to accommodate
modes and umasks that include sticky/setuid/setgid bits. Report
and fix from Martijn Dekker <martijn@inlv.org>
/* Return the octal number parsed from STRING, or -1 to indicate
that the string contained a bad number. */
int
read_octal (string)
char *string;
{
int result, digits;result = digits = 0;
while (*string && ISOCTAL (*string))
{
digits++;
result = (result * 8) + (*string++ - '0');
if (result > 07777)
return -1;
}if (digits == 0 || *string)
result = -1;return (result);
}Было if (result > 0777)
Как верно подметил Нанобот, сисколл установки umask учитывает только 0777, так что от увеличения дополнительных бит в баше ничего не изменится.
> Как верно подметил Нанобот, сисколл установки umask учитывает только 0777, так что
> от увеличения дополнительных бит в баше ничего не изменится.я подозреваю, что существует какая-то, отличная от линукс, система, в которой существует umask с другой реализацией и для которой тоже собирается баш. возможно где-то в *bsd...
> Как верно подметил Нанобот, сисколл установки umaskumask в баше встроенный.
int umask_builtin (list) WORD_LIST *list; {...;}
>> Как верно подметил Нанобот, сисколл установки umask
> umask в баше встроенный.
>
> int umask_builtin (list) WORD_LIST *list; {...;}
>и внутри umask_builtin оно ж всё равно делает вызов ядра. а то иначе это будет бесполезная команда (например, пользователь поставит umask 022 и запустит какой-то процесс...если umask - чисто функция баша, то запущеный процесс не сможет узнать, что написал пользователь в другом процессе...чтобы оно работало так, как ожидается, нужно ядро вызывать).
я думаю, если хорошо поискать, где-то внутри umask_builtin будет вызов ядра (ну или libc)
>>> Как верно подметил Нанобот, сисколл установки umask
>> umask в баше встроенный.Ойспадя. https://lists.gnu.org/archive/html/bug-bash/2018-03/msg00083...
> и внутри umask_builtin оно ж всё равно делает вызов ядра. а то
> иначе это будет бесполезная команда (например, пользователь поставит umask 022 иТак надо!
> Так надо!While POSIX says the effect of specifying sticky/setuid/setgid bits is
unspecified[*], the 'umask' builtin should still accept these bits, as
it does in every other shell.Вот так и надо было писать в новости.
Астрологи объявили год поломанных скриптов.
> Астрологи объявили год поломанных скриптов.Говорила ж мама: "Пиши скрипты только на sh"...
Это не помогает с дебиановским dash, вообще говоря.PS: и да, жду свидетелей двух башей в альте -- бегать по дистрибутивам и интересоваться, почему они ещё не на bash5. Ну или завязывать с двухстандартностью. Ну или оставаться лицемерами, да.
ССЗБ
Миша, а как же Альт? Что-то ты всё про Debian, да про Debian.
> Миша, а как же Альт?https://bugzilla.altlinux.org/31399 CLOSED FIXED
> Это не помогает с дебиановским dash, вообще говоря.У Debian-а мейнтейнеров завались, там это как раз не проблема.
> PS: и да, жду свидетелей двух башей в альте -- бегать по дистрибутивам и интересоваться, почему они ещё не на bash5. Ну или завязывать с двухстандартностью. Ну или оставаться лицемерами, да.
Я так понимаю, через пару лет они будут свидетелями трёх башей в альте? )
> Это не помогает с дебиановским dash, вообще говоря.В смысле не помогает? Он же вроде POSIX совместимый: dash is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible.
>>>> Астрологи объявили год поломанных скриптов.
>>> Говорила ж мама: "Пиши скрипты только на sh"...
>> Это не помогает с дебиановским dash, вообще говоря.
> В смысле не помогает? Он же вроде POSIX совместимый: dash is a
> POSIX-compliant implementation of /bin/sh that aims to be as small as
> possible.Сдаётся мне, полностью честно было бы s/is /aims to be / вот здесь.
Глючный он местами, и несколько лет назад (когда вляпался в такое и разбирались с нашим майнтейнером dash, он заодно большой знаток стандартов, в отличие от меня) оказалось проще обойти проблему в скрипте, чем исправить интерпретатор у нас или в апстриме. Проблема была уже известна. Здесь я её в каком-то из аналогичных обсуждений тоже показывал в цветах и красках, но это опять же к слову о жалобах на троллейбусной остановке (разве что я уже знал, что они уже знают)...
PS: на /bin/sh, который в альте из bash собирается -- скрипт работал, разумеется. И нет, то был не башизм.
>> Астрологи объявили год поломанных скриптов.
> Говорила ж мама: "Пиши скрипты только на sh"...На котором из? Впрочем geesh/gash порешают, да.
http://pubs.opengroup.org/onlinepubs/9699919799/idx/xcu.html
На том который описан в IEEE Std 1003.1, зачем завязываться на конкретный интерпретатор?
#>>>Говорила ж мама: "
#>>> только на sh"...
> На том который описан в IEEE Std 1003.1, зачем завязываться на конкретный
> интерпретатор?Я ж про _реализацию_ спрашивал.
Который из них реализует этот вашЬ с[замечательный]й "POSIX shell"? И чтоб не больше и не меньше? И чтоб без ошибок в реализации и стандарте?
Они все? Ни один из? '#!/bin/bash --posix'?
Что Ваша мама вам _конкретно_ говорила-то???777 А _его_ мама _ему_?
<///>
> Который из них реализует этот вашЬ с[замечательный]й "POSIX shell"? И
> чтоб не больше и не меньше?Кстати, сразу, при выборе варианта -
> Они все?
, то исть писать _под все_ возможные реализации /bin/sh, написание скрипта превращается в сизифов камень-в-гору.
Да, желание "позиксивистов" озадачить всех вокруг своими проблемами понятно, но совершенно непотребно.
> <///>
Приветы маме.
> Я ж про _реализацию_ спрашивал.
> Который из них реализует этот вашЬ с[замечательный]й "POSIX shell"?Например bash --posix, да, или вызов баша через команду sh, большинство других шеллов предоставляющих /bin/sh делают так же. Если не делают, то пишите им в багтрекер.
> чтоб не больше
А почему не больше? Больше можно, стандарт не запрещает реализациям делать расширения синтаксиса.
> и не меньше?
Разработчики баша утверждают что реализуют этот стандарт, даже в мане написано.
Но я мамой клясться конечно не буду.> И чтоб без ошибок в реализации и стандарте?
Извините Андрей, но ваши безошибочные программисты в другом замке.
>> чтоб не больше
> А почему не больше? Больше можно, стандарт не запрещает реализациям делать расширения
> синтаксиса.Я не знаю, почему вам двоим мамы (или мама? не братья?) запрещают в башизмы. И вы остальным по ушам с этим фетишем ездите. Стандпрт же ж вишь ты "не запрещает в расширения", ага.
ksh очень хорош по совместимости
Уйди! ты просто с ними не возился!их вообще два, и обычно в системе стоит старый.
Что, скрипты настолько сложны, что трудно подправить?
Бывают не столь сложны скрипты, сколь инварианты, особенно неявные.
Я о большей части перечисленного даже не слышал. Думается, большинство этих изменений даже не заметит.
хвастаться собственной некомпетентностью - какой интересный вариант каминг аута.
>Встроенная реализация malloc переведена на использование mmap для обеспечения запроса блоковО, а вот и пачка потенциальных уязвимостей и переполнений подъехала.
А теперь расскажи, чем в плане переполнений аллокация через mmap хуже malloc/new (который сам обёртка над mmap/brk в большинстве libc).
А в каких аллокаторах, кроме, возможно, виндовых, malloc работает через что-то отличное от mmap/(s)brk?
В Винде всё точно так же, только вызов называется VirtualAlloc. Даже если задать огромную пустую секцию исполняемого файла и аллоцировать кучу там, внизу окажется отображение страниц.
Это ровно то, что делается в других реализациях malloc.
А зачем башу своя реализация malloc?
Для оптимизации, упрощения отладки и улучшения их переносимости между различными системами.
Пихать внешние невалидированные данные в неизолированный баш это само по себе потенциальная уязвимость.
Без https по умолчанию раздавать файлы в наше время - жуткий моветон.// b.
а еще говорят что шапка из фольги помогает при паранойи. попробуйте.
> а еще говорят что шапка из фольги помогает при паранойи. попробуйте.слышал, в последных прошивках излучателей используются особые радиоволны, которые пробивают шапочки из фольги
> в последных прошивках излучателей используются особые радиоволныТак они и https пробивают на ура. Тут нужны другие подходы.
Нихрена она не помогает. Наоборот, излучение отражается от поверхности планеты и концентрируется под шапочкой.
Проверять подпись загруженного файла уже можно лет 20 как.
А md5 скачан с того же места без https. Угу.
Какая разница, откуда скачан md5, если проверять надо подпись?
А .sig-файл с подписью и открытый ключ для её проверки тоже скачаны по нешифрованному каналу, в том числе "с того же места без https". Угу.
Ездить надо к автору лично ;)
> А .sig-файл с подписью и открытый ключ для её проверки тоже скачаны
> по нешифрованному каналу, в том числе "с того же места без https". Угу.И зачем было городить инфраструктуру со всякими keys.gnupg.net, спрашивается...
>> А .sig-файл с подписью и открытый ключ для её проверки тоже скачаны
>> по нешифрованному каналу, в том числе "с того же места без https". Угу.
> И зачем было городить инфраструктуру со всякими keys.gnupg.net, спрашивается...Чтоб как с dns-ом было: быстро, удобно и не напрягая мозг. https://www.opennet.me/opennews/art.shtml?num=49937
> А .sig-файл с подписьюЭто так же не имеет значения так как подпись проверяется ключом.
> и открытый ключ для её проверки тоже скачаны по нешифрованному каналу
А этого вы не знаете, это не из чего не следует и так же вы не знаете проверял ли пользователь подписи самого ключа и его отпечаток. Если он проверил ключ при получении, как того требуют правила — то всё будет в порядке и по HTTP.
Расскажите это "зелёным", они Вам расскажут, что моветон -- делать свой вклад в глобальное потепление. Ну а мы тут полюбуемся на два лагеря опирающихся всё больше на эмоции вместо рассуждения.
Ядро линукс 5.0, баш 5.0... Что к чему приурочили?
К скорому выходу Librem 5.
> К скорому выходу Librem 5.С 5 понятно. А 0 к чему?
символ бесконечного уроборуса. типа всё это фарэвэр
Тепрь я спокоен. А то боялся, что выпустят 0 телефонов.
модули до сих пор не завезли? нет нормального способа заинклудить другой файл (source гуляет от cwd, а не от dirname текущего файла, причем нужно учитывать, что текущий файл может быть симлинком на другой). А еще недавно обнаружил, что переменная $? всегда ноль, если результат сабшелла записывается в локальную переменную:$ my_func () { aaa=$(exit 1); echo $?; }
$ my_func
1
$ my_func () { local aaa=$(exit 1); echo $?; }
$ my_func
0Язык бредовый, но тем не менее идеальный для запуска серии процессов, поэтому ругаю я его исключительно в духе "милые бранятся только тешатся" и не променяю его на всякие нескучные фишы
> bash
> языкВы это серьёзно? Зачем что-то сложное писать на убогих скриптовых языках?
Напиши на "неубогом" языке скрипт восстановления реплики бд мускуля.
Все так плохо, что это уже надо скриптовать? Поменяйте базу уже.
Например, чтобы не встраивать интерпретатор какого-нибудь питона или руби докер-образ. А еще, чтобы все это потом могли поддерживать, т. к. баш мало-мальски знает любой юникс-админ.
> $ my_func () { local aaa=$(exit 1); echo $?; }Возможно, проблема в том, что $? относится к самому local (который выполнился успешно, так как значения переменным присвоены). А в первом случае оно относится к запускаемым командам независимо от того, используется ли их значение для чего-то или нет (например, для записи в переменную aaa).
> если результат сабшелла записывается в локальную переменнуювсё верно, потому что это результат команды local, раздели объявление локальных переменных и присвоение в них.
Причина в том, что local -- это команда, а не часть синтаксиса. И ее код возврата всегда 0.
Нелогично, но это так. Я сам был очень удивлен, когда первый раз напоролся на эту особенность.
> source гуляет от cwdНет.
(кстати, альтовая libshell имени legion@ -- полезная библиотечка для тех, кто действительно пишет на шелле)
$ which shell-error
which: no shell-error in (/home/mike/bin:/usr/local/bin:/bin:/usr/bin:/usr/games)
$ type shell-error
shell-error is /bin/shell-error
$ . shell-error
$ fatal error
bash: errorPS (спасибо оппоненту):
$ pwd
/home/mike
> > source гуляет от cwd
> Нет.Да.
$ tree
.
├── include-me.sh
└── subdir
├── include-me.sh
└── main.sh1 directory, 3 files
$ cat include-me.sh
echo "Гуляет от cwd"
$ cat subdir/include-me.sh
echo "Шигорин был прав"
$ cat subdir/main.sh
source include-me.sh
$ bash subdir/main.sh
Гуляет от cwd> (кстати, альтовая libshell ...
Ладно, посмотрю.
Кстати, Шигорин, у меня оффтоповый вопрос тебе, как большому знатоку RPM-based-дистростроительства: какой софтиной свежесобранные RPM складируют по всяко-разным папкам как в [1], создавая при этом все возможные репозитории (createrepo) - репозиторий только для src.rpm, репозиторий только для debuginfo, только для обычных бинарников, и все это помноженное на версии дистра и архитектуры? Или каждый дистр сам для себя пишет такие вещи? Я через rpmbuild добиваюсь 4-х пакетов: src.rpm, debuginfo, debugsource и обычный бинарник, а есть ли готовые инструменты для складирования этих файлов по папкам и автоматического пересоздания rpm-репозиториев - не ясно.
[1] http://fedora-mirror01.rbc.ru/pub/fedora/linux/releases/
> Кстати, Шигорин, у меня оффтоповый вопрос тебе, как большому знатоку RPM-based-дистростроительства: какой софтиной свежесобранные RPM складируют по всяко-разным папкам как в [1], создавая при этом все возможные репозитории (createrepo) - репозиторий только для src.rpm, репозиторий только для debuginfo, только для обычных бинарников, и все это помноженное на версии дистра и архитектуры? Или каждый дистр сам для себя пишет такие вещи? Я через rpmbuild добиваюсь 4-х пакетов: src.rpm, debuginfo, debugsource и обычный бинарник, а есть ли готовые инструменты для складирования этих файлов по папкам и автоматического пересоздания rpm-репозиториев - не ясно.Ты можешь разложить пакеты так, как тебе это заблагорассудится, а затем натравить на корень createrepo. Этого, как правило, достаточно.
Если у тебя под несколько архитектур, то я бы разложил пакеты разных архитектур по разным каталогам, и в каждой запустил бы свой createrepo. Скриптуется на раз-два. Сомневаюсь, что есть софтина, которая это делает.
Главное -- никогда не изменять добавленный пакет постфактум. Когда createrepo --update запускаешь, он не проверяет пакеты, уже находящиеся в базе, на соответствие хэшу.
>> > source гуляет от cwd
>> Нет.
> Да.Нет. В приведённом мной примере и впрямь стоило сразу показать, что стою не в /bin, тут Вы правы.
> $ tree
> ├── include-me.sh
> └── subdir
> ├── include-me.sh
> └── main.shЭто и не опровергал, просто в целом Ваше утверждение счёл неверным (и для кого-то это может оказаться неприятным сюрпризом -- ну как вот помните те любимые детские грабли с тестовым скриптиком, называющимся test? :).
> какой софтиной свежесобранные RPM складируют по всяко-разным папкам как в [1]
> [...] Или каждый дистр сам для себя пишет такие вещи?Зависит от ожидаемой раскладки репозитория, да.
> [...] а есть ли готовые инструменты для складирования этих файлов по папкам
> и автоматического пересоздания rpm-репозиториев - не ясно.Тут лучше спросить tigro@ или, скажем, Лёню Кантера -- они наверняка смогут подсказать прицельно, а мне надо искать/читать упомянутый createrepo, чтоб ответить что-то хотя бы про него.
Почитайте уже http://mywiki.wooledge.org/BashPitfalls#local_varname.3D.24.... что ли, да и всё остальное в той же вики. Поможет избавиться от иллюзий о том, что скрипты на баше - это просто.
А pre- и post-exec так и приходится пилить либо патчами, либо очень неочевидно приседая.
systemd твой друг
> systemd твой другС такими друзьями и враги не нужны.
Да ты упрт!
Причём тут системда, если мне нужна конструкция, которая позволяет выполнить свой код ПОСЛЕ нажатия пользователем кнопки ентер, но ДО выполнения введённой команды (ну и соответственно, другую команду после завершения пользовательского приложения, но ДО возврата управления пользователю)? Да, я хочу сделать себе нормальную history с синхронизацией, регэкспами и статистикой.
> Да, я хочу сделать себе нормальную history с синхронизацией, регэкспами и статистикой.Нууу... из перекликающихся задачек вспомнился LiLaLo -- вдруг подойдут тамошние изящные хаки (без изменения интерпретатора): http://xgu.ru/wiki/LiLaLo
PS: вообще у Игоря немало ценной информации и красивых хаков (сюда он нынче порой пишет про заточенные под curl веб-сервисы, но ими далеко не ограничивается), кто не видел его вики и проекты -- очень рекомендую найти время глянуть хоть краем глаза.
PPS: а про systemd -- может, это очередной скрипткидди пытался нас о чём-то предупредить?..
Лучше бы двумерные массивы запилили уже, в конце-то концов.
Массивы размерностью больше 1 - зло.
> Массивы размерностью больше 1 - зло.Ы??? Очень неожиданное мнение. Можно получить и его обоснование?
Запросто. Массивы с размерностью >1 не существуют.
Скажу по другому: я хочу сложные структуры данных. Так яснее?
> хочу сложные структуры данныхЕсть в питоне и перле, пользуйтесь.
Возьми нормальный язык и не ремонтируй двигатель изолентой.
> Скажу по другому: я хочу сложные структуры данных. Так яснее?В 4.0 сделали local -n
Передачу "по имени" можно пилить уже.Минус - в старых дебианах и рхелах не работает (это как раз к вопорсу про bash <-> язык). Ну, и скрипты _таких_ объёмов становятся, что ... мысли про язык - приходят.
ООП на башЕ. :/ Упражнение в .... тщетности.
Пишем:_rl_set_field() { #arg1- 'THIS', arg2- 'field', arg3- 'value'
local -n vl="$3"; local fnm="$2"
_set "$1" "$fnm" "$vl"
.
.
.Зовём:
release_read() { # arg1- 'THIS', stdin - ... => new THIS.[]
local fld val tformwhile read fld; do
val="$( _read_nlnl)"
_rl_set_field "$1" "$fld" 'val'
done < <( _gpg_signed_body| _release_unfold)
}
Во-о-от... Сложные структуры, многомерные массивы, ассоц.списки с обратными индексами и проч., и проч., и проч. оставляю в качетве упражнения читателю.
> Скажу по другому: я хочу сложные структуры данных. Так яснее?Если нужны сложные структуры данных, то скорее всего Вы ошиблись с выбором инструмента. Shell -- он для запуска задач, проверок аргументов, организации параллельной работы пула задач. Но не для вычислений и не для сложной логики.
Тут уже выше рекомендовали Perl. Либо же рассмотрите любой другой язык по Вашему вкусу.
Интересно, в баше, когда-нибудь появится возможность возвращать из функции не только числа от 0 до 256? Для этого как минимум придется сделать исполнение функций не отдельным процессом, а потоком, но, вроде, других ограничений не вижу.
func () {
if что-то ; then
echo "0"
else
echo "65535"
fi
}Пользуйся)
Видел точно такое же на С++
Пользуюсь, но все же это костыль. Некрасиво.
Из функции можно возвращать строку.Если речь про код выхода по команде exit, то там вообще 4 байта.
Из этих 4-х только один - код выхода процесса. И ограничение это не в bash, так что ответ на оригинальный вопрос - не будет этого никогда.
> 256off-by-one
> Интересно, в баше, когда-нибудь появится возможность возвращать из функции не только числа
> от 0 до 256? Для этого как минимум придется сделать исполнение
> функций не отдельным процессом, а потоком, но, вроде, других ограничений не
> вижу.С-слабак!
1.
_get() { # 1- 'OBJ', 2- fld, 3- 'out' => rc &| $out
local -n vv="$1" ou="$3";
[ "${vv[$2]}" = "" ] && return 1
ou="${vv[$2]}"; }
2.
declare -a ARR # _new() и ...
ARR['xyz']=abc # ... _set() не поместились на полях этого форума.
ARR['123']=389_get 'ARR' 'xyz' 'var1'
_get 'ARR' 'xyz' 'var2'
printf "var1=%1, var2=%s\n" "$var1" "$var2"(Да, про 'строки возвращать' сказали уже. Вот это оно и есть. Не через пайпы ж с подпроцессами их гонять! Р)
См.также -> http://www.opennet.me/openforum/vsluhforumID3/116249.html#95
> Интересно, в баше, когда-нибудь появится возможность возвращать из функции не только числа от 0 до 256?Во-первых 255, во-вторых нет, не появится, потому как kernel/libc в вызове _exit рассматривает как код возврата только первый байт статуса.
Использую zsh, а для сборки пакетов держу dash.
Держите нас в курсе. Это так интересно.
А мне интересно. Не всем же выбирать софт по официальным мануалам редхета.Плюсанул ему.
А, ну да. Навыбирают себе "софта" а потом на лезут на борды с такими головоломными вопросами, что сам Друзь офигеет
Александр, перелогинтесь.
> Навыбирают себе "софта" а потом на лезут на борды с такими головоломными вопросамиСлушал бы таких, как вы, сидел бы сейчас на десяточке.
>> Навыбирают себе "софта" а потом на лезут на борды с такими головоломными вопросами
> Слушал бы таких, как вы, сидел бы сейчас на десяточке.Только если "десяточка" -- это Debian Buster! :)
Тот редкий случай, когда на ЛОРе новость более полная.// b.
В переводе на LOR местами текст очень напоминает машинный перевод. В переводе на opennet выкинута куча малоинтересных мелочей, которые только распыляют внимание и мало кому интересны.
BASHism improved...
Сделали бы еще вывод истории команд с хронологией по дате....
Оно уже есть как бы. Переменную HISTTIMEFORMAT погуглите
Я пробовал написать на bash что-то типа менеджера паролей. Это возможно. Но как-то очень неприятно)) Ну я просто юзер, но в конце концов переписал на elisp. Но тоже не особо хорошо. Думаю в итоге переписать на Perl, это уже будет хоть что-то.Конечно можно бездумно юзать и встроенный в FF, до поры до времени))
Сейчас пихонеры тебя исправят.
> Я пробовал написать на bash что-то типа менеджера паролей.А чем именно не устроил каждый из существующей горы вроде pwsafe? (первый попавшийся под руку, не воспринимайте как рекомендацию!)
Я о нем не слышал)) Ок, учту.
Да и непонятно о каком pwsafe речь?
Там есть автоматический выбор аккаунта для текущего отркрытого в фоксе домена? - Вероятно, нет.
Есть автоматическая подстановка юзернейма/пароля в буфер обмена? - Тоже наверно нет. Так неудобно..
Это есть в KeePassX.С global shortcut не очень ровно в Wayland, но в остальном - вполне рабочая штука.
http://kpcli.sourceforge.net/
?
Да хоть fpm2. Был, но так же слишком просто ;)
kpcli совместим с KeePass в отличие от fpm2 и прочих, а это значит что синхронизация файла мэнеджера паролей будет работать практически на всех платформах, - андроид, яблоко, венда, все юникс подобные ОСи и даже на старой нокии из под джавы.
менеджер паролей на bash - pass . очень хороший менеджер паролей.
Что только не придумают чтоб не использовать прекрасный perl!