I see that, Chet. But it's not necessarily supposed to be echoed, that's what I'm saying. It's counterintuitive that fc prints the output. In fact, the output could very confusing. I have a complicated expression in the DEBUG trap that doesn't produce any output by itself, but this is what I see after calling fc, typing ls and leaving the editor:
[carlos@netbook ~]$ fc ls [[ $BASH_COMMAND == "termic_hook @prompt" ]] || termic_hook "$BASH_COMMAND" get_profile $*) get_profile $* TERMIC_PROFILES $*) TERMIC_PROFILES $* basename $1) basename $1 TERMIC_PROFILES $base $*) TERMIC_PROFILES $base $* TERMIC_PROFILES $base) TERMIC_PROFILES $base Anki apps bin blog blog2 books down movies music node_modules notes post.html post.rst store tmp work "ls" is ok, the last line is expected, but my debug trap doesn't output what it's being listed in between, it's more like if I had "set -x". It's not even that the trap is being called recursively. Someone else got into this issue before: http://stackoverflow.com/questions/12363901/how-to-use-debug-trap-without-echoing-trap-command-in-fix-command Of course, it's possible to alias fc to reset the trap before calling the editor and restore after exiting, but it's a hack. On Tue, Sep 24, 2013 at 11:18 AM, Chet Ramey <chet.ra...@case.edu> wrote: > On 9/19/13 2:12 PM, Carlos Pita wrote: > >> Bash Version: 4.2 >> Patch Level: 45 >> Release Status: release >> >> Description: >> >> If you set a DEBUG trap fc echoes it along the edited commands after >> leaving editor. > > Sure: the DEBUG trap is supposed to be executed before every simple > command (and a few other types). > > Chet > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
