Re: bug: can't break/continue from within eval
Martijn Dekker dixit: >Agreed; there is nothing to suggest otherwise. 'eval' executes its >arguments in the current shell environment in place of itself. So after >parsing those arguments, executing them should be equivalent to 'eval' >not being there at all. And it got implemented thus. Testing, of course, welcome ☺ There’s now also isglobal(), do you wish to have another shot at [[ -v varname ]], possibly including manpage and testsuite patch, or should I put it on my own TODO? bye, //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block.
Re: bug: can't break/continue from within eval
Op 08-04-17 om 02:08 schreef Chet Ramey: > On 4/7/17 7:46 PM, Thorsten Glaser wrote: >> Chet Ramey dixit: >> 'break' and 'continue' are POSIX "special builtins", meaning if they fail they should cause the shell to exit, at least in POSIX mode. >>> >>> Posix explicitly makes this case unspecified. >> >> Indeed, I just found this out as well, thanks. >> >> Ib m curiousb & is the 'break' in 'eval break' contained within the >> compound-list of the do loop? (Ib ll probably make this work as >> requested nevertheless as I consider it correct, butb & meh, those >> standardsb &) > > Yeah, I think it is. Agreed; there is nothing to suggest otherwise. 'eval' executes its arguments in the current shell environment in place of itself. So after parsing those arguments, executing them should be equivalent to 'eval' not being there at all. - M.
Re: bug: can't break/continue from within eval
On 4/7/17 7:46 PM, Thorsten Glaser wrote: > Chet Ramey dixit: > >>> 'break' and 'continue' are POSIX "special builtins", meaning if they >>> fail they should cause the shell to exit, at least in POSIX mode. >> >> Posix explicitly makes this case unspecified. > > Indeed, I just found this out as well, thanks. > > Ib m curiousb & is the 'break' in 'eval break' contained within the > compound-list of the do loop? (Ib ll probably make this work as > requested nevertheless as I consider it correct, butb & meh, those > standardsb &) Yeah, I think it is. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: can't break/continue from within eval
Chet Ramey dixit: >> 'break' and 'continue' are POSIX "special builtins", meaning if they >> fail they should cause the shell to exit, at least in POSIX mode. > >Posix explicitly makes this case unspecified. Indeed, I just found this out as well, thanks. I’m curious… is the 'break' in 'eval break' contained within the compound-list of the do loop? (I’ll probably make this work as requested nevertheless as I consider it correct, but… meh, those standards…) bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Re: bug: can't break/continue from within eval (plus, status 0 on error)
Op 08-04-17 om 00:36 schreef Chet Ramey: > On 4/7/17 6:56 PM, Martijn Dekker wrote: > >> A second thing: >> >> $ mksh -o posix -c 'break; echo $?' >> mksh: break: can't break >> 0 >> $ mksh -o posix -c 'continue; echo $?' >> mksh: continue: can't continue >> 0 >> >> 'break' and 'continue' are POSIX "special builtins", meaning if they >> fail they should cause the shell to exit, at least in POSIX mode. > > Posix explicitly makes this case unspecified. So it does. My bad. Remains the question whether the current behaviour is actually sensible. - M.
Re: bug: can't break/continue from within eval (plus, status 0 on error)
On 4/7/17 6:56 PM, Martijn Dekker wrote: > A second thing: > > $ mksh -o posix -c 'break; echo $?' > mksh: break: can't break > 0 > $ mksh -o posix -c 'continue; echo $?' > mksh: continue: can't continue > 0 > > 'break' and 'continue' are POSIX "special builtins", meaning if they > fail they should cause the shell to exit, at least in POSIX mode. Posix explicitly makes this case unspecified. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
bug: can't break/continue from within eval (plus, status 0 on error)
$ mksh -o posix -c 'for x in 1 2 3; do eval "break"; done' mksh: break: can't break mksh: break: can't break mksh: break: can't break $ mksh -o posix -c 'for x in 1 2 3; do eval "continue"; done' mksh: continue: can't continue mksh: continue: can't continue mksh: continue: can't continue The "break"/"continue" executed within the loop, so this should work (as it does on every other shell except pdksh). Actual use case, as requested: one of my shell functions contains a loop, within which there is a 'case' construct wrapped in 'eval' so it can use a variable referenced by another variable, and it needs to be able to conditionally break out of the loop based on its value. Since mksh won't tolerate the 'break' within the 'eval', I need to make the code more awkward by moving the 'break' outside of the 'case' within the 'eval' while still keeping it conditional. A second thing: $ mksh -o posix -c 'break; echo $?' mksh: break: can't break 0 $ mksh -o posix -c 'continue; echo $?' mksh: continue: can't continue 0 'break' and 'continue' are POSIX "special builtins", meaning if they fail they should cause the shell to exit, at least in POSIX mode. And in this case I can see good reasons for that. A failing 'break'/'continue' is a strong indicator that the program is in an inconsistent state where continuing would make no sense and may very well be harmful. In non-POSIX mode, it's your decision whether they should exit or not, but they should at the very least return a nonzero exit status on error. Thanks, - M.