[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help-bash Digest, Vol 113, Issue 29
|
From: |
Budi |
|
Subject: |
Re: Help-bash Digest, Vol 113, Issue 29 |
|
Date: |
Tue, 16 Mar 2021 15:01:13 +0000 |
How can we return from a Bash line code doing tee, ie. making another
process, within function, to return back to the function caller ?
this not work at all
fn(){
find ~+ -regextype posix-extended -iregex '.+/foo.*(bar|baz)' | tee >(
read u &&{ echo $u was found ;return 1;} )
echo Not seen
}
On 3/14/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: Help-bash Digest, Vol 113, Issue 21 (Budi)
> 2. Re: idea about negative indexed array keys (Greg Wooledge)
> 3. Re: Help-bash Digest, Vol 113, Issue 21 (Alex fxmbsw7 Ratchev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 14 Mar 2021 16:59:47 +0000
> From: Budi <budikusasi@gmail.com>
> To: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> Cc: help-bash <help-bash@gnu.org>
> Subject: Re: Help-bash Digest, Vol 113, Issue 21
> Message-ID:
> <CAH0GyZAZAyrusfBj-4zF7vjECpQ4pCPHrm8QZyx-0M3RNH-RPg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Alex fxmbsw7, you're brilliant !!
>
> SOLVED !
> God blesses you...
>
> On 3/14/21, Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:
>> 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
>>> > ******************************************
>>> >
>>>
>>>
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 14 Mar 2021 13:14:53 -0400
> From: Greg Wooledge <greg@wooledge.org>
> To: help-bash@gnu.org
> Subject: Re: idea about negative indexed array keys
> Message-ID: <YE5EjTWc03SsPIWs@wooledge.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Mar 14, 2021 at 11:46:51AM +0100, Alex fxmbsw7 Ratchev wrote:
>> i know which it was
>>
>> it was shift -1
>> to shift from the end
>>
>> is there a way to do so ? just wondering
>
> Your Subject: header still contains the phrase "indexed array" so I'm
> going to start with those.
>
> The only way to remove the largest-indexed element of an array is to
> determine what that index is, and then use unset. (Other approaches
> would require reconstructing the entire array, so I'm not counting those.)
>
> If you're trying to use an array to implement a stack, the unset
> approach is highly viable. I recommend keeping a second variable that
> holds the largest index at any given time.
>
> E.g.
>
> unicorn:~$ pop() { r=${stack[n]}; unset 'stack[n--]'; }
> unicorn:~$ push() { stack[++n]="$1"; }
> unicorn:~$ push foo; push bar; push baz; pop; echo "$r"; declare -p stack n
> baz
> declare -a stack=([1]="foo" [2]="bar")
> declare -- n="2"
>
> This works because the "stack" is under your control at all times. If
> you poke at the array without calling "pop" or "push", however, all bets
> are off.
>
> (In a real script, I would use a different variable name than "n" to
> hold the stack's highest index. And probably add some error checking,
> for the case where you try to pop from an empty stack.)
>
> If you're not trying to implement a stack, then tell us what you're
> trying to do.
>
> ----
>
> Now, let's explore the case where the Subject: header doesn't talk about
> indexed arrays. You imply that you're trying to remove the last
> positional parameter given to a script. We might guess that you're
> trying to implement a wrapper around cp, or something like that, where
> the final argument is treated specially.
>
> The literal answer to your question is: no. No, you cannot "shift from
> the end".
>
> How, then, would one implement a script that works like cp, performing
> pre-checks on the final argument?
>
> One way is to use bash's indirection feature to get the final argument.
>
> n=$#
> lastarg=${!n}
>
> This doesn't alter the positional parameters, of course. But then we can
> also use bash's parameter expansion syntax to rewrite the positional
> parameters:
>
> set -- "${@:1:n-1}"
>
> This copies the entire argument list at least once, probably more than
> once, so it's expensive. Oh well. This is bash, and if you wanted speed,
> you'd be writing in some other language.
>
> If you aren't trying to implement a script that works like cp, then tell
> us what you're trying to do.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 14 Mar 2021 20:51:44 +0100
> From: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> To: Budi <budikusasi@gmail.com>
> Cc: help-bash <help-bash@gnu.org>
> Subject: Re: Help-bash Digest, Vol 113, Issue 21
> Message-ID:
> <CAALKErGv=TM36F_jULbu0RFb9zAoYcyA+t3x9TyeVg+WzKgt_g@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> thank you sir i slept well special
> ( its about time which results experience )
>
> cheers, peace
>
> On Sun, Mar 14, 2021 at 5:59 PM Budi <budikusasi@gmail.com> wrote:
>
>> Alex fxmbsw7, you're brilliant !!
>>
>> SOLVED !
>> God blesses you...
>>
>> On 3/14/21, Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:
>> > 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
>> >> > ******************************************
>> >> >
>> >>
>> >>
>> >
>>
>
>
> ------------------------------
>
> 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 29
> ******************************************
>
- Re: Help-bash Digest, Vol 113, Issue 29,
Budi <=