> There isn't much written on namerefs for two reasons:
>
> 1) They're quite new.
> 2) They're pretty useless. :(
It depends on what your expectations are. Namerefs are essentially variable
name aliases. For their stated purpose -- passing variable names to shell
functions and allowing those fu
On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote:
> IMHO any user action should not lead to SIGSEGV! I am not objecting against
> recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> idea why this is happened. I have made recursive "sourse" by mistake and
> spend a lot of ti
On Wed, Sep 3, 2014 at 9:09 PM, Chet Ramey wrote:
>> There isn't much written on namerefs for two reasons:
>>
>> 1) They're quite new.
>> 2) They're pretty useless. :(
>
> It depends on what your expectations are. Namerefs are essentially variable
> name aliases. For their stated purpose -- pass
On 9/3/14, 1:14 PM, lolilolicon wrote:
> Yes, they're convenient, and make the code look somewhat more
> readable, compared to equivalent `eval` or `printf -v` statements.
> Functionally, they're all the same.
> And they all suffer from the same issue. No matter which of those
> three is used, one
$ cat parallel-test.bash
function process_job {
sleep 1
}
function main {
typeset -i index=0 cur_jobs=0 max_jobs=6
trap '((cur_jobs--))' CHLD
set -m
while ((index++ < 30)); do
echo -n "index: $index, cur_jobs: $cur_jobs"
set +m
childs=$(pgrep -P $$ | wc
