Re: Control characters in declare output

[L A Walsh]

On 10/31/2018 11:01 PM, 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.  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 
  

BTW, to keep that red from turning your terminal red, I used:
 read _CRST <<<"$(tput sgr0)"   #Reset
 read _CRED <<<"$(tput setaf 1)"  #RED
 read _CGREEN <<<"$(tput setaf 2)"  #GREEN
 read _CBLD <<<"$(tput bold)"   #Bold

And in usage:
[[ $UID -eq 0 ]] && {
   _prompt_open="$_CBLD$_CRED"
   _prompt="#"
   _prompt_close="$_CRST"
 }


   That way I can display the file on a screen without the control 
characters

actually changing the color of the terminal.

(just in case you might be looking for a way around that behavior).

Re: Control characters in declare output

[Chet Ramey]

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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Control characters in declare output

[Rob Foehl]

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.  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.


Similarly:

╶➤ y=$'\e[31m'"oops"$'\e[0m'

╶➤ declare -p y
declare -- y="oops"

String again in red.  Compare with:

╶➤ set |grep ^y=
y=$'\E[31moops\E[0m'

No issues with the set output.  As they can both be usefully re-read by 
the shell, is there any possibility for similarly escaped output from the 
declare builtin, instead of raw control characters?


-Rob