Re: 'local -x VARIABLE' does not clear variable for subprocesses

[Dan Douglas]

On Sunday, May 04, 2014 01:22:02 AM Arfrever Frehtes Taifersar Arahesis wrote:
> 'local -x VARIABLE' (without assignment of value) does not clear
> variable for subprocesses.  It is regression in bash 4.3.
>
> Behavior of 'local VARIABLE' without -x option also changed, but I am
> not sure what should be correct behavior in that case.
>
> bash 4.2.47:
>
> $ export VAR1=abc VAR2=abc
> $ f() { local VAR1; local -x VAR2; bash -c 'declare -p VAR{1,2}'; }
> $ f
> bash: line 0: declare: VAR1: not found
> bash: line 0: declare: VAR2: not found
>
> bash 4.3.11:
>
> $ export VAR1=abc VAR2=abc
> $ f() { local VAR1; local -x VAR2; bash -c 'declare -p VAR{1,2}'; }
> $ f
> declare -x VAR1="abc"
> declare -x VAR2="abc"
>
> --
> Arfrever Frehtes Taifersar Arahesis

This is pretty ambiguous territory. One thing that did change in 4.3 is
that you can now unexport a variable that was exported to a function
through an assignment during the call via `typeset +x`, but I believe
that's unrelated to a separate `export`.

I reran one of my old tests:
https://gist.github.com/ormaaj/04923e11e8bdc27688ad#file-output

As you can see there isn't much rhyme or reason to the results, and
these tests take into account all the other differences that don't have
to do with exporting.

Test 1 exports a global then localizes it. Test 2 exports a local and
tests a local from a child scope. Test 3 tests exported namerefs.

--
Dan Douglas

Re: bind -x and multiple prompt/command lines

[Jesper Nygårds]

Chet,

Not that it is pressing in any way, but have you had any time to look at
this?


On Tue, Apr 22, 2014 at 1:34 PM, Jesper Nygårds wrote:

> Here are simplified versions of two functions that I have written. Both
> are inspired by similar functions floating around on the zsh mailing lists.
> The first copies the previous word on the command line, and the second one
> converts three consecutive dots (...) into ../.., and you can then keep
> adding levels by typing . repeatedly.
>
> Note that I am by no means an expert in Bash programming, so I'm sure the
> same thing could be done more elegantly.
>
>
> bind -x '".":_rationalise-dot'
> bind -x '"\e:":_copy-previous-word'
>
> _copy-previous-word () {
> local -a words
> eval words=($READLINE_LINE)
> #NOTE: copies quoted words correctly, but does not insert with the
> escape intact
> READLINE_LINE+=${words[${#words[@]}-1]}
> READLINE_POINT=${#READLINE_LINE}
> }
>
> _rationalise-dot () {
> if [[ ${READLINE_LINE:0:$READLINE_POINT} == *\.\. ]]; then
>
> READLINE_LINE="${READLINE_LINE:0:$READLINE_POINT}/..${READLINE_LINE:$READLINE_POINT}"
> ((READLINE_POINT+=3))
> else
>
> READLINE_LINE="${READLINE_LINE:0:$READLINE_POINT}.${READLINE_LINE:$READLINE_POINT}"
> ((READLINE_POINT++))
> fi
> }
>
>
>
> On Fri, Apr 18, 2014 at 3:13 PM, Chet Ramey  wrote:
>
>> On 4/15/14, 11:22 AM, Jesper Nygårds wrote:
>> > I don't have any solution to offer, but I would like to second the wish
>> for
>> > this to work better, and for the same reason: I have written several
>> very
>> > useful functions for rewriting the command line, binding them with bind
>> -x.
>> > Like Rob, I have concluded that it does not work well with a multi-line
>> > prompt, as the visual effect of the prompt moving further and further
>> down
>> > is rather unpleasant.
>>
>> Can you send me one or two so I can play around with them and see what the
>> options are?
>>
>> Chet
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, ITS, CWRUc...@case.edu
>> http://cnswww.cns.cwru.edu/~chet/
>>
>
>