Re: SIGCHLD traps shouldn't recurse

5 Nisan 2021 Pazartesi tarihinde L A Walsh yazdı: > On 2021/04/03 00:41, Oğuz wrote: > >> but I >> don't think it's useful at all because the number of pending traps keeps >> piling up, and there is no way to reset that number. If there is no real >> use case for recursive SIGCHLD traps (which I

Re: SIGCHLD traps shouldn't recurse

On 2021/04/06 00:23, Oğuz wrote: 5 Nisan 2021 Pazartesi tarihinde L A Walsh > yazdı: On 2021/04/03 00:41, Oğuz wrote: but I don't think it's useful at all because the number of pending traps keeps piling up, and there is no way to r

Re: SIGCHLD traps shouldn't recurse

On Tue, Apr 6, 2021 at 10:54 AM L A Walsh wrote: > > > On 2021/04/06 00:23, Oğuz wrote: > > 5 Nisan 2021 Pazartesi tarihinde L A Walsh > > yazdı: > > > > On 2021/04/03 00:41, Oğuz wrote: > > > > but I > > don't think it's useful at all because the numb

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote: > But, maybe we can introduce a special syntactic treatment of `unset' When I made a comment about the possibility of unset becoming a keyword, Chet said he had no plans to do that. ... here: https://lists.gnu.org/archive/html/bug-bas

Re: Empty array referenced by indirection reports unbound variable

arr=( ) implies no [0]= On Mon, Apr 5, 2021, 22:46 konsolebox wrote: > set -u > array=() > __ref=array[@] > : "${array[@]}" # Reports nothing > : "${!__ref}" # Unbound variable > > Using bash version 5.1.4. I know this can be avoided by using namerefs > instead but indirection is more portable w

Re: Empty array referenced by indirection reports unbound variable

On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7 Ratchev wrote: > > arr=( ) implies no [0]= arr[0] is not exactly being referenced here. -- konsolebox

Re: Empty array referenced by indirection reports unbound variable

On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7 Ratchev wrote: > > arr=( ) implies no [0]= Also `arr=()` does not imply `arr[0]=`. `arr[0]` remains unset and not assigned to any. Not even an empty string. -- konsolebox

Re: Changing the way bash expands associative array subscripts

2021年4月6日(火) 21:06 Greg Wooledge : > On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote: > > But, maybe we can introduce a special syntactic treatment of `unset' > > When I made a comment about the possibility of unset becoming a keyword, > Chet said he had no plans to do that. > > ... h

Re: Empty array referenced by indirection reports unbound variable

what i meant was there is not one element defined so .. any reference to anything in it will be not set.. makes sense @ is not defined i remember !var worked with it, or at least other defined sub elements On Tue, Apr 6, 2021, 16:26 konsolebox wrote: > On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7

Re: Empty array referenced by indirection reports unbound variable

On Tue, Apr 6, 2021 at 10:38 PM Alex fxmbsw7 Ratchev wrote: > > what i meant was there is not one element defined so .. any reference to > anything in it will be not set.. makes sense @ is not defined > i remember !var worked with it, or at least other defined sub elements @ means everything or

Re: Empty array referenced by indirection reports unbound variable

im sorry i dont support set -u cant discuss it On Tue, Apr 6, 2021, 16:40 konsolebox wrote: > On Tue, Apr 6, 2021 at 10:38 PM Alex fxmbsw7 Ratchev > wrote: > > > > what i meant was there is not one element defined so .. any reference to > anything in it will be not set.. makes sense @ is not de

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 06, 2021 at 11:28:13PM +0900, Koichi Murase wrote: > 2) we > can distinguish the erasure of the element associated with key=@ > `unset -v a[$key]' from the entire array erasure `unset -v a[@]'. As a counter-proposal, Chet could entirely remove the special meaning of unset 'a[@]' and in

Re: Empty array referenced by indirection reports unbound variable

Date:Tue, 6 Apr 2021 22:39:55 +0800 From:konsolebox Message-ID: | @ means everything or nothing. Unbound variable errors should not apply to it. I know nothing about namerefs and arrays and stuff like that, but did you consider the possibility that after

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 6, 2021 at 6:13 PM Greg Wooledge wrote: > As a counter-proposal, Chet could entirely remove the special meaning > of unset 'a[@]' and introduce a new option to unset which would take > its place. It appears -a is not yet used, so that would be a good pick. > Unless I missed somethin

