Re: PATCH: expanding parameters like echo/print builtins

Re: PATCH: expanding parameters like echo/print builtins

[Jilles Tjoelker]

> [${(g)parameter} expansion for expanding like echo/print]

Am I really strange in thinking this should really be done using command
substitution of echo, print or printf with appropriate options?

Admittedly, this requires precautions if trailing newlines are
significant, like (for expanding similar to the System V echo):

result=$(printf '%b@' "$v")
result=${result%@}

If trailing newlines are not significant, the syntax is very readable,
like:

result=$(printf '%b' "$v")

result=$(printf "$v") # careful with %

result=$(print - "$v")

Command substitution can be slow because it forks a subshell, but ksh93
and FreeBSD sh prove it need not be -- a subshell can be emulated
without a fork in many cases and POSIX is explicitly worded to allow
this.

Other tricks are using eval with $'...' (requires special care for ' and
is not in POSIX.1-2008).

In general, I think the ${(foo)parameter} forms are mostly write-only
code for interactive use, except perhaps if you use them a lot.

-- 
Jilles Tjoelker

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 14,  1:41pm, Jilles Tjoelker wrote:
} Subject: Re: PATCH: expanding parameters like echo/print builtins
}
} > [${(g)parameter} expansion for expanding like echo/print]
} 
} Am I really strange in thinking this should really be done using command
} substitution of echo, print or printf with appropriate options?

A lot of features added to zsh are things that could be done another
way but that it's more convenient to have a shortcut.

E.g., one could argue that $((5 + 3)) should really be done using
$(expr 5 + 3), etc.

} Admittedly, this requires precautions if trailing newlines are
} significant [...]
} Other tricks are using eval with $'...' (requires special care for '
} and is not in POSIX.1-2008).

It's often precisely to avoid those precautions and "special care"
cases that things like (g) get introduced.
 
} In general, I think the ${(foo)parameter} forms are mostly write-only
} code for interactive use, except perhaps if you use them a lot.

I think you've got that exactly backward. :-)  If these forms were
primarily for interactive use, the syntax would probably be a lot
less convoluted.  $'...' is for interactive use.  ${(g:oe:)...}, not
so much.

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 12, 12:40pm, Mikael Magnusson wrote:
} Subject: Re: PATCH: expanding parameters like echo/print builtins
}
} On 12 May 2011 12:10, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > [Is there a potential conflict where
} > (%) inserts something that (g) then incorrectly replaces, if you use
} > both of them togher?]
} 
} Well, if (%) inserts something before (g) processes it, (g) will
} replace it, but what would make it incorrect?

Specifically, are there any terminal control sequences that use a
backslash?  A quick grep of /etc/termcap seems to show that there
are some sequences (fs and ds usually, but some others) that use
a backslash.  To avoid those being interpreted as part of a (g)
escape, it might be best to have (g) occur before (%) unless the
user explicitly orders them the other way by nesting.

-- 

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 12 May 2011 12:10, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 11,  7:43pm, Mikael Magnusson wrote:
> } Subject: Re: PATCH: expanding parameters like echo/print builtins
> }
> } What I meant was that the relation between V and g:: isn't documented,
> } but yeah, I did miss the whole list :). Here's a patch, minus the
> } renumbering of subsequent items.
>
> Renumbering the subsequent items is a nasty bit to leave out, because
> there are cross-references among the items that always get forgotten;
> I just fixed all of those up a few months ago.
>
> It might be better just to add this to item 12 rather than introduce
> a new number.

Ah, good point.

> } Any better names than echo-type expansion? :)
>
> Elsewhere these kinds of things are referred to as "escape sequences"
> but then so are %-dohickeys for prompts.  Probably would have been
> a good idea years ago to refer to the % forms as "expandos" or some
> such word ...
>
> But, given that they're all escapes, we could go with
>
> item(tt(12.) em(Escape sequence replacement))(
> First any prompt-style formatting from the tt((%)) family of flags is
> applied, then any replacements from the tt((g)) flag are performed.
> )
>
> The (g) stuff usually involves making the string *shorter* so to call
> it an "expansion" is a bit odd.

