Path: csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Rob Foehl Newsgroups: gnu.bash.bug Subject: Control characters in declare output Date: Thu, 1 Nov 2018 02:01:07 -0400 (EDT) Lines: 37 Approved: bug-bash@gnu.org Message-ID: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1541052090 29091 208.118.235.17 (1 Nov 2018 06:01:30 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Virus-Scanned: amavisd-new at loonybin.net X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:470:1f07:3b6::f2 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14755 Prompted (pun intended) by the recent thread on detecting missing newline= s=20 in command output, I'd had another look at my own version, and discovered= =20 a potential issue with control characters being written as-is in declare=20 output. Minimal (harmless) reproducer: =E2=95=B6=E2=9E=A4 x () { echo $'\e[31m'"oops"$'\e[0m'; } =E2=95=B6=E2=9E=A4 declare -f x x () { echo ''"oops"'' } Emits the string in red in a terminal. Any instances with control=20 sequences that do anything more invasive with the terminal cause more=20 trouble. Similarly: =E2=95=B6=E2=9E=A4 y=3D$'\e[31m'"oops"$'\e[0m' =E2=95=B6=E2=9E=A4 declare -p y declare -- y=3D"oops" String again in red. Compare with: =E2=95=B6=E2=9E=A4 set |grep ^y=3D y=3D$'\E[31moops\E[0m' No issues with the set output. As they can both be usefully re-read by=20 the shell, is there any possibility for similarly escaped output from the= =20 declare builtin, instead of raw control characters? -Rob