Re: alias expansion bug with matching { ... }
Thorsten Glaser wrote: |Steffen Nurpmeso dixit: |>Would you mind re-allowing hyphen-minus again? That really has | |Sure, done. Although I kinda follow the idea of not letting them |start with a hyphen-minus and have enacted that as well. I blindly say that is cl. Thank you! --steffen
Re: alias expansion bug with matching { ... }
Steffen Nurpmeso dixit: >Would you mind re-allowing hyphen-minus again? That really has Sure, done. Although I kinda follow the idea of not letting them start with a hyphen-minus and have enacted that as well. bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D
Re: alias expansion bug with matching { ... }
Hallo! Thorsten Glaser wrote: |Dixi quod… |>Commit ID: 10058E5A1067AFA1BBA ... |Oh well. For the sake of consistency. But fixing this DID uncover |a re-entrancy bug in 'typeset -f' ouput (which IS also used in some |other places internally): ... |When deferring alias interpretation until the end, we do get: ... |This is problematic (in the first two) and inconsistent (in the last) case. ... |To make this work but not get “\./pfn” stupidly, I had to limit the |allowed characters in “alias”, but ksh93 does so too, as does POSIX. Would you mind re-allowing hyphen-minus again? That really has become very common in $PATH, and the new ksh_isalias() seems to omit it. For example, ?0[steffen@wales]$ alias|wc -l 86 ?0[steffen@wales]$ alias|grep -F -- -|wc -l 78 ?0[steffen@wales]$ ls /usr/bin|wc -l 1565 ?0[steffen@wales]$ ls /usr/bin|grep -F -- -|wc -l 372 I seem to remember that i have opened an Austin Group issue to include hyphen-minus in the set of allowed characters, that is [1], … i seem to be too lazy to look into the standard to resolve the aberrations on notational aspects of the desired change that have evolved on the tracker, though. Still, bash etc. support it. In the other window i updated the desired action. [1] http://austingroupbugs.net/view.php?id=1050 Ciao! --steffen
Re: alias expansion bug with matching { ... }
Dixi quod… >Commit ID: 10058E5A1067AFA1BBA >Log message: >fix reentrancy of 'typeset -f' output in the face of aliases; also, >move alias handling for COMSUBs and friends to parse time by request >of Martijn Dekker (and for consistency with function definitions) Oh well. For the sake of consistency. But fixing this DID uncover a re-entrancy bug in 'typeset -f' ouput (which IS also used in some other places internally): The old comsub-5 tested this: print '#!/bin/mksh\nfor x in "$@"; do print -r -- "$x"; done' >pfn chmod +x pfn alias echo='echo a' foo() { ./pfn "$(echo foo)" } typeset -f foo expected-stdout: foo() { ./pfn "$(echo foo )" } But what if we try to re-enter it? print '#!/bin/mksh\nfor x in "$@"; do print -r -- "$x"; done' >pfn chmod +x pfn alias echo='echo a' foo() { echo moo ./pfn "$(echo foo)" } typeset -f foo >x cat x foo . ./x typeset -f foo foo When deferring alias interpretation until the end, we do get: foo() { echo a moo ./pfn "$(echo foo )" } a moo a foo foo() { echo a a moo ./pfn "$(echo foo )" } a a moo a foo With this, we also get: alias echo=print x() { echo a; (echo b); x=$(echo c); } typeset -f x ⇒ x() { print a ( print b ) x=$(echo c ) } This is problematic (in the first two) and inconsistent (in the last) case. With the code I committed, we get: foo() { \echo a moo ./pfn "$(\echo a foo )" } a moo a foo foo() { \echo a moo ./pfn "$(\echo a foo )" } a moo a foo To make this work but not get “\./pfn” stupidly, I had to limit the allowed characters in “alias”, but ksh93 does so too, as does POSIX. So, in the end… yes, thank you. Welterusten, //mirabilos (who doesn’t get enough Cider for this) PS: sleepless unite! ☺ -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: alias expansion bug with matching { ... }
Martijn Dekker dixit: >Define "legit" and "weird" (and explain how they're mutually exclusive). ;-) ;-) >What I'm doing is this: >https://github.com/modernish/modernish#use-varsetlocal #user-content-use-varsetlocal by the way. I see. I can also see the benefit of expanding the aliases at the time of the _first_ parse (especially later on…). Ordinarily, TPAREN parsing ought to do the trick… hmm… tg@blau:~ $ alias echo=print tg@blau:~ $ x() { echo a; (echo b); x=$(echo c); } tg@blau:~ $ typeset -f x x() { print a ( print b ) x=$(echo c ) } (Defining a function then dumping it is a popular way in mksh to figure out how things are parsed.) This is likely due to the… sALIAS = 0; in front of that in yyrecursive() in syn.c; we could certainly try to do with it enabled. BUT! static int sALIAS = ALIAS; /* 0 in yyrecursive */ This was introduced at the time yyrecursive() was. There likely has been some kind of reason… ah! comsub-5. Aliases were expanded twice otherwise. So… well, it’s still more useful at parse time than at runtime. >So no, this does not really need to be supported in command >substitutions or any other subshells. But I do report every little >oddity I find, sometimes they're indicative of bugs. Indeed, and for that I’m thankful… please just indicate whether this is something like that or if you have an actual use case for it the next time you have something weird like this ;) bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: alias expansion bug with matching { ... }
Op 04-04-17 om 02:26 schreef Thorsten Glaser: > That’s no excuse… pdksh does simple search for a matching ) > in command substitutions, failing $(case x in y) ;; esac ). Yeah, I've run into that. It even parses quote marks in comments within command substitutions, requiring them to be balanced (so an "it's" in a comment would cause a syntax error pinpointed twelve zillion lines further on). bash 2 did the same thing. So did ksh88, I'm pretty sure... > I think “we” agreed somewhere (maybe here, maybe in IRC, maybe > on the Austin ML) that doing weird things to the shell syntax > with aliases need not really be supported. So, please, do tell > me whether you *really* have a *legit* use case for… that. Define "legit" and "weird" (and explain how they're mutually exclusive). ;-) What I'm doing is this: https://github.com/modernish/modernish#use-varsetlocal So no, this does not really need to be supported in command substitutions or any other subshells. But I do report every little oddity I find, sometimes they're indicative of bugs. - M.
Re: alias expansion bug with matching { ... }
Martijn Dekker dixit: >It works on every other shell, even pdksh. That’s no excuse… pdksh does simple search for a matching ) in command substitutions, failing $(case x in y) ;; esac ). >But this does not: > >$ var=$({ OPEN echo hi; CLOSE }) && echo "$var" >mksh: syntax error: ')' unexpected I see. Apparently, aliases are not parsed during recursing into the parser (the exact feature fixing the aforementioned pdksh bug). This is likely because it only needs to figure out the syntax. And… indeed: tg@blau:~ $ x() { > var=$({ OPEN echo hi; CLOSE; }) && echo "$var" > } tg@blau:~ $ typeset -f x x() { var=$({ OPEN echo hi ; CLOSE ; } ) && echo "$var" } tg@blau:~ $ x /bin/mksh: syntax error: ';' unexpected Just what I expected if my speculation was true. But: WHAT THE HEY ARE YOU DOING?! Implementing ALGOL in shell? I think “we” agreed somewhere (maybe here, maybe in IRC, maybe on the Austin ML) that doing weird things to the shell syntax with aliases need not really be supported. So, please, do tell me whether you *really* have a *legit* use case for… that. Thanks, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec