On Fri, Feb 4, 2022 at 10:18 PM Robert Elz <k...@munnari.oz.au> wrote:
>
> Date: Fri, 4 Feb 2022 21:06:11 +0100
> From: Alex fxmbsw7 Ratchev <fxmb...@gmail.com>
> Message-ID:
> <CAALKErH2N+EiVW+=sVBNYrpYa5JiWVrVjCe1YT=neguujcr...@mail.gmail.com>
>
>
> | now changing this to dynamic eof marker
>
> There is no such thing. Unlikely (*VERY* unlikely) there ever will be.
>
> | cat <<$( printf leet )
> | $( printf leet )
> | $( printf leet )
> | notice the two spaces in the middle to not match eof
>
> Yes, that is supposed to work, and "cat" should write a single
> line containing "leet". The end word is *never* expanded, not
> the copy of it after the << operator, and not the one that terminates
> the here doc data (the former gets quote removal, but there are none
> here to remove).
i guess thats not rendundant enough for bash, or yet too early
cause it doesnt interpret at runtime much yet, it just maps text or
chars to read until
also its a high security risk, how to say... to let $( and all << as
separator is all nonsense
> Since there are no quotes in the end word on the << operator, the
> here doc text is expanded (when used, not when read - though in this
> example it is used immediately when it is read, so that also makes no
> apparent difference - but giving examples where it does is easy).
> That includes expanding command substitutions inside the here doc
> text (which does not include the end word). The $( printf leet )
> produces "leet" on stdout, which replaces the command substitution
> text in the here doc, so cat reads (and outputs) the single line "leet".
>
> | thats valid code, cause eof is written twice ( the $( .. ) code )
>
> No idea what you mean there - but yes, the end word must be written
> twice, once after << and once after the here doc data. If you're
> counting the one that was inside the here doc (because it looks similar)
> then that's pure co-incidence, that one could be anything, and while altering
> that might change the input cat reads (and hence writes) it has no other
> impact on anything at all. You could even omit it entirely.
written twice.. to match eof matching, but why
if you start your << with $( printf leet ) or $( printf leet ) and
just wanna end with 'leet' .. .. .. you need command subst ( aka same
code ) to match instead of the resulting text ? hm
well there are many sides of coding i see
> | but
> |
> | cat <<$( printf end )
> | $( printf end )
> | # here it should already end the heredoc parser
>
> No it shouldn't. The 2nd line there doesn't have enough spaces,
> they're not the same.
i didnt continue the last line that matched the same command substitution
it was a try to example from a view of interpreting the text dynamically
still a bit unclear to me
>
> The end word (after <<) is parsed as a command substitution, to find its
> end, but is never expanded (the code in it is never executed) - all the
> parsing accomplishes in this case is to allow the correct ')' to be found
> so the command substitution text ends at the correct place - beyond that
> it is ignored.
what are you saying isnt clear to me
do you want $( to expand or not
i thought you wanted
> Perhaps a different example - I'm sure you know that in $(( )) you can
> embed an arithmetic expression, and if you try and do something like
>
> $(( data 2 ))
>
> you'll get a syntax error, because "data 2" is not a valid arithmetic
> expression.
you get this cause alias parsing is disabled, cause $(( is a command
an alias $(( would work
but bash doesnt handle the ending right yet
hint to chet: its just sad it results yet early in a code parse error
#!/usr/bin/env -S bash
shopt -s expand_aliases
alias -- \
p='printf %s\\n ' \
assign='assign=$(( ' begin='$(( ' end=')) ' \
sep=', ' \
plus=+\ minus=-\ div=/\ mul=\*\ \
for d in "1 + 2" "1 plus 2"
do
alias -- data="$d "
p begin data end
done
nevermind i realized its exactly the same and i understood why its erroring
alias.sh: line 14: unexpected EOF while looking for matching `)'
alias.sh: line 16: syntax error: unexpected end of file
cause bash doesnt parse aliases yet into pre parse state
yea i just wish it would, such as no code error for valid code
> But collecting the text of arithmetic is done by simply looking for the '))'
> that matches the '((' after the opening '$' (taking account of any other
> parentheses that might exist in the expression). The actual arithmetic isn't
> evaluated (or parsed) until it is to be expanded - it is simply a string.
>
> That means you can do (should be able to do, not all shells work properly)
>
> cat <<$(( any random trash *$ ^%%\ # you like - except for parentheses ))
factically, this is no right complete shell construct to execute, then
cause random trash wont match
so its unmatched matcher
> and it should work fine (the here doc text ends with the exact same string,
> spacing and all). Even the "except for parentheses" just means that any
> parentheses that occur must balance correctly - otherwise the correct '))'
> won't be detected.
>
> kre
>
>
>