Re: Empty array referenced by indirection reports unbound variable

On Tue, Apr 6, 2021 at 11:28 PM Robert Elz wrote: > | @ means everything or nothing. Unbound variable errors should not apply > to it. > > I know nothing about namerefs and arrays and stuff like that, > but did you consider the possibility that after > > array=() > > then > > ar

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 6, 2021 at 10:28 PM Koichi Murase wrote: > > 2021年4月6日(火) 21:06 Greg Wooledge : > > On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote: > > > But, maybe we can introduce a special syntactic treatment of `unset' > > > > When I made a comment about the possibility of unset bec

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 06, 2021 at 06:34:21PM +0300, Ilkka Virta wrote: > $ declare -A a=([foo]=123 [bar]=456) > $ unset 'a[@]' > $ declare -p a > bash: declare: a: not found > > i.e. both remove the whole array, not just the contents. Huh, so it does. I didn't know that. In that case, I have no qualms a

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 6, 2021 at 6:53 PM Greg Wooledge wrote: > In that case, I have no qualms about proposing that unset 'a[@]' and > unset 'a[*]' be changed to remove only the array element whose key is > '@' or '*', respectively, and screw backward compatibility. > That also seems to be what Ksh and Zs

Re: Changing the way bash expands associative array subscripts

2021年4月7日(水) 0:53 Greg Wooledge : > On Tue, Apr 06, 2021 at 06:34:21PM +0300, Ilkka Virta wrote: > > $ declare -A a=([foo]=123 [bar]=456) > > $ unset 'a[@]' > > $ declare -p a > > bash: declare: a: not found > > > > i.e. both remove the whole array, not just the contents. > > Huh, so it does. I d

Re: Changing the way bash expands associative array subscripts

On Wed, Apr 07, 2021 at 01:46:27AM +0900, Koichi Murase wrote: > I remember there was some discussion in the bug-bash list on the > behavior of `test -v a[@]' which actually tests whether the array `a' > has at least one element. > It cannot be replaced by `test -v a' because > `a' implies `a[0]'

Re: Changing the way bash expands associative array subscripts

On Wed, Apr 7, 2021 at 12:20 AM Ilkka Virta wrote: > What konsolebox said about a[$k]=() works in my Zsh for indexed arrays, but > not associative ones. > (It replaces an array slice, so can also be used to insert elements in the > middle.) Bash can adopt this. Also if Bash could just store assoc

Re: Changing the way bash expands associative array subscripts

On Wed, Apr 07, 2021 at 03:53:43AM +0800, konsolebox wrote: > Also if Bash could just store associative array > values as a list to preserve store order and stop expanding > "${array[@]}" based on the sorted order of the keys, then the slice > function can also be applied there. There is no sortin

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 6, 2021, 3:09 PM Greg Wooledge wrote: > On Wed, Apr 07, 2021 at 03:53:43AM +0800, konsolebox wrote: > > Also if Bash could just store associative array > > values as a list to preserve store order and stop expanding > > "${array[@]}" based on the sorted order of the keys, then the sli

Re: Changing the way bash expands associative array subscripts

On Wed, Apr 7, 2021 at 4:09 AM Greg Wooledge wrote: > There is no sorting in the output. You're right. I misobserved the test I had before. > (but not tcl's dictionaries, > which are closer to what you're envisioning). I don't know Tcl's dictionaries, but the clearest example I can give is Java

Re: Changing the way bash expands associative array subscripts

On Tue, Apr 06, 2021 at 03:24:54PM -0500, Dennis Williamson wrote: > Python 3.7 has insertion-order dictionaries. So these are dependable > gerbils. That explains my test results, which I didn't post. I had been told in the past that python's dictionaries did NOT remember insertion order, but I'm

Re: incorrect character handling

On 2021/03/30 13:54, Lawrence Velázquez wrote: Further reading: https://mywiki.wooledge.org/BashPitfalls#echo_.22Hello_World.21.22 --- I find that disabling history expansion via '!' at bash-build time is the most ideal solution, since someone preferring 'csh' would likely still be using c