Also a good point, I can change it to "process escape sequences like
the echo builtin" also in the description of the g:: flag, that's what
the print description calls it.

> [Is there a potential conflict where
> (%) inserts something that (g) then incorrectly replaces, if you use
> both of them togher?]

Well, if (%) inserts something before (g) processes it, (g) will
replace it, but what would make it incorrect?
/tmp/\u3042% echo -E ${(g::%):-%~}
/tmp/あ

It is of course possible to move (g) somewhere else in the sequence if
wanted, I just figured it was closest logically to (%) and put it
there. (But if you don't like the order, all you have to do is
/tmp/\u3042% echo -E ${(%)${(g::):-%~}}
/tmp/\u3042
)

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 11,  7:43pm, Mikael Magnusson wrote:
} Subject: Re: PATCH: expanding parameters like echo/print builtins
}
} What I meant was that the relation between V and g:: isn't documented,
} but yeah, I did miss the whole list :). Here's a patch, minus the
} renumbering of subsequent items.

Renumbering the subsequent items is a nasty bit to leave out, because
there are cross-references among the items that always get forgotten;
I just fixed all of those up a few months ago.

It might be better just to add this to item 12 rather than introduce
a new number.

} Any better names than echo-type expansion? :)

Elsewhere these kinds of things are referred to as "escape sequences"
but then so are %-dohickeys for prompts.  Probably would have been
a good idea years ago to refer to the % forms as "expandos" or some
such word ...

But, given that they're all escapes, we could go with

item(tt(12.) em(Escape sequence replacement))(
First any prompt-style formatting from the tt((%)) family of flags is
applied, then any replacements from the tt((g)) flag are performed.
)

The (g) stuff usually involves making the string *shorter* so to call
it an "expansion" is a bit odd.  [Is there a potential conflict where
(%) inserts something that (g) then incorrectly replaces, if you use
both of them togher?]

-- 

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 19:26, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 11 May 2011 19:19:51 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> (Should the order
>> parameter expansion flags are applied in be documented somewhere?)
>
> It's documented in *immense* detail in the subsection "Rules" under
> Parameter Expansion, but even the 23 existing rules don't cover
> everything.  Feel free to add another one.  Actually, (V) is covered, at
> rule 15, so maybe you just missed it.

What I meant was that the relation between V and g:: isn't documented,
but yeah, I did miss the whole list :). Here's a patch, minus the
renumbering of subsequent items. Any better names than echo-type
expansion? :)

--- a/Doc/Zsh/expn.yo
+++ b/Doc/Zsh/expn.yo
@@ -1305,6 +1305,9 @@ is applied.
 item(tt(12.) em(Prompt evaluation))(
 Any prompt-style formatting from the tt((%)) family of flags is applied.
 )
+item(tt(13.) em(Echo-type expansion))(
+Any expansion from the tt((g)) flag is applied.
+)
 item(tt(13.) em(Quote application))(
 Any quoting or unquoting using tt((q)) and tt((Q)) and related flags
 is applied.


-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 19:26, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 11 May 2011 19:19:51 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> (Should the order
>> parameter expansion flags are applied in be documented somewhere?)
>
> It's documented in *immense* detail in the subsection "Rules" under
> Parameter Expansion, but even the 23 existing rules don't cover
> everything.  Feel free to add another one.  Actually, (V) is covered, at
> rule 15, so maybe you just missed it.

Actually this is a case of me being an idiot. I remember scrolling
past it, but I always thought I was scrolling past the list given in
the beginning of zshexpn giving the relation between
history/alias/process/etc substitutions.

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Peter Stephenson]

On Wed, 11 May 2011 19:19:51 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> (Should the order
> parameter expansion flags are applied in be documented somewhere?)

