Working with array keys (was Re: Parameter Expansion: Case Modification: ${var~} not documented)
On Tue, Aug 18, 2015 at 3:50 PM, Chet Ramey wrote: > On 8/18/15 1:43 PM, Dan Douglas wrote: >> On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote: >>> Would you mind sharing the rational behind having it undocumented? >> >> Since I like guessing: the syntax for parameter expansion operators is >> currently non-extensible, so the namespace of terse operators is in limited >> supply. New syntax should be extensible to suit future needs while keeping >> the >> language minimal. This is new syntax that adds one function that will be >> rarely used. I can think of better ways to use that operator. > > This is true, and I would prefer to not set the ~ `operator' in stone until > I'm more satisfied with how it works. > > Bash-4.4 has the ${param@operator} family of expansions (inspired by a > similar feature in mksh) as the extensible syntax you're asking for. > Ah yeah. I saw the var@Q already. That will be nice! > I assume you mean the difference betweeen ${!param[@]/followed/bysomething} > and ${!param[@]}. Yeah that sort of thing. E.g. a recent example where my best answer is still pretty bad even with fancy bash 4.3-isms. It would be quite nice to get rid of the intermediary `keys` array just to look up the keys of keys. ~ $ bash <<\EOF function rev { typeset -n _ref=$1 _ret=$2 typeset -a keys=("${!_ref[@]}") typeset key=0 for ((; key <= ${#keys[@]}; key++)); do _ret[${keys[key - 1]}]=${_ref[${keys[-key]}]} done } typeset -a a=([0]=a [1]=b [3]=c) b rev a b typeset -p b EOF declare -a b='([0]="c" [1]="b" [3]="a")' Thats maybe a little tricky. What doesn't work now is ${!_ref[@]:(-(key)):1}
Re: Parameter Expansion: Case Modification: ${var~} not documented
On 8/18/15 1:43 PM, Dan Douglas wrote: > On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote: >> Would you mind sharing the rational behind having it undocumented? > > Since I like guessing: the syntax for parameter expansion operators is > currently non-extensible, so the namespace of terse operators is in limited > supply. New syntax should be extensible to suit future needs while keeping > the > language minimal. This is new syntax that adds one function that will be > rarely used. I can think of better ways to use that operator. This is true, and I would prefer to not set the ~ `operator' in stone until I'm more satisfied with how it works. Bash-4.4 has the ${param@operator} family of expansions (inspired by a similar feature in mksh) as the extensible syntax you're asking for. > The operators in use currently are already a disaster. We *really* could use > a > solution for the circumfix operators `!var[@]` and `!var[*]` that collide > with > the prefix `!` operator, and for reasons unknown don't interoperate with any > of the other expansions such as array slicing / subscripting. I wouldn't want > to add new (pointless) syntax before the fundamental problems are addressed. I assume you mean the difference betweeen ${!param[@]/followed/bysomething} and ${!param[@]}. The latter I picked up from ksh93 as is. The former is the generalization of indirect evaluation I sort of picked up from ksh93, because I didn't think you needed namerefs to have indirect evaluation. The first examples doesn't work as well as I hoped it would because I chose to use the `parameter' as used in other expansions (param[@]) as the unit of indirection instead of just the name (param). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Parameter Expansion: Case Modification: ${var~} not documented
On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote: > Would you mind sharing the rational behind having it undocumented? Since I like guessing: the syntax for parameter expansion operators is currently non-extensible, so the namespace of terse operators is in limited supply. New syntax should be extensible to suit future needs while keeping the language minimal. This is new syntax that adds one function that will be rarely used. I can think of better ways to use that operator. The operators in use currently are already a disaster. We *really* could use a solution for the circumfix operators `!var[@]` and `!var[*]` that collide with the prefix `!` operator, and for reasons unknown don't interoperate with any of the other expansions such as array slicing / subscripting. I wouldn't want to add new (pointless) syntax before the fundamental problems are addressed. -- Dan Douglas
Re: Parameter Expansion: Case Modification: ${var~} not documented
Would you mind sharing the rational behind having it undocumented? On Tue, Aug 18, 2015 at 7:38 AM, Chet Ramey wrote: > On 8/18/15 9:50 AM, Dan Douglas wrote: > > >> Description: > >> The man page fails to document the ${var~} and ${var~~} case inversion > >> expansion. > >> It got the upper and lower, ie ${var^} and ${var,} but not invert. > >> > >> Fix: > >> More documentation. > > > > I'm pretty sure that's intentional. The corresponding `declare -c` has > never > > been documented either. > > Correct; it's undocumented. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
Re: Parameter Expansion: Case Modification: ${var~} not documented
On Tue, Aug 18, 2015 at 09:22:07AM -0500, Dan Douglas wrote: > The `~` is obviously inspired by the vim > movement to toggle caps. ~ is standard vi, not a vim extension.
Re: Parameter Expansion: Case Modification: ${var~} not documented
On 8/18/15 9:50 AM, Dan Douglas wrote: >> Description: >> The man page fails to document the ${var~} and ${var~~} case inversion >> expansion. >> It got the upper and lower, ie ${var^} and ${var,} but not invert. >> >> Fix: >> More documentation. > > I'm pretty sure that's intentional. The corresponding `declare -c` has never > been documented either. Correct; it's undocumented. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Parameter Expansion: Case Modification: ${var~} not documented
On Tuesday, August 18, 2015 08:50:51 AM Dan Douglas wrote: > I'm pretty sure that's intentional. The corresponding `declare -c` has never > been documented either. > Hrm, it doesn't "correspond" actually. declare -c just capitalizes the first letter of the string. Another thing about the ${var~} expansions is I wonder why it isn't just built in to the substitution expansion. The `~` is obviously inspired by the vim movement to toggle caps. Given `foobarbaz`, vim can also do `:s/foo\zs\(bar\) \zebaz/\U\1/` and yield `fooBARbaz`. This is much more powerful, though it requires bash to start supporting backrefs in substitutions. There's also this ksh feature I've never found a use for: $ ksh -c 'x=foobarbaz; typeset -M toupper x; echo "$x"' FOOBARBAZ I don't know, the only purpose is to replace `typeset -l/-u` and allow for other towctrans operations. -- Dan Douglas
Re: Parameter Expansion: Case Modification: ${var~} not documented
On Monday, August 17, 2015 01:08:55 PM Isaac Good wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/ locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib - > D_FORTIFY_SOURCE=2 -march=i686 -mtune=generic -O2 -pipe > -fstack-protector-strong -- param=ssp-buffer-size=4 > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' > -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' - > DSYS_BASH_LOGOUT='/etc/bash.bash_logout' > uname output: Linux netbook 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 > 07:48:39 CEST 2014 i686 GNU/Linux > Machine Type: i686-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 39 > Release Status: release > > Description: > The man page fails to document the ${var~} and ${var~~} case inversion > expansion. > It got the upper and lower, ie ${var^} and ${var,} but not invert. > > Fix: > More documentation. I'm pretty sure that's intentional. The corresponding `declare -c` has never been documented either. -- Dan Douglas