On 4/3/20 7:45 PM, Ami Fischman wrote:
> On Fri, Apr 3, 2020 at 9:13 AM Chet Ramey <chet.ra...@case.edu> wrote:
>> 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.
>
> I've found
> https://groups.google.com/d/topic/gnu.bash.bug/_oG51FIMDE0/discussion
> which suggests disabling [set -v] during the e-a-e-c but AFAICT doesn't talk
> about the DEBUG trap. Or are you saying that e-a-e-c is implemented using
> DEBUG?
No. The emacs and vi mode editing commands are front ends to `fc'. POSIX
requires this in various places:
"For example, in vi editing mode, typing "<ESC> v" is equivalent to:
EDITOR=vi fc"
fc executes commands from the file after editing. That file can hold an
arbitrary series of commands, so it's useful to have the shell echo the
commands as it reads them. You can't just dump a line at a time, since
there might be compound commands, and dumping the contents of the file
right after editing would be useless. So bash (and ksh93, mksh, zsh, but
not any of the ash descendents) temporarily enable `set -v' while executing
the file.
There's nothing special about those commands, so if the DEBUG trap is
set, the trap handler runs at the right time. There's nothing special
about the DEBUG trap, either, so the verbose setting that's in effect
causes echoing of those commands as they're read.
Hence the discussion topic: should bash disable set -v when executing
the DEBUG trap, should it do that just while running commands from a
file while running `fc', or should it continue with its current behavior?
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/
