help-bash
[Top][All Lists]
Advanced

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

Re: quote interpretation via vars without eval


From: Koichi Murase
Subject: Re: quote interpretation via vars without eval
Date: Sun, 14 Mar 2021 01:57:10 +0800

Thank you for the explanation

2021年3月13日(土) 23:02 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>:
> well, i cannot
> this is my text i do as i can
> tried to type a period after my small short sentenses, made me no sense.. im 
> sorry
> .. i dont plan on obfuscating, neither code nor mail text, or insult, or so, 
> its just me and so it is

OK, so... knowing the fact that the style is non-standard and may
confuse the readers, you intentionally continue to write emails in
this style because this is an important part of your identity. Is that
what you mean? I'm not a native speaker of English, so I don't know
actually what this style is, but is this a dialect of your hometown or
nation? Or an established writing style in some literature fields of
lyrics or poems? Anyway, even if you don't intend to obfuscate it, the
resulting style is certainly obfuscating in particular for non-native
speakers like me, which is a real problem but not a philosophical
matter of good or bad.

> i had many such advices, about oudated wrong formatting rules

Does this mean the style you use was popular and common in old days?
(I assumed `oudated' means `outdated' but maybe this is again a
misunderstanding.) Can you point some web pages that document this
style if any? If this is your own style and you haven't documented the
style, maybe you can write texts in both your style and plainer
English side-by-side so that readers can understand the style by
comparing the texts. It's just a naive suggestion, but in this way,
you don't have to bend your style and also can advertise your style
(though I'm not sure if anyone is interested in it), and also, readers
who are not familiar with this style can understand the meaning
correctly.

> assume newline be the dot, or at least an important meaning separator

I see. Thank you for the explanation.

> settment i meant, by set-ing

Thank you for the clarification.

> also you misunderstood my quotes question
>
> it was related to internal parsing of bash of strings
> not arguments
> i set declare [-opts] "$var" where $var is complex array stuff
> and i noticed, cause i format $var by declare -p output
>
> so to summarize, i have one string, with quotes data inside, which declare 
> "$var" parses right

I still don't have confidence that I get the situation. Can you show
an explicit example for the content of the variable `var'? For
example, are you talking about the cases like the following?

$ def='arr=("foo" "$(echo bar)" <(echo dummy))'
$ declare -a "$def"
$ declare -p arr
declare -a arr=([0]="foo" [1]="bar" [2]="/dev/fd/63")

> my question is, where else this behavior

OK, so do you want to get the complete list of the places where
arbitrary code execution can occur? Also, you want to know how to
suppress this eval-like behavior of `declare'?

> i dont look for arguments, im looking for quote interpretation by flat 
> strings, eg when needing to do eval to make em interpreted

I think this is a good chance, so let me ask: What is `em'? I see this
word many times in your other replies but was wondering what this
means. Also, I couldn't get the meaning of this whole sentence. Can
you explain it in more detail?

> declare "$complex" obvisously parses them right, " quotes as also $'
> .. question .. which other builtins would interpret $complex quote-right
> i suppose declare would also parse ' and \ right but i didnt try
>
> cmd='a "complex command"' ; eval "$cmd"
>  is needed to interpret the quotes
> i dont need it much for commands, more for safe variable assignments ( i 
> learnt some lessions about how eval can explode and wrong code can harm )
>

--
Koichi



reply via email to

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