Re: alias expansion bug with matching { ... }

[Thorsten Glaser]

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 { ... }

[Steffen Nurpmeso]

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 { ... }

[Thorsten Glaser]

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 { ... }

[Martijn Dekker]

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 { ... }

[Thorsten Glaser]

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