Re: quote interpretation via vars without eval

[Alex fxmbsw7 Ratchev]

about my language, i mean my commons, they're rather smooth english talking
this very similiar to why i dont uppercase, its nonsense, and its work, and
its ugly
i learnt much by computer chat, more realtime multiline (later now irc
oneline) - i learned english on computers ( mac os pre x ) i mean it made
sense, more sense than super epyc processors nowdays with crappy software
.. :/

about find, it does, actually i didnt benchmark but its mainly two reasons,
one is find may be slower ( 2x instead of 1x ) and actually it prints
filenames malformed with ? question marks instead of exact meaning
i attached both files there
i do in PROMPT_COMMAND then 'var=$( this )' and in PS1 $var

..
the text lacking ( context ), is the slang known along when parsing the
text, from beginning to end
like its nothing special, just spoken out
i speak as i type and i speak what i type
else stuff doesnt work out

so we're just two different persons off different rules and cultures

.. your interpretation of my question, is 100 % perfectly true as history
and trueness is
word up :))

about the codes with substitution i sent, i abondonded them cause they
didnt work out ( especially they're at small directories count already too
slow )
i didnt expect this off bash, 100 different statements or less in @( <here>
) is very slow :/ no 1*n speed or 1/2, .. cant express, its just wrongly
slow

you are too complete .. kiochi .. :))

about the quotes and the topic, yes where else, but not in eval
where i can do $var and $var contains quote separated stuff and bash
interpretes this so ( declare "$var" did .. but its rare, otherwise to
utilize quote parsing bash has to eval to succeed its own functions .. .. )

i guess it may be only declare i can use it i dunno where else it could be
useful excepts for commands where sadly eval must be used

you know
var=( $'"a b c"' 'a\ b\ c' ) ; printf %s--\  ${var[@]}
"a-- b-- c"-- a\-- b\-- c--

i didnt quote here to expand
in the buggy subst script i dont quote cause i became to know when
assignments are done they dont have to be quoted
only when used as arguments

var=( $'"a b c"' 'a\ b\ c' ) ; eval printf %s--\  ${var[@]}
a b c--a b c--

nothing against eval, excepts one gotta be pro to not produuce buggable code
like my subst code that i .off'ed, nowork :))
life is hard :))

thank you kindly, \./ peace


On Mon, Mar 15, 2021 at 12:03 AM Koichi Murase <myoga.murase@gmail.com>
wrote:

> > 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
>

prptrecents
Description: Binary data

prptrecents.gawk
Description: Binary data