It's documented in *immense* detail in the subsection "Rules" under
Parameter Expansion, but even the 23 existing rules don't cover
everything.  Feel free to add another one.  Actually, (V) is covered, at
rule 15, so maybe you just missed it.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 19:07, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 11 May 2011 18:38:46 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> The c and e flags will have tendencies to output unprintable
>> characters, can I write them in the expected test output somehow?
>
> The way to do this is to capture the output via a pipe or $(...) or
> whatever and then make that output readable by using ${(q)...} or
> something such.  There will be examples somewhere.  This does rely on
> the shell getting the reverse conversion right, but we test the features
> its relying on elsewhere so in theory we shouldn't get errors cancelling
> each other out.  (I'm loath to rely on od, and certainly xxd isn't
> standard enough.)

Hm, or could I use ${(V)${(g:c:):-'^X'}}? (actually putting V in the
same parens work, but the order isn't documented). (Should the order
parameter expansion flags are applied in be documented somewhere?)

  foo='\u65\123'
  print -r ${(g:o:)foo}
  foo='\u65\0123'
  print -r ${(g::)foo}
  foo='\u65^X'
  print -r ${(V)${(g:c:)foo}}
  foo='\u65\C-x\M-a'
  print -r ${(V)${(g:e:)foo}}
  foo='\u65\123\C-x'
  print -r ${(V)${(g:eo:)foo}}
0:${(g)...}
>eS
>eS
>e^X
>e^X\M-a
>eS^X

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 18:48, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 11,  6:22pm, Mikael Magnusson wrote:
> } Subject: Re: PATCH: expanding parameters like echo/print builtins
> }
> } Do I need to clarify in the docs that you write g:: to give neither of
> } the three flags? Just g by itself is an error, like for the other
> } flags that take options.
>
> I don't think that's a problem, but yes it should be doc'd.
>
> BTW, the construct "... the exception of the next sentence.  In none
> of these modes ..." is a little clunky; probably OK to just say "...
> except that in none of these modes ..."

How's this?

