Austin Group Bug Tracker via austin-group-l at The Open Group wrote in <bb3868e91f686e62a2ddcb2a5f1b1...@austingroupbugs.net>: .. |https://austingroupbugs.net/view.php?id=1852 .. |Summary: Clarify "$@[:$@:]" (with $# -eq 0) ... | (0006871) McDutchie (reporter) - 2024-09-02 19:35 | https://austingroupbugs.net/view.php?id=1852#c6871 ... |Here is a more comprehensive regression test I wrote. Expected output: |none. Feel free to use any or all of it. I hereby dedicate it to the public |domain as per Creative Commons CC-0: |https://creativecommons.org/publicdomain/zero/1.0/
|for e in 3 '"$@"' \ | 5 '"$@$@"' \ | 7 '"$@$@$@"' \ | 9 '"$@$@$@$@"' \ | 11 '"$@$@$@$@$@"' \ | 13 '"$@$@$@$@$@$@"' \ This is no joke actually, i find it amazing *how* often software fails on "deeper recursion" of a thing. For example the busybox shell fails terribly as soon as ?: constructs get deeper, aka intermangled, even though lots of people tried fixing over two decades, they spent real time. (The real fix is not included because it increases the code by ~2000 bytes, but that aside.) At times you even get answers like "we already do more than required", but noone understands why "+10++11" is a correctly handled case, whereas "+10++VAR" is not, and if you generate things automatically and individual tokens expand like so for whatever reason, the one thing fails and the other not. These are just shell examples i have at hand. (And in hindsight to the software programmer "scene" in its current state i am thinking that rewriting in Rust will solve the issues ...) ... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
