Thank you for your reply. I understand what you concern .
In our enviroment we consider it as an import audit function which send those
command history to remote SIEM directly.
孙会林
中国银联信息总中心
地 址：上海市浦东新区顾唐路1699号
邮 编：201201
电 话：021-3892-6607
From: Chet Ramey
Date: 2018-07-17 23:02
To: su
On 7/17/18 5:19 PM, Grisha Levit wrote:
> When there is a variable with a name that includes a subscript in the
> environment, test -v looks at that variable rather than an array with
> that subscript.
Even though bash needs to do a better job to segregate environment
variables with invalid names,
On 7/17/18 4:44 PM, Grisha Levit wrote:
> The following commands:
>
> declare -n r=v[0]
> v=(X); r=Y
> declare -p ${!v*}
> printf "%s: <%s>\n" "r" "$r" "v" "$v"
>
> Will normally produce the following output:
>
> declare -a v=([0]="Y")
> r:
> v:
>
> However, if we
On 7/17/18 4:51 PM, Grisha Levit wrote:
> Usually, an assignment preceding a command that would create a
> variable with an invalid name is rejected and treated like a command
> name:
>
> $ 1=X :
> bash: 1=X: command not found
>
> But when the variable name looks (sort of) like an array subscript
On 7/18/18 8:25 AM, Denys Vlasenko wrote:
> Unquoted ${v:+ARG} operator allows single-quoted strings
> in ARG:
>
> $ x=a; echo ${x:+'b c'}
> b c
>
> In this case, obviously single quotes must be paired.
>
> If ${v:+ARG} is in double-quoted string, single quotes lose their special
> status:
>
>
Unquoted ${v:+ARG} operator allows single-quoted strings
in ARG:
$ x=a; echo ${x:+'b c'}
b c
In this case, obviously single quotes must be paired.
If ${v:+ARG} is in double-quoted string, single quotes lose their special
status:
$ x=a; echo "${x:+'b c'}"
'b c'
IOW: they work similarly to ord
On Tue, Jul 17, 2018 at 05:47:20PM -0400, Grisha Levit wrote:
> At global scope this works as expected:
>
> $ declare -n ref=var; declare -a ref=(X); declare -p ref var
> declare -n ref="var"
> declare -a var=([0]="X")
>
> But in a function, we end up with the nameref variable having both the
> `