item(tt(g:opts:))(
Expand words like the echo builtin when no options are given (tt(g::)).
With the tt(o) option, octal escapes don't take a leading zero.  With the
tt(c) option, sequences like `tt(^X)' are interpreted.  With the tt(e)
option, interprets `tt(\M-t)' and similar sequences like the print
builtin.  With both of the tt(o) and tt(e) options, behaves like the
print builtin except that in none of these modes is `tt(\c)' interpreted.
)

And this for s,

 separator var(string).  Note that a var(string) of two or more
 characters means that all of them must match in sequence; this differs from
 the treatment of two or more characters in the tt(IFS) parameter.
-See also the tt(=) flag and the tt(SH_WORD_SPLIT) option.
+See also the tt(=) flag and the tt(SH_WORD_SPLIT) option.  An empty
+string may also be given in which case every character will be a separate
+element.


> } for this flag there are a limited number of options, so : could be
> } obligatory for the field separator, then you could say just (g). Does
> } anyone care about this? :) (It would also mean we can't use : as a new
> } flag though).
>
> I don't like the idea of limiting the delimiter to ":".

Okay, I guess I don't really either.

> RE Oliver's suggestion of a (\) flag -- I considered that too but it
> is not clear whether the backslash might be removed in some contexts
> before zsh gets around to parsing the flags.
>
> I suppose we could use (/) (to mean "reverse the backslashes"?) but ...

${(/::) looks like an alien girl waving goodbye. :)

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Peter Stephenson]

On Wed, 11 May 2011 18:38:46 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> The c and e flags will have tendencies to output unprintable
> characters, can I write them in the expected test output somehow?

The way to do this is to capture the output via a pipe or $(...) or
whatever and then make that output readable by using ${(q)...} or
something such.  There will be examples somewhere.  This does rely on
the shell getting the reverse conversion right, but we test the features
its relying on elsewhere so in theory we shouldn't get errors cancelling
each other out.  (I'm loath to rely on od, and certainly xxd isn't
standard enough.)

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 11,  6:22pm, Mikael Magnusson wrote:
} Subject: Re: PATCH: expanding parameters like echo/print builtins
}
} Do I need to clarify in the docs that you write g:: to give neither of
} the three flags? Just g by itself is an error, like for the other
} flags that take options.

I don't think that's a problem, but yes it should be doc'd.

BTW, the construct "... the exception of the next sentence.  In none
of these modes ..." is a little clunky; probably OK to just say "...
except that in none of these modes ..."

} for this flag there are a limited number of options, so : could be
} obligatory for the field separator, then you could say just (g). Does
} anyone care about this? :) (It would also mean we can't use : as a new
} flag though).

I don't like the idea of limiting the delimiter to ":".

RE Oliver's suggestion of a (\) flag -- I considered that too but it
is not clear whether the backslash might be removed in some contexts
before zsh gets around to parsing the flags.

I suppose we could use (/) (to mean "reverse the backslashes"?) but ...

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 18:21, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 11 May 2011 15:02:51 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>>       * The (@) flag; interacts obscurely with qt and isarr.
>>       * This is one of the things that decides whether multsub
>>       * will produce an array, but in an extremely indirect fashion.
>> @@ -1932,6 +1936,36 @@ paramsubst(LinkList l, LinkNode n, char **str,
>> int qt, int ssub) presc++;
>>                   break;
>>
>> +             case 'z':
>
> This might want to be 'g'.

Indeed, I noticed this line had spaces instead of tabs, so while
editing the patch file I copied the z line from the context and added
a +, taking care to change the z to a g as I did so, but somehow
didn't actually. So if this made you worry that I hadn't tested the
patch, fear not :). Speaking of testing, should I add tests for this
too? The c and e flags will have tendencies to output unprintable
characters, can I write them in the expected test output somehow? Ie,
it is probably not a good idea to write
>${(g:c:):-^X}
when testing that feature, since it'll break in the same way in both
places. It is probably not likely that c specifically would break and
everything else work, so I would personally be happy with just testing
g:: and maybe g:o: too, since that's easy enough. In fact...

--- a/Test/D04parameter.ztst
+++ b/Test/D04parameter.ztst
@@ -298,6 +298,14 @@
 >Howzat
 >usay

+  foo='\u65\123'
+  print -r ${(g:o:)foo}
+  foo='\u65\0123'
+  print -r ${(g::)foo}
+0:${(g)...}
+>eS
+>eS
+
   foo='I'\''m nearly out of my mind with tedium'
   bar=foo
   print ${(P)bar}


-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 18:03, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 11,  5:14pm, Mikael Magnusson wrote:
> } Subject: Re: PATCH: expanding parameters like echo/print builtins
> }
> } On 11 May 2011 17:03, Bart Schaefer <schaefer@brasslantern.com> wrote:
> } >
> } > I'd probably have done it with ${(%)arr:gs/%/%%}
> }
> } Yeah, me too, except (%) doesn't expand \u304c or \0123, or any of the
> } other stuff that (g) expands :).
>
> Hrm.  What was I thinking of?  Obviously hadn't eaten breakfast yet.
>
> } I looked at the list of letters and the first free one was b, so i
> } picked that, then when i got as far as discover that the function is
> } called getkeystring and noticed g was also free, i went with that.
> } [...] The following characters are taken:
> } #%@AacCDefFikLnoOPqQtuUvVwWXz0p~jlmrsZ_lBEMNR
>
> So ...
>
> x='#%@AacCDefFikLnoOPqQtuUvVwWXz0p~jlmrsZ_lBEMNR'
> y=( {$[##a]..$[##z]} {$[##A]..$[##Z]} )
> print ${${(#)y}:#[$x]}
>
> b d g h x y G H I J K S T Y
>
> I guess (g) is as good as anything, unless someone prefers to save the
> lowercase letters and go with (G).

Oops, I typed l twice, the second one was supposed to be I, so the list is
b d g h x y G H J K S T Y

Do I need to clarify in the docs that you write g:: to give neither of
the three flags? Just g by itself is an error, like for the other
flags that take options. There's not really any good reason for this
other than it is much easier to reuse the code used by s and j (and
Z). But for s/j you want to be able to specify any character, whereas
for this flag there are a limited number of options, so : could be
obligatory for the field separator, then you could say just (g). Does
anyone care about this? :) (It would also mean we can't use : as a new
flag though).

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Peter Stephenson]

On Wed, 11 May 2011 15:02:51 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
>       * The (@) flag; interacts obscurely with qt and isarr.
>       * This is one of the things that decides whether multsub
>       * will produce an array, but in an extremely indirect fashion.
> @@ -1932,6 +1936,36 @@ paramsubst(LinkList l, LinkNode n, char **str,
> int qt, int ssub) presc++;
>  		    break;
>  
> +		case 'z':

This might want to be 'g'.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 11,  5:14pm, Mikael Magnusson wrote:
} Subject: Re: PATCH: expanding parameters like echo/print builtins
}
} On 11 May 2011 17:03, Bart Schaefer <schaefer@brasslantern.com> wrote:
} >
} > I'd probably have done it with ${(%)arr:gs/%/%%}
} 
} Yeah, me too, except (%) doesn't expand \u304c or \0123, or any of the
} other stuff that (g) expands :).

Hrm.  What was I thinking of?  Obviously hadn't eaten breakfast yet.
 
} I looked at the list of letters and the first free one was b, so i
} picked that, then when i got as far as discover that the function is
} called getkeystring and noticed g was also free, i went with that.
} [...] The following characters are taken:
} #%@AacCDefFikLnoOPqQtuUvVwWXz0p~jlmrsZ_lBEMNR

So ...

x='#%@AacCDefFikLnoOPqQtuUvVwWXz0p~jlmrsZ_lBEMNR'
y=( {$[##a]..$[##z]} {$[##A]..$[##Z]} )
print ${${(#)y}:#[$x]}

b d g h x y G H I J K S T Y

I guess (g) is as good as anything, unless someone prefers to save the
lowercase letters and go with (G).

Re: PATCH: expanding parameters like echo/print builtins

[Oliver Kiddle]

Bart wrote:
> I'd probably have done it with ${(%)arr:gs/%/%%} ... but I don't have
> any objection to the (g) flag except to wonder if another choice for
> the letter (g) might be better.  The fact that it mnemes to GETKEY_
> isn't going to be very helpful to most users.

Given that % is used for the (%) flag it might be logical to use \ here.
Or would it just be too confusing. It'd probably need quoting, right?

As for existing solutions, ${(Q)${(qqqq)var}//\\\\/\\} might do it.

Oliver

Re: PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

On 11 May 2011 17:03, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 11,  3:02pm, Mikael Magnusson wrote:
> } Subject: PATCH: expanding parameters like echo/print builtins
> }
> } Is this already possible? I had an array with a lot of \u1234 escapes
> } in it, and couldn't find a way to do it easily.
>
> I'd probably have done it with ${(%)arr:gs/%/%%}

Yeah, me too, except (%) doesn't expand \u304c or \0123, or any of the
other stuff that (g) expands :).

> [...] I don't have
> any objection to the (g) flag except to wonder if another choice for
> the letter (g) might be better.  The fact that it mnemes to GETKEY_
> isn't going to be very helpful to most users.
>
> But I don't have the list of available letters handy. :-)

I looked at the list of letters and the first free one was b, so i
picked that, then when i got as far as discover that the function is
called getkeystring and noticed g was also free, i went with that. e
is taken (for echo), and p which does the same for subsequent flags is
taken, and P is also taken. If anyone has a better mnemonic in mind,
feel free to suggest it. The following characters are taken:
#%@AacCDefFikLnoOPqQtuUvVwWXz0p~jlmrsZ_lBEMNR

-- 
Mikael Magnusson

Re: PATCH: expanding parameters like echo/print builtins

[Bart Schaefer]

On May 11,  3:02pm, Mikael Magnusson wrote:
} Subject: PATCH: expanding parameters like echo/print builtins
}
} Is this already possible? I had an array with a lot of \u1234 escapes
} in it, and couldn't find a way to do it easily.

I'd probably have done it with ${(%)arr:gs/%/%%} ... but I don't have
any objection to the (g) flag except to wonder if another choice for
the letter (g) might be better.  The fact that it mnemes to GETKEY_
isn't going to be very helpful to most users.

But I don't have the list of available letters handy. :-)

PATCH: expanding parameters like echo/print builtins

[Mikael Magnusson]

Is this already possible? I had an array with a lot of \u1234 escapes
in it, and couldn't find a way to do it easily. I came up with this:
${arr:gs/(#b)'\\\\u(????)/${(#):-$(( 16#$match[1] ))}'}
but it's a bit awkward to type.

The following patch adds the (g::) parameter flag which calls the
getkeystring function, and allows setting the _EMACS, _OCTAL_ESC and
_CTRL flags.

---
 Doc/Zsh/expn.yo |    8 ++++++++
 Src/subst.c     |   55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/Doc/Zsh/expn.yo b/Doc/Zsh/expn.yo
index 2c3a571..2beebd7 100644
--- a/Doc/Zsh/expn.yo
+++ b/Doc/Zsh/expn.yo
@@ -863,6 +863,14 @@ item(tt(F))(
 Join the words of arrays together using newline as a separator.
 This is a shorthand for `tt(pj:\n:)'.
 )
