On 12/8/14 3:48 PM, Linda Walsh wrote:
>> intending to declare the *scalar* varible "$a" as a copy of the
>> scalar variable "$b"
> ----
> How does the script writer **KNOW** $a and $b are scalar?
I agree that the script writer needs to pay attention to the types and
values of variables he is using if he doesn't unset them first.
> I'm using 'a=fmt' and 'b=out' for clarity in my example
> but say I want to insert a line to print the current UID/EUID/time & hostname:
>
> #!/bin/bash
>
> ### add lowercase info line of currently executing user:
>
> unset fmt out
> declare -x fmt='($(echo uid:$UID) $(echo euid:$EUID) $(date) $(uname -n))'
> declare -a out
> declare -l out=$fmt
> echo "out=${out[@]}"
> sudo bash --norc -c 'declare -a out;declare -l out=$fmt; echo "out=${out[@]}"'
This is exactly the backwards compatibility issue I'm talking about. The
question is how much of this to give up and how to make the functionality
available, even if it's not by default. The simplest thing is to require
`eval declare -l out=$fmt', but change to the default behavior is going to
require some change to some scripts. Adding an option to change the
default behavior is least disruptive, but will probably not sufficiently
address the `vulnerability' to satisfy security people.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
