help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-bash] Escaping in backquote string in double quoted strings -- que


From: KHMan
Subject: [Help-bash] Escaping in backquote string in double quoted strings -- query about bash intent
Date: Tue, 7 May 2019 20:52:02 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

Hi all,

Further to my posting on 2019-05-03, I would like to direct the following to those who work on bash. (Thanks to Greg and Andy for the replies, but it is not the answer that I was seeking since programmers will most certainly encounter these kind of things in an editor and then post bug tickets when highlighting breaks.)

If this is inappropriate for help-bash, I can repost it on the dev list. But here I am only trying to understand the _intention_ of the code so that I can code the appropriate highlighting fix -- it's really still a glorified shell user's query.


So looking at the source code for bash-5.0:

parse.y[4971]:
      /* Parse a matched pair of quote characters. */
      if MBTEST(shellquote (character))
        {
          push_delimiter (dstack, character);
ttok = parse_matched_pair (character, character, character, &ttoklen, (character == '`') ? P_COMMAND : 0);
          pop_delimiter (dstack);

I notice that many parse_matched_pair calls were bracketed by push_delimiter and pop_delimiter. But here:

parse.y[3734]:
/* Parse an old-style command substitution within double quotes as a
         single word. */
      /* XXX - sh and ksh93 don't do this - XXX */
      else if MBTEST(open == '"' && ch == '`')
        {
          nestret = parse_matched_pair (0, '`', '`', &nestlen, rflags);

Here, for the case of a backquote string inside a double quoted string, there is no push_delimiter and pop_delimiter. If current_delimiter drives escape behaviour, this would account for the observed output for the test cases.

I guess the comment means something but I only know how to write simple bash scripts so I have no idea what it really means:
    Parse an old-style command substitution within
    double quotes as a single word.

So what's the intention of bash here? What is bash trying to do and is the escape behaviour for double quotes (\") in this situation (as presented in my first 2019-05-03 posting) unintended behaviour or intended behaviour? If it is intended behaviour, what is the rationale for it?


Thanks,
--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia





reply via email to

[Prev in Thread] Current Thread [Next in Thread]