Re: break no longer breaks out of loops defined in an outer context

2017-02-28 16:18:05 -0500, Chet Ramey: [...] > > Just my personal opinion, but I think I'd rather the spec had > > been updated to accomodate the bash (and many other shells) > > behaviour rather than bash breaking its backward compatibility > > to comply to a requirement that is not particularly u

Re: break no longer breaks out of loops defined in an outer context

2017-03-01 09:49:52 -0500, Chet Ramey: [...] > > Would you recommend people start adding: > > > > shopt -s compat44 2> /dev/null || true > > > > at the start of their script that they develop for bash-4.4 now > > so that it still works even when bash-6.0 makes a non-backward > > compatible change

Issues in option handling (Was: break no longer breaks out of loops defined in an outer context)

2017-03-03 08:27:03 -0500, Chet Ramey: > On 3/1/17 4:58 PM, Stephane Chazelas wrote: > > > BTW, there seems to have been a regression in the handling of the -O > > option to the bash interpreter: > > Thanks, I'll take a look. It looks to be specific to the various

"unset var" pops var off variable stack instead of unsetting it

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

Re: "unset var" pops var off variable stack instead of unsetting it

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

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-18 13:16:56 -0400, Chet Ramey: > On 3/17/17 5:51 PM, Stephane Chazelas wrote: > > > Now, if that "split" functions is called from within a function > > that declares $IFS local like: > [...] > > because after the "unset IFS", $IFS is n

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-19 18:05:19 -0400, Chet Ramey: > On 3/19/17 5:51 PM, Stephane Chazelas wrote: > > > On comp.unix.shell ot http://unix.stackexchange.com, I've posted > > many articles describing how to do splitting in POSIX-like > > shells: > > > > ( # sub

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 12:30:09 +0900, 渡邊裕貴: > It seems to me this matter is specific to the IFS variable (and possibly > few others like CDPATH). Unsetting IFS restores the default field splitting > behavior, but unsetting PATH does not restore the default command search > path. As Peter suggests, you can loc

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 08:04:33 -0400, Greg Wooledge: [...] > > Credits to Dan Douglas > > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html) > > for finding the bug. He did find a use for it though (get the > > value of a variable from the caller's scope). > > Isn't this exactly the same as t

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 14:47:17 -0400, Chet Ramey: > On 3/20/17 2:30 PM, Eric Blake wrote: > > On 03/17/2017 07:21 PM, Stephane Chazelas wrote: > > > >>> The problem is the non-obvious nature of unset's interaction with scope, > >> > >> the main pr

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 16:32:10 -0400, Chet Ramey: [...] > > See also: > > > > $ bash -c 'f() { unset a; echo "$a";}; a=1; a=2 f' > > 1 > > > > already mentioned. > > A distinction without a difference; the behavior is explicitly the same. [...] One I haven't mentioned yet is: $ bash -c 'f() { local a; un

read -N and UTF-8 characters

Using "read -N" on text containing multi-byte characters produces incorrect result. On Debian amd64 with the latest code from git: $ locale charmap UTF-8 $ printf '\ue9VWXYZ' | ./bash -c 'IFS= read -rN4 a; printf %s "$a"' | hd c3 58 a9 56 57|.X.VW| 00

Re: printf inconsistent results for %.0f

2024-08-14 09:11:05 -0400, Chet Ramey: > On 8/13/24 7:05 PM, Grisha Levit wrote: > > On Mon, Aug 12, 2024, 11:04 Chet Ramey > > wrote: > > > > My question is why the (admittedly old) gnulib replacement > > strtod/strtold > > is messing things up. > > > > > >

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

er Ͱ), but would apply for any byte in the range \300 to \364 at least in UTF-8 and other byte values in locales using multibyte character encodings other than UTF-8 (like the BIG5-HKSCS one mentioned below). [reposted (and corrected) from an email sent privately]: 2025-04-20 16:48:48 +0100,

<    1   2   3   4   5