[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: verbosity of DEBUG trap following edit-and-execute-command
From: |
Chet Ramey |
Subject: |
Re: verbosity of DEBUG trap following edit-and-execute-command |
Date: |
Fri, 3 Apr 2020 12:13:35 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
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/