Configuration Information [Automatically generated, do not change]:
Machine: The Book
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
Phonetic CFLAGS: /ˈɡoʊ.toʊ/
uname output: Sudocode 1.0.0-aleph-0 λογ-OS ϺΜΠ PREEMPT_DYNAMIC ευ-Fri
08:21 ευTC 20XY Bk GNU/Linux

Bash Version: latest
Patch Level: 0
Release Status: release

Description:

    Fix interaction between shell history and case-in-comsub

    In interactive mode, the following lines all behave
    as expected. That is, they do not cause history expansion,
    and they each execute without printing to stderr.

    1. echo $(if true; then echo 'hi!'; fi)
    2. echo $(if false; then echo 'hi!'; fi)
    3. echo "$(if true; then echo 'hi!'; fi)"
    4. echo "$(if false; then echo 'hi!'; fi)"
    5. echo $(case a in a) echo 'hi!';; esac)
    6. echo $(case a in b) echo 'hi!';; esac)

    The same correct (lack of) behavior is observed for all other
    forms of conditional, whether the condition is true or false,
    and whether the outer comsub is double quoted or not quoted.
    (e.g., for, while, until, [[ ]] && { }, [ ] || { }, etc.)

    However, in cases of the following form:

    7. echo "$(case a in a) echo 'hi!';; esac)"
    8. echo "$(case a in b) echo 'hi!';; esac)"

    we get the following output, even in cases for which the
    enclosing case pattern is false.

    > bash: !': event not found

    Commands of the above form may print other strings, depending
    on the contents of the shell's history.

    This commit provides a simple first draft of a fix in subst.c,
    and adds the file tests/comsub28.sub to verify that history
    expansion in single quotes no longer occurs in these contexts.

    Limitations:
    * The current fix does not attempt to address arbitrarily nested
      case statements inside comsubs. A more complete fix to this
      problem would be better handled by someone with more familiarity
      with the codebase (e.g. Chet, if he thinks it's worth the time.)
    * Another reason for not pursuing a more general fix at the moment
      is that I'm not sure whether this bug is a symptom of a more
      general problem in the parser related to case stmts inside comsubs.
      I mention this only because I fixed a similar bug back in 2020
      related to SEMI_SEMI_AND inside of case statements within comsubs,
      which I never got around to submitting and which was eventually
      fixed. Since this is the second time I've encountered $(case)
      related bugs, I decided to keep the fix simple for now, since I'm
      not sure if this fix is just addressing a symptom and not the cause.

    I'm by no means an expert on the code base, so apologies in
    advance for any glaringly obvious errors or bad decisions.

Repeat-By:

        echo "$(case a in b) echo 'hi!';; esac)"

Fix:

        Current version of the fix uses a simple heuristic check
        (to see if we're inside a `case` statement) to the function
        `skip_to_histexp` in the file `subst.c`.

Reply via email to