Re: Help-bash Digest, Vol 113, Issue 21

[Alex fxmbsw7 Ratchev]

side code:

args=( a b c )
"${args[@]}"
eval "${args[@]}"

there are aliases for chained assignments

you need to quote eval "$var" to make it expand right and not space
separatrd

complex='[[ x ]] && echo x'
eval "$complex"

you mostly will fail eval cause the resulting command might do harm
understand, that the string\s that eval takes in the end _must_ look
_exactly_ like written by you on the console properly
so its a strings in strings and quotes there and subquotes issue

as for your example
i think this should sufficie

args=( -one 'two three' -four ./CMake"$var"'stuffix' )
find .. "${args[@]}"

On Sun, Mar 14, 2021 at 12:21 PM Budi <budikusasi@gmail.com> wrote:

> How to expand only bash $variable at any certain point of anything
> (time, condition, etc) ?
> as this works :
>   i=1
>   u="sum = $i + \$o"
>   o=two; n=$(eval echo $u)
>
> to equalize to n='sum = 1 + two'
>
> the truth,  $(eval echo $)  won't work for complex long expression
> The real case the u above is some find arguments as, e.g., the output of
> set -x:
> C='( -ipath /home/olive/build/CMakeFiles/* (  ( -type d ( -regex
> .*\s.* -printf '\''%p/'\''\n -o -printf %p/\n ) -o ( -regex .*\s.*
> -printf '\''%p'\''\n -o -printf %p\n ) ) ) -o -ipath
> /home/olive/build/CMakeFiles -type f ( -regex .*\s.* -printf
> '\''%p'\''\n -o -printf %p\n ) -o -iregex .{17}/.+/CMakeFiles$RP (
> -type d ( -regex .*\s.* -printf '\''%p/'\''\n -o -printf %p/\n ) -o (
> -regex .*\s.* -printf '\''%p'\''\n -o -printf %p\n ) ) )'
>
> So $RP there is big need to be expanded after once expansion, like $o
> sample.
>
> So how to expand only a bash variable at any certain arbitrary point
> without touch any else expression in which the var. sit
>
>
>
> On 3/13/21, help-bash-request@gnu.org <help-bash-request@gnu.org> wrote:
> > Send Help-bash mailing list submissions to
> >       help-bash@gnu.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       https://lists.gnu.org/mailman/listinfo/help-bash
> > or, via email, send a message with subject or body 'help' to
> >       help-bash-request@gnu.org
> >
> > You can reach the person managing the list at
> >       help-bash-owner@gnu.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Help-bash digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: idea about negative indexed array keys (Alex fxmbsw7 Ratchev)
> >    2. Re: quote interpretation via vars without eval
> >       (Lawrence Velázquez)
> >    3. Re: quote interpretation via vars without eval
> >       (Alex fxmbsw7 Ratchev)
> >    4. Re: quote interpretation via vars without eval (Chet Ramey)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sat, 13 Mar 2021 16:32:33 +0100
> > From: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> > To: help-bash <help-bash@gnu.org>
> > Subject: Re: idea about negative indexed array keys
> > Message-ID:
> >       <CAALKErE0eVucQJ2HsgdurqQHMDmjzdzE59U==
> jm+oRFffYx7xw@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > correction of text
> >
> > past week*s*
> >
> > *and i know it didnt happen with bash 4 cause i dont have bash 4 since
> > looong*
> > *who knows what's been*
> >
> > On Sat, Mar 13, 2021 at 3:43 PM Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> > wrote:
> >
> >> this one looks exactly like the one i rememeber
> >> but there are factical mismatches, it happened in the past week, with
> bash
> >> 5.1.4-maint
> >> but seemfully somewhere else than direct array index
> >>
> >> On Sat, Mar 13, 2021 at 3:36 PM Greg Wooledge <greg@wooledge.org>
> wrote:
> >>
> >>> On Fri, Mar 12, 2021 at 05:11:19PM -0500, Eli Schwartz wrote:
> >>> > On 3/12/21 4:58 PM, Alex fxmbsw7 Ratchev wrote:
> >>> > > i saw, ${arr[-1]} == syntax error
> >>> > >
> >>> > > what about implenting it, -0 is the last -1 is the second last etc
> >>> > >
> >>> > > such negative values are already in ${..:<>:<>} implented, as a
> good
> >>> small
> >>> > > statement for the same style
> >>> >
> >>> > How did you accomplish the task of getting a syntax error for this? I
> >>> > managed it with:
> >>> >
> >>> > $ declare arr=(foo bar baz "syntax error")
> >>> > $ echo "${arr[-1]}"; echo "${arr[-2]}"
> >>> > syntax error
> >>> > baz
> >>>
> >>> unicorn:~$ bash-4.1 -c 'a=(a b c); echo "${a[-1]}"'
> >>> bash-4.1: a: bad array subscript
> >>>
> >>> unicorn:~$ bash-4.2 -c 'a=(a b c); echo "${a[-1]}"'
> >>> c
> >>>
> >>> Is that close enough?
> >>>
> >>>
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Sat, 13 Mar 2021 10:41:06 -0500
> > From: Lawrence Velázquez <vq@larryv.me>
> > To: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> > Cc: Koichi Murase <myoga.murase@gmail.com>, help-bash@gnu.org
> > Subject: Re: quote interpretation via vars without eval
> > Message-ID: <6CF08637-6DB7-4298-8B37-4B62F61FDA4B@larryv.me>
> > Content-Type: text/plain;     charset=us-ascii
> >
> >> On Mar 13, 2021, at 10:02 AM, Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> >> wrote:
> >>
> >> i had many such advices, about oudated wrong formatting rules
> >
> > Consider the possibility that standards and conventions are not,
> > in fact, always "outdated" and "wrong", even if you don't understand
> > or like them.
> >
> >> there is also misunderstanding totally
> >> settment i meant, by set-ing
> >> also you misunderstood my quotes question
> >
> > You should not be surprised when the rest of us fail to understand
> > your avant-garde grammar, syntax, and vocabulary.
> >
> >> it was related to internal parsing of bash of strings
> >> not arguments
> >> i set declare [-opts] "$var" where $var is complex array stuff
> >
> > There might have been less of a "misunderstanding" if you'd actually
> > mentioned this in your original email.
> >
> > vq
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Sat, 13 Mar 2021 16:51:18 +0100
> > From: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> > To: Lawrence Velázquez <vq@larryv.me>
> > Cc: Koichi Murase <myoga.murase@gmail.com>, help-bash
> >       <help-bash@gnu.org>
> > Subject: Re: quote interpretation via vars without eval
> > Message-ID:
> >       <CAALKErEiGjfH_6OjtDeYNGADzyKWBg0K=
> Wg2Dqu6BveYkciX7g@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > you know, you didnt spend 10 years and still around psychiatry aka poison
> > prison cause your parents lied you in there, and where is your public
> self
> > written server site and stuff for public
> > i had it, ill do it again
> >
> > from my 1. mail :
> > 'i was doing declare -p to again modifications'
> > 'noticed i can include quotes inside the declare settment ( declare
> [-opts]
> > "$res" )'
> >
> > $res being the most common var name for str to result modifications i
> know
> >
> > 'backslashes, quotes, etc, in vars, as arguments' <- as arguments there i
> > mention args cause thats a declare arg amd i am or was looking for making
> > shell quoting or more features separately expand
> > instead of having to eval
> >
> > peace
> >
> > On Sat, Mar 13, 2021 at 4:41 PM Lawrence Velázquez <vq@larryv.me> wrote:
> >
> >> > On Mar 13, 2021, at 10:02 AM, Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com
> >
> >> wrote:
> >> >
> >> > i had many such advices, about oudated wrong formatting rules
> >>
> >> Consider the possibility that standards and conventions are not,
> >> in fact, always "outdated" and "wrong", even if you don't understand
> >> or like them.
> >>
> >> > there is also misunderstanding totally
> >> > settment i meant, by set-ing
> >> > also you misunderstood my quotes question
> >>
> >> You should not be surprised when the rest of us fail to understand
> >> your avant-garde grammar, syntax, and vocabulary.
> >>
> >> > it was related to internal parsing of bash of strings
> >> > not arguments
> >> > i set declare [-opts] "$var" where $var is complex array stuff
> >>
> >> There might have been less of a "misunderstanding" if you'd actually
> >> mentioned this in your original email.
> >>
> >> vq
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Sat, 13 Mar 2021 11:53:10 -0500
> > From: Chet Ramey <chet.ramey@case.edu>
> > To: Koichi Murase <myoga.murase@gmail.com>, Alex fxmbsw7 Ratchev
> >       <fxmbsw7@gmail.com>
> > Cc: chet.ramey@case.edu, help-bash <help-bash@gnu.org>
> > Subject: Re: quote interpretation via vars without eval
> > Message-ID: <6ca00a77-b931-93d5-3746-8b2d393e0283@case.edu>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > On 3/13/21 6:35 AM, Koichi Murase wrote:
> >> 2021年3月13日(土) 7:59 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>:
> >>> 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 ?
> >>
> >> `declare' is a command that takes string arguments [but with an
> >> exception for the array assignments of the form `arr=(...)']. You can
> >> quote them since they are treated as normal arguments.
> >
> > Not exactly. Builtins like `declare' and `local' (and `export' and
> > `readonly') that accept assignment statements are so-called "declaration
> > commands."
> >
> > If the shell can recognize the argument to a declaration command as an
> > assignment statement while parsing, it's subjected to the same
> > expansions as an assignment statement. In particular, that means pathname
> > expansion and word splitting are not performed.
> >
> > POSIX approved an interpretation concerning "declaration utilities" back
> in
> > 2011, and it will be a part of the upcoming issue 8.
> >
> > https://www.austingroupbugs.net/view.php?id=351
> >
> > Bash-4.0 and later versions attempt to expand assignment statement
> > arguments to declaration commands the same way as standalone assignment
> > statements.
> >
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> >                ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRU    chet@case.edu
> http://tiswww.cwru.edu/~chet/
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Help-bash mailing list
> > Help-bash@gnu.org
> > https://lists.gnu.org/mailman/listinfo/help-bash
> >
> >
> > ------------------------------
> >
> > End of Help-bash Digest, Vol 113, Issue 21
> > ******************************************
> >
>
>