+item(tt(g:opts:))(
+Expand words like the echo builtin.  With the tt(o) option, octal escapes
+don't take a leading zero.  With the tt(c) option, sequences like `tt(^X)'
+are interpreted.  With the tt(e) option, interprets `tt(\M-t)' and similar
+sequences like the print builtin.  With both tt(o) and tt(e) options, behaves
+like the print builtin with the exception of the next sentence.   In none
+of these modes is `tt(\c)' interpreted.
+)
 item(tt(i))(
 Sort case-insensitively.  May be combined with `tt(n)' or `tt(O)'.
 )
diff --git a/Src/subst.c b/Src/subst.c
index 617986c..a2af01b 100644
--- a/Src/subst.c
+++ b/Src/subst.c
@@ -1607,6 +1607,10 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int ssub)
      */	
     int presc = 0;
     /*
+     * The (g) flag.  Expand words with various GETKEY_ flags.
+     */
+    int getkeys = -1;
+    /*
      * The (@) flag; interacts obscurely with qt and isarr.
      * This is one of the things that decides whether multsub
      * will produce an array, but in an extremely indirect fashion.
@@ -1932,6 +1936,36 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int ssub)
 		    presc++;
 		    break;
 
+		case 'z':
+		    t = get_strarg(++s, &arglen);
+		    if (getkeys < 0)
+			getkeys = 0;
+		    if (*t) {
+			sav = *t;
+			*t = 0;
+			while (*++s) {
+			    switch (*s) {
+			    case 'e':
+				getkeys |= GETKEY_EMACS;
+				break;
+			    case 'o':
+				getkeys |= GETKEY_OCTAL_ESC;
+				break;
+			    case 'c':
+				getkeys |= GETKEY_CTRL;
+				break;
+
+			    default:
+				*t = sav;
+				goto flagerr;
+			    }
+			}
+			*t = sav;
+			s = t + arglen - 1;
+		    } else
+			goto flagerr;
+                    break;
+
 		case 'z':
 		    shsplit = LEXFLAGS_ACTIVE;
 		    break;
@@ -3141,6 +3175,27 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int ssub)
 	opts[PROMPTPERCENT] = opp;
     }
     /*
+     * Perform GETKEY expansion
+     */
+    if (getkeys >= 0) {
+	if (isarr) {
+	    char **ap;
+
+	    if (!copied)
+		aval = arrdup(aval), copied = 1;
+	    ap = aval;
+	    for (; *ap; ap++) {
+		int len;
+		*ap = getkeystring(*ap, &len, getkeys, NULL);
+	    }
+	} else {
+	    int len;
+	    if (!copied)
+		val = dupstring(val), copied = 1;
+	    val = getkeystring(val, &len, getkeys, NULL);
+	}
+    }
+    /*
      * One of the possible set of quotes to apply, depending on
      * the repetitions of the (q) flag.
      */
-- 
1.7.4-rc1