Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14760
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Control characters in declare output |
| Date | 2018-11-01 11:06 -0400 |
| Message-ID | <mailman.3219.1541084837.1284.bug-bash@gnu.org> (permalink) |
| References | <alpine.LFD.2.21.1811010140240.7623@bugs.loonybin.net> |
On 11/1/18 2:01 AM, Rob Foehl wrote:
> Prompted (pun intended) by the recent thread on detecting missing newlines
> in command output, I'd had another look at my own version, and discovered a
> potential issue with control characters being written as-is in declare
> output.
I don't see it as much of an issue.
Minimal (harmless) reproducer:
>
> ╶➤ x () { echo $'\e[31m'"oops"$'\e[0m'; }
>
> ╶➤ declare -f x
> x ()
> {
> echo ''"oops"''
> }
>
> Emits the string in red in a terminal. Any instances with control
> sequences that do anything more invasive with the terminal cause more trouble.
As documented, $'...' strings are expanded and converted to single-quoted
strings by the parser. In this case, that means while the function
definition is read and parsed, so the actual definition includes raw
control characters. It's difficult to make a good case for escaping these
characters while printing the function definition, which has to print
commands, while printing variable values is much more limited in scope.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Control characters in declare output Chet Ramey <chet.ramey@case.edu> - 2018-11-01 11:06 -0400
csiph-web