Re: Unset array doesn't work

[Clark Wang]

On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov 
wrote:

>
>> Take a look at these links:
>>
>>   - http://wiki.bash-hackers.org/commands/builtin/unset
>>   - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference
>>
>
> Thanks, Clark! However, I find it difficult to follow the explanation at
> the
> first link and even more difficult to connect it to this case. So I'm not
> sure
> I'm getting it right. Could you maybe explain what exactly happens in the
> code
> I posted?
>

Your code:

inner() {
unset res
if [[ $1 == "set" ]]; then
res[0]="X"
res[1]="Y"
fi
}

outer() {
local res=
inner "$1"
echo "res: ${res[@]}"
}

The "unset" in inner() actually unsets the "res" in outer() and the
following assignment (to res[0] and res[1]) is actually assigning to the
global var "res". And in outer(), after calling inner(), its local "res" is
gone and it also referencing to the global var "res".

With 2 "unset" commands, even the global "res" is unset.

Re: Unset array doesn't work

[Nikolai Kondrashov]

On 02/12/2018 10:03 AM, Clark Wang wrote:

On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov mailto:spbn...@gmail.com>> wrote:


Take a look at these links:

   - http://wiki.bash-hackers.org/commands/builtin/unset 

   - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference 



Thanks, Clark! However, I find it difficult to follow the explanation at the
first link and even more difficult to connect it to this case. So I'm not 
sure
I'm getting it right. Could you maybe explain what exactly happens in the 
code
I posted?


Your code:

 inner() {
 unset res
 if [[ $1 == "set" ]]; then
 res[0]="X"
 res[1]="Y"
 fi
 }

 outer() {
 local res=
 inner "$1"
 echo "res: ${res[@]}"
 }

The "unset" in inner() actually unsets the "res" in outer() and the
following assignment (to res[0] and res[1]) is actually assigning to the
global var "res". And in outer(), after calling inner(), its local "res" is
gone and it also referencing to the global var "res".

With 2 "unset" commands, even the global "res" is unset.


Thank you, that explains it wonderfully. Sorry for being lazy and not figuring
it out myself. Now I need to craft a fix :)

Nick

Re: Incorrectly wrapped long utf8 PS1

[Chet Ramey]

On 2/10/18 11:52 PM, galtge...@o2.pl wrote:

> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
> 
> Description:
> A detailed report is at 
> https://bugzilla.gnome.org/show_bug.cgi?id=787157.

This report is from last September.  Please try it with bash-4.4.19 (there
is one patch in that set that may be relevant) and the version from the
devel git branch on Savannah. There have been several changes in the last
five months, and I'd prefer not to work on the same bug twice.  Thanks.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Unset array doesn't work

[Chet Ramey]

On 2/12/18 1:41 AM, Nikolai Kondrashov wrote:
> Hi Chet,
> 
> On 02/12/2018 01:31 AM, Chet Ramey wrote:
>> On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
>>> Hi everyone,
>>>
>>> I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
>>> an "unset" of a global array variable doesn't work inside a function, in
>>> "dkms" script from DKMS package. Adding another "unset" of the same
>>> variable
>>> next to it fixes the issue.
>>
>> Do you have a local variable with the same name "shadowing" the global?
> 
> Thank you for the quick response!
> 
> Looking more into this, the variable in question is defined as a local in the
> calling function and is being "unset" in a function called from that one.

This is bash's dynamic scoping. The visibility of a local variable is
restricted to a function and its children, and `unset' removes the
currently-visible instance. Removing such an instance can `unconver' an
instance in a previous scope.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Feature request: PROMPT_COMMANDS array variable

[Chet Ramey]

On 1/23/18 1:23 PM, Daniel Colascione wrote:
> Right now, PROMPT_COMMAND gives a shell command to run before displaying
> the prompt. It's common these days to include in one's bash configuration
> numerous packages from different sources that *all* want to run code at
> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
> stores a list of shell commands to execute? With a PROMPT_COMMANDS
> variable, different packages can independently add their hooks without
> stepping on each other.

I think the way to go forward on this is to make PROMPT_COMMAND an array
variable in a future version of bash. This is completely backwards-
compatible with current usage.

In the meantime, appending using $'\n' as a separator is the best way to
add commands to $PROMPT_COMMAND.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Custom word completion, word splitting, bad behavior

[Chet Ramey]

On 2/7/18 5:11 PM, Nick Patavalis wrote:

> On the other hand, readline seems not to be able to complete something
> like:
> 
> ls /tm"p/foo/a b"
> 
> (and I don't understand why), though this is true, regardless of
> whether " is in COMP_WORDBREAKS or not. I *both* cases, the command line
> is split (correctly) like:
> 
>ls | /tm"p/foo/a b"
> 
> so, probably, this is irrelevant with the discussion at hand.

Because, as I said in my original reply, readline understands how to
complete inside quoted strings. If point is after the `b', for instance,
and you hit TAB, readline scans back to the open quote and passes
"p/foo/a b" to the completion function.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Unset array doesn't work

[Nikolai Kondrashov]

On 02/12/2018 04:26 PM, Chet Ramey wrote:

On 2/12/18 1:41 AM, Nikolai Kondrashov wrote:

Hi Chet,

On 02/12/2018 01:31 AM, Chet Ramey wrote:

On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:

Hi everyone,

I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a global array variable doesn't work inside a function, in
"dkms" script from DKMS package. Adding another "unset" of the same
variable
next to it fixes the issue.


Do you have a local variable with the same name "shadowing" the global?


Thank you for the quick response!

Looking more into this, the variable in question is defined as a local in the
calling function and is being "unset" in a function called from that one.


This is bash's dynamic scoping. The visibility of a local variable is
restricted to a function and its children, and `unset' removes the
currently-visible instance. Removing such an instance can `unconver' an
instance in a previous scope.


Thank you, Chet. Your and Clark's explanation help a lot.
Sorry for the noise.

Nick

Re: Custom word completion, word splitting, bad behavior

[Nick Patavalis]

On Mon, Feb 12, 2018 at 6:33 PM, Chet Ramey  wrote:
>
> Because, as I said in my original reply, readline understands how to
> complete inside quoted strings. If point is after the `b', for instance,
> and you hit TAB, readline scans back to the open quote and passes
> "p/foo/a b" to the completion function.
>

I see...

Still the *line* is split correctly into two words (ls | tm"p/foo a
b") regardless of the presence of '"' in COMP_WORDBREAKS. Then
readline decides to complete the second word (tm"p/foo/ a b) in this
manner (ignoring the part before the quotes). So this is not really
pertinent to our original discussion...

/npat