Re: [Help-bash] Escaping in backquote string in double quoted strings -- query about bash intent

[KHMan]

On 5/15/2019 2:20 AM, Chet Ramey wrote:
> On 5/7/19 8:52 AM, KHMan wrote:
>
> > 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.
>
> The backquotes are not quote characters.

Yes, from your first reply I guess I understand better what the 
intent was.

For the majority of casual bash scripting users (like myself), I 
suppose bash is expected to work as expected. It's good to have 
some authoritative feedback sometimes when there are so many 
details to handle when dealing with shell script highlighting. 
Often, the use of bash terminology etc is not second nature to 
those of us who use bash casually -- it hampers one's ability to 
grok precisely how a line of script is being parsed.


> > 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.
>
> The idea is that you don't want a double quote inside the command
> substitution to terminate the quoted string, so you consume it as a single
> word. It's the difference between
>
> $ cat bq
> echo "`echo "<b>"`"
> $ ./bash ./bq
> <b>
>
> and
>
> $ ksh93 ./bq
> ./bq[1]: b: cannot open [No such file or directory]

Luckily for me nobody has complained about syntax highlighting 
breakage for ksh scripts in Scintilla-based editors for more than 
a decade. :-) But it was painful to have to handle some extra 
syntax of zsh.


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