Re: Feature request
9 Kasım 2020 Pazartesi tarihinde Dale R. Worley yazdı: > writes: > >> On Nov 8, 2020, at 6:49 PM, Budi wrote: > >> > >> Need feature on while's readily flag > >> > >> $ i=;while ((i<5)) ;do let i++ ;echo $i ;done ;echo $? > >> 1 > >> 2 > >> 3 > >> 4 > >> 5 > >> 0 > >> > >> $ i=7;while ((i<5)) ;do let i++ ;echo $i ;done ;echo $? > >> 0 > >> > >> we need feature on while's ability to supply flag when it's up to the > >> end of loop block > > > > It's not clear what you're asking for. Do you want while to exit > > nonzero when it doesn't perform any loops? > > I suspect what Budi wants is more explicit control of the exit value of > the while block. Of course, as long as the block is executed at least > once, it is straightforward to control the exit value. Compare these > two examples: > > $ i=0;while ((i<5)) ;do let i++ ;echo $i; true ;done ;echo $? > > $ i=0;while ((i<5)) ;do let i++ ;echo $i; false ;done ;echo $? > > What cannot be controlled is the exit value if the block is not executed > i.e. if the initial evaluation of the condition is false. In that case, > the exit value is always zero. > > You're not saying this warrants a change to the while loop's behavior though, right? There is nothing wrong with using an extra variable to determine whether the loop body was ever reached. i=7 j=0 while ((i<5)); do let i++ echo $i j=1 done echo $j > Dale > > -- Oğuz
Re: Feature request
Date:Sun, 08 Nov 2020 20:37:24 -0500 From:wor...@alum.mit.edu (Dale R. Worley) Message-ID: <87ft5j2tuz@hobgoblin.ariadne.com> | What cannot be controlled is the exit value if the block is not executed | i.e. if the initial evaluation of the condition is false. In that case, | the exit value is always zero. That's what the standard says it has to be. But since "if the initial evaluation of the condition is false" can be tested before getting to the while test, it is trivial to deal with this, and usually, deal with it more elegantly than having some magic exit value from a while where the body is never executed. But like Lawrence, I'm not at all sure that is what Budi actually wants. kre
Re: Feature request
On Mon, Nov 09, 2020 at 05:27:38PM +0700, Robert Elz wrote: > | What cannot be controlled is the exit value if the block is not executed > | i.e. if the initial evaluation of the condition is false. In that case, > | the exit value is always zero. > > That's what the standard says it has to be. But since "if the initial > evaluation of the condition is false" can be tested before getting to the > while test, it is trivial to deal with this, [...] Not in the general case, "while somecommand". Running "somecommand" may have nontrivial costs and side effects that would prevent you from wanting to run it twice. But as Oğuz said, it's simple to control this with an additional variable.
Re: Add configure switch to define USE_XON_XOFF
On 11/6/20 1:25 PM, Ivan Kozlov wrote: > Readline tests that macro and suppresses software flow control. This is quite > handy: I want software flow control, just not *in bash*, where it is not > useful and I would like C-s to do incremental search instead. With > USE_XON_XOFF, it is inactive in bash and is restored before executing a > command alongside other termios settings. It is probably possible to hack > this with PROMPT_COMMAND/PS0, but clearly this is a much cleaner and readily > available option. The only thing lacking is a configure switch. > Thanks for the suggestion. I will look at this for a future bash version. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature request
Date:Mon, 9 Nov 2020 07:52:34 -0500 From:Greg Wooledge Message-ID: <20201109125234.gy...@eeg.ccf.org> | Not in the general case, "while somecommand". Running "somecommand" | may have nontrivial costs and side effects that would prevent you from | wanting to run it twice. It is the control command of a while loop. Running it twice (many times) is going to be the normal case. Often anyway. Certainly there is no one solution that will work for everyone, every time, if there was, someone would have written that program many years ago, and there would be nothing left to write. Different circumstances lead to different solutions. And we still don't know what the initial request was really for, or why. kre
Unexpected code injection with [[ -v ]]
bash version 5.0.3(1)-release, Debian package 5.0-4, amd64.
Prompted by a discussion with someone in IRC.
unicorn:~$ key='$(date >&2)'
unicorn:~$ declare -A aa
unicorn:~$ aa[$key]=foo
unicorn:~$ echo "${aa[$key]}"
foo
unicorn:~$ [[ -v aa[$key] ]]
Mon Nov 9 18:17:30 EST 2020
bash: aa: bad array subscript
unicorn:~$ [[ -v 'aa[$key]' ]]
unicorn:~$
It's well-known that handing an unsanitized index to an *indexed* array
causes code injection when the index is evaluated in a math context, but
the code injection from -v with an *associative* array is a new one to me.
It's especially confusing because it doesn't happen with assignments or
expansions -- just with -v.
It seems single-quoting the array name + square brackets + key "works" to
avoid the code injection, but it's not clear to me why that's needed.
