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
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 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.
Parameter Expansion: Case Modification: ${var~} not documented
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.
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
Would you mind sharing the rational behind having it undocumented?
On Tue, Aug 18, 2015 at 7:38 AM, Chet Ramey chet.ra...@case.edu 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/
