I have following (part) of a shell script (inside t7508-status.sh
):
test_expect_success 'status --column' '
cat >expect <<\EOF &&
# On branch main
# Your branch and '\''upstream'\'' have diverged,
# and have 1 and 2 different commits each, respectively.
# (use "git pull" to merge the remote branch into yours)
#
# Changes to be committed:
# (use "git restore --staged <file>..." to unstage)
# new file: dir2/added
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git restore <file>..." to discard changes in working directory)
# modified: dir1/modified
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# dir1/untracked dir2/untracked
# dir2/modified untracked
#
EOF
COLUMNS=50 git -c status.displayCommentPrefix=true status --column="column dense" >output &&
test_cmp expect output
'
OK, the first quoted part seems obvious status --column
, but the second quoted parts starts at the end of the first line and ends IMHO in the third line
# Your branch and '\''upstream'\'' have diverged,
^--here
Then an escaped quote follows by a new quoted part? Or does the <<\EOF ... EOF
has higher priority? The reason for my question is to create correct syntax coloring using ANTLR.
CodePudding user response:
You are correct: the first quoted part ends on the third line, and is immediately followed by an escaped single-quote which is followed by another single-quoted section. Then the same thing happens again 8 characters later. Since there's no space or other delimiter between these sections, they're treated as parts of a single long string (an argument to test_expect_success
).
Since the <<\EOF
and #
marks occur inside single-quoted sections, they have no syntactic significance at all; they are just literal characters that'll be passed to test_expect_success
as part of the argument. In a single-quoted string, only thing with any syntactic significance is a single-quote (which just indicates the end of the single-quoted section).
You can see the result of this by replacing the test_expect_success
command with printf '[%s]\n'
, and seeing what gets printed inside the [ ]
marks.