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 c...@case.edu http://tiswww.cwru.edu/~chet/