If an empty array is declared using `declare -a NAME` and then immediately
`declare -p NAME` is invoked, it says there is no such variable. However,
if one assigns some values to the array, `declare -p` works then as expected.
That is: `declare -p NAME` does not work on an array which has been dec
In the following script, the effect of calling f0 is that the value
global $i
is still 5, but the effect of calling f1 is that the value of the global
$i is
9. It's nice to be able to create a function like unlocal that moves
local
variables out of the way, but I'm wondering if it can be relied
On Mon, Jan 05, 2015 at 01:14:53PM -0700, Poor Yorick wrote:
> It's nice to be able to create a function like unlocal that moves
> local
> variables out of the way, but I'm wondering if it can be relied on in
> future
> versions:
Chet can give the authoritative answer about future directions, bu
On 1/4/15 11:43 AM, isabella parakiss wrote:
> Ok, that makes sense, but why doesn't it work if I change the delimiter?
>
> read -t 3 -d q *press random keys without pressing q*
>
> I think the same should happen here, I'm asking bash to read as much input as
> it can until it reads a q. S
If this behavior (ignore with warning one or more Ctrl-Z keypresses during
loops before eventually backgrounding) was desirable, there may be code
that could be borrowed from IGNOREEOF handling (I haven't looked at it).
-Jonathan Hankins
On Wed, Dec 31, 2014 at 1:26 PM, Ed Avis wrote:
> Thanks
On Mon, Jan 05, 2015 at 03:25:56PM -0500, Greg Wooledge wrote:
> On Mon, Jan 05, 2015 at 01:14:53PM -0700, Poor Yorick wrote:
> > It's nice to be able to create a function like unlocal that moves
> > local
> > variables out of the way, but I'm wondering if it can be relied on in
> > future
> > v
