Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16080 > unrolled thread

Re: verbosity of DEBUG trap following edit-and-execute-command

Started byChet Ramey <chet.ramey@case.edu>
First post2020-04-03 12:13 -0400
Last post2020-04-03 12:13 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: verbosity of DEBUG trap following edit-and-execute-command Chet Ramey <chet.ramey@case.edu> - 2020-04-03 12:13 -0400

#16080 — Re: verbosity of DEBUG trap following edit-and-execute-command

FromChet Ramey <chet.ramey@case.edu>
Date2020-04-03 12:13 -0400
SubjectRe: verbosity of DEBUG trap following edit-and-execute-command
Message-ID<mailman.77.1585930425.2644.bug-bash@gnu.org>
On 4/2/20 12:50 PM, Ami Fischman wrote:
> After the editor invoked by edit-and-execute-command exits, the
> about-to-be-executed command (as edited by the editor) is echoed, but seemingly
> as if [set -v] was set, causing a command executed before the edited command as
> the result of a trap DEBUG to be echoed, as well. This is annoying for example
> when using the DEBUG trap as a way to change colors as demonstrated in
> https://nigeltao.github.io/blog/2018/colorful-text.html#shell-prompts

OK. The editing commands are just a convenient way to execute the `fc -e -'
command, starting with a file consisting of the command being edited. After
editing, that file is executed like a shell script, and set -v is indeed
temporarily enabled to show the edited commands being read. Since these
edited commands are saved in the history list, we use the parser to honor
the various history list config variables (command-oriented history,
history ignoring, etc.) instead of just dumping the file before it gets
executed. This is also how you get compound commands in the file echoed
in their entirety before they're executed. So far so good.

Since this is all wrapped up in existing shell features, there's no good
way to isolate the fc behavior. I've seen suggestions on here to disable
set -v while running the DEBUG trap unconditionally, like ksh93 does.

What do you think? Should bash just disable set -v when running the DEBUG
trap?

Chet

-- 
``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/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web