Re: quote interpretation via vars without eval

[Koichi Murase]

> On Sat, Mar 13, 2021 at 8:42 PM Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> 
> wrote:
>> in short when i thought about all those 'styles' its just street spoken 
>> language as text ( my emails )

Just a naive question, do the styles, such as periods vs newlines (at
the end of sentences), "I" vs "i", "I'm" vs "im", make any distinction
in the spoken language? The spoken language may be related to grammar
and vocabulary, but it seems to me that the spoken language has
nothing to do with which formatting style should be used in the
written representation.

It is still obscure for me to translate the spoken language into texts
unmodified because texts lack much contextual information that was
carried by tone, pitches, etc. in the original verbal communication.
Consistent usage of commas, periods, capitalization, etc.---although
they are not pronounced in the spoken language---supplements a part of
such missing information within grammatically well-structured
sentences. I understand you don't like it, but I don't agree that
these formatting rules don't make sense.

>> about coding, i was modifying var=$( declare -p arr ) with many assignments, 
>> see attached script
>> its doesnt work anymore, i gotta recode it
>> it separates all files * minus dirs */ via string assignments, instead of 
>> slow loops
>>
>> i dont count much on it, however it was working, didnt benchmark ( i do so 
>> cause speed )

Thank you for the explanation of how you use `declare -A "$var"' and
what was the original purpose. But I still don't understand the
original question. Maybe I am completely failing to understand the
question. Let me confirm if my interpretation of your language is
correct:

> i was doing declare -p to again modifications, and noticed i can include
> quotes inside the declare settment ( declare [-opts] "$res" )
> where else do the quotes get interpreted, can you write a short list ?

I assumed that the newline between the first and second lines doesn't
have the role of a separator although it contradicts your explanation
that the newline is an important meaningful separator. My
interpretation is this:

    " I tried to modify `declare -p' again and noticed that I can
    include quotes inside declare assignments of the form `declare
    [-opts] "$res"'. Could you briefly list up other places where the
    quotes get interpreted? "

But maybe something is wrong because in your example there are no
quotes in the value of the variable `x1'. When there are filenames
with quotes, the variables `xa', `xd', and `xf' can contain some
quotes, but there is no mention of that. Also, if one cares about such
a general case, one also needs to consider the possible filenames of
the form `$(malicious-code)' which would cause problems in these
examples.

Anyway, if one answers the question "Where the quotes get
interpreted", there are so many places that don't fit into a "short"
list. I think you can search the Bash manual with "quote removal". But
I actually guess you are interested in a specific type of context
where the quote removal occurs instead of the general context, which I
couldn't get from your explanation so far.

>> ' em ' in short street slang for ' them ' , or also ' dem '
>> appears in gangsta rap songs or jamaican raegge or whatever thats called much

Thank you for the explanation. It seems they are normally written as
«'em» in texts, which was the reason I couldn't find it in Web
dictionaries.

>> .. the sentense ..
>> declare -a "$var" # as you did # did interprete quotes
>> where else to
>> i think chet exactly answered with a new demanded posix entry

Chet has explained the syntactic treatment of the variable assignments
of the form `var=...' in POSIX which has nothing to do with quotes or
the argument of the form `"$res"' (in `declare [-opts] "$res"'). Also,
let me add that I recognize that rule but skipped the explanation in
the first reply just because I thought it is irrelevant to your
question.

2021年3月14日(日) 16:53 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>:
> here is the working 'nondirs' filter script but its not useable too slow on 
> big dirs
> maybe somewhen bash's speed can be increased, in the end its a big bunch of 
> "elem"|$'other\34elem' in a @( .. )

Is there a reason that you don't use «find "$path" -type d» and «find
"$path" ! -type d»?

--
Koichi