There is a parse error in B:
# A
bash$ p=; : "${p:=>(f()(echo "$@") ;f foo)}"; declare -p p
declare -- p=">(f()(echo ) ;f foo)"
bash$ p=; : ${p:=>(f()(echo "$@") ;f foo)}; declare -p p
declare -- p="/dev/fd/63"
foo
bash$ p=; echo "${p:=>(f()(echo "$@") ;f foo)}"
(f()(echo ) ;f foo)
# B
ba
On Tue, Mar 14, 2017 at 9:07 PM, Chet Ramey wrote:
> when PS1 is expanded the first time, the "current" history entry is the
> one corresponding to the last command entered
> PS2 looks at the current history entry, which is 530 since we've
> started on it.
I think I'm missing something. It seems
Hi,
consider this function:
split() (
unset -v IFS # default splitting
set -o noglob # disable glob
set -- $1 # split+(no)glob
[ "$#" -eq 0 ] || printf '<%s>\n' "$@"
)
Note the subshell above for the local scope for $IFS and for
the noglob option. That's a common idiom in POSIX shells
It's probably easiest to find previous discussions here on this topic
by searching for 'upvar' (common name for a function that takes
advantage of this behavior).
Latest I think was this one [1] but a much earlier discussion is here [2].
[1] https://lists.gnu.org/archive/html//bug-bash/2015-01/
The need to localize IFS is pretty obvious to me - of course that's
given prior knowledge of how it works.
The problem is the non-obvious nature of unset's interaction with scope,
(and the lack of documentation). Not much can be done about the former,
as it is with so many things.
2017-03-17 17:35:36 -0500, Dan Douglas:
> The need to localize IFS is pretty obvious to me - of course that's
> given prior knowledge of how it works.
[...]
I don't expect the need to have to add "local var" in
(
unset -v var
echo "${var-OK}"
)
would be obvious to many people beside you th
On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
> I don't expect the need to have to add "local var" in
>
> (
>unset -v var
>echo "${var-OK}"
> )
True. I would pretty much never use a subshell command group when I know
that locals are available though. And if I know locals are available
On 03/17/2017 09:16 PM, Dan Douglas wrote:
> Why
> would a subshell just make the call stack go away?
I guess slight correction, it's unset itself, because:
> In fact, mksh prints "global" even without the subshell, despite it
> using dynamic scope for either function definition syntax.
Another
