Re: In defence of compound aliases

Robert Elz wrote in <27918.1547593...@jinx.noi.kre.to>: ... |I fail to see why any real importance is given to shell speed. | |On my system, where I use bash as my interactive shell, in more |than 56000 invocations (almost 57000), bash has yet to accumulate |1 cpu second, and bash does not

Re: In defence of compound aliases

Robert Elz wrote: > I fail to see why any real importance is given to shell speed. The shell speed has a major influence on the execution time for the "configure" scripts. The ksh93 variant that is part of OpenSolaris is e.g. nearly twice as fast (in terms of wall clock time) than bash.

Re: In defence of compound aliases

Robert Elz wrote: > Date:Tue, 15 Jan 2019 09:46:20 -0500 > From:Chet Ramey > Message-ID: > > | Which shells don't rescan the alias value in the lexer? AFAICT, that's one > | of the things everyone does the same way. > > And the proposed resolution says they

Re: In defence of compound aliases

Harald van Dijk wrote: > On 15/01/2019 15:13, Joerg Schilling wrote: > > BTW: Given that the multi byte support requires sevral conversions between > > multi byte chars and wide chars and that these conversions take approx. 30% > > of > > the typical time used by the shell, adding multi byte

Re: In defence of compound aliases

Harald van Dijk wrote: > > posh does not work because it sets "optind" to 0 even though POSIX requires > > it > > to be initialized with 1. > > Implementations are allowed to accept this as an extension, and if they > do, they are allowed to make use of that extension in their utilities.

Re: In defence of compound aliases

Date:Wed, 16 Jan 2019 05:20:12 +0700 From:Robert Elz Message-ID: <27785.1547590...@jinx.noi.kre.to> | magnolia$ echo $BASH_VERSION | 4.4.12(1)-release Just realised I was using a system with an older bash than I do have available here for that test, on a newer

Re: In defence of compound aliases

On 15/01/2019 23:04, Robert Elz wrote: Date:Tue, 15 Jan 2019 20:38:15 + From:Harald van Dijk Message-ID: | On 15/01/2019 15:13, Joerg Schilling wrote: | > would make it she slowest shell in the universe. | parser as well. Testing on its own

Re: In defence of compound aliases

On 1/15/19 5:20 PM, Robert Elz wrote: > As for which shells don't do it, or do it differently, .well, bash is one ... > > magnolia$ echo $BASH_VERSION > 4.4.12(1)-release > magnolia$ alias foo='echo "x' > magnolia$ foo bar" > x bar > magnolia$ > > Notice two spaces between the 'x' and 'bar'

Re: In defence of compound aliases

Date:Wed, 16 Jan 2019 05:20:12 +0700 From:Robert Elz Message-ID: <27785.1547590...@jinx.noi.kre.to> | ksh93, bosh, mksh, pdksh, all give the same results. And yash, forgot to test that one earlier. I also forgot zsh, but whatever it is doing (with --emulate sh or

Re: In defence of compound aliases

Date:Tue, 15 Jan 2019 20:38:15 + From:Harald van Dijk Message-ID: | On 15/01/2019 15:13, Joerg Schilling wrote: | > would make it she slowest shell in the universe. | parser as well. Testing on its own configure script, yes, there are | faster shells,

Re: In defence of compound aliases

On 15/01/2019 11:15, Joerg Schilling wrote: Harald van Dijk wrote: Can there be an alternative rewording that specifies the behaviour in even more cases, where the resulting text is still both correct and understandable, and the extra cases are verified to work the same way on all current

Re: In defence of compound aliases

On 15/01/2019 11:03, Joerg Schilling wrote: Harald van Dijk wrote: On 14/01/2019 13:32, Joerg Schilling wrote: posh does not work on platforms with a POSIX compliant getopt(), so there are other reasons not to take posh into account. This is misleading. There are platforms with a POSIX

Re: In defence of compound aliases

2019-01-15 17:19:24 +0100, Joerg Schilling: [...] > > Note that even UNIX (POSIX+XSI) certified systems are not > > compliant. For instance, macOS "/bin/echo" doesn't expand \n, > > \b... as POSIX+XSI requires. > > AFAIR, Apple did compile bash (like Sun did for Solaris) in a way that does > not

Re: In defence of compound aliases

2019-01-15 17:19:24 +0100, Joerg Schilling: [...] > > I don't think GNU/Debian systems care about XSI, or the UNIX > > trademark either. AFAICT, they concern themselves with the POSIX > > base, and pick XSI extensions when they are useful (and don't > > break their own backward compatibility). >

Re: In defence of compound aliases

Stephane CHAZELAS wrote: > > Note that XSI enhancements only may be omitted in case of a UNIX system for > > embedded use. So this is a similar problem as the missing multi byte > > support in > > "dash" that only would be permitted if dash was used on embedded systems > > only. > [...] > >

Re: In defence of compound aliases

Chet Ramey wrote: > > You seem to missunderstand me. > > Sure, OK. Frame it how you like. The question stands. If that is how > every existing alias implementation behaves, we should not argue about > adding that to the standard to tighten up the meaning of "the resulting > tokens shall replace

Re: In defence of compound aliases

2019-01-15 16:13:42 +0100, Joerg Schilling: > Stephane CHAZELAS wrote: > > > > posh is s non-POSIX that even normal tests return incorrect results > > > :-( > > > > "type" is not in the POSIX base (and as a result not in > > the Debian policy) > >

Re: In defence of compound aliases

On 1/15/19 10:14 AM, Joerg Schilling wrote: > Chet Ramey wrote: > >> Or are we hung up on the word "stack"? > > You seem to missunderstand me. Sure, OK. Frame it how you like. The question stands. If that is how every existing alias implementation behaves, we should not argue about adding that

Re: In defence of compound aliases

Chet Ramey wrote: > Or are we hung up on the word "stack"? You seem to missunderstand me. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL:

Re: In defence of compound aliases

Stephane CHAZELAS wrote: > > posh is s non-POSIX that even normal tests return incorrect results :-( > > "type" is not in the POSIX base (and as a result not in > the Debian policy) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html First added with issue 2, which seems to

Re: In defence of compound aliases

On 1/15/19 9:56 AM, Joerg Schilling wrote: > Chet Ramey wrote: > >> Which shells don't rescan the alias value in the lexer? AFAICT, that's one >> of the things everyone does the same way. > > A shell that did this would only be able to alias one word by one other word > and macros like > >

Re: In defence of compound aliases

Chet Ramey wrote: > Which shells don't rescan the alias value in the lexer? AFAICT, that's one > of the things everyone does the same way. A shell that did this would only be able to alias one word by one other word and macros like alias ll='ls -l' would not work. I am not aware of

Re: In defence of compound aliases

2019-01-15 11:56:20 +0100, Joerg Schilling: [...] > OK: > > PATH=/ /opt/schily/bin/posh -c 'type' > /opt/schily/bin/posh: type: not found > > posh is s non-POSIX that even normal tests return incorrect results :-( "type" is not in the POSIX base (and as a result not in the Debian policy)

Re: In defence of compound aliases

On 1/15/19 9:05 AM, Robert Elz wrote: > | Again, why can't you agree on having the alias expansion work strictly at > the > | lexical level, prepending the expanded string to the input and rescanning > from > | the beginning? > > If the role here was to define how things should work,

Re: In defence of compound aliases

Date:Tue, 15 Jan 2019 11:55:52 + From:"Schwarz, Konrad" Message-ID: | Although I understand Robert Elz's reservations with respect to macro expansion, | it remains a technique with a lot of bang for the buck I hope no-one (perhaps except you) read my

Re: In defence of compound aliases

Harald van Dijk wrote: > Can there be an alternative rewording that specifies the behaviour in > even more cases, where the resulting text is still both correct and > understandable, and the extra cases are verified to work the same way on > all current shells? If there is, I suspect that

Re: In defence of compound aliases

Harald van Dijk wrote: > On 14/01/2019 13:32, Joerg Schilling wrote: > > posh does not work on platforms with a POSIX compliant getopt(), so there > > are > > other reasons not to take posh into account. > > This is misleading. There are platforms with a POSIX compliant getopt() > on which it

Re: In defence of compound aliases

Martijn Dekker wrote: > > posh > > $ type alias > > alias is a shell builtin > > Yes: > > $ ./posh -c 'alias' > posh: alias: not found > $ ./posh -c 'type alias' > ./posh: type: not found > > You're on Solaris, right? posh doesn't have 'type' either so you must be > running your

Re: In defence of compound aliases

On 14/01/2019 05:59, Martijn Dekker wrote: I'm frankly astonished that there seems to be a growing consensus to de-specify this long-standing type of alias usage. Please, reconsider. The interpretation given in , as I understand it, is that aliases

Re: In defence of compound aliases

On 14/01/2019 13:32, Joerg Schilling wrote: posh does not work on platforms with a POSIX compliant getopt(), so there are other reasons not to take posh into account. This is misleading. There are platforms with a POSIX compliant getopt() on which it does not work, but there are also

Re: In defence of compound aliases

Stephane Chazelas wrote: > The "alias" and "unalias" builtins were already removed in the > very first version of posh (0.01 in 2002), I don't know why. > Maybe the Debian policy at the time was forbidding the use of > aliases. Shure? posh $ type alias alias is a shell builtin Jörg --

Re: In defence of compound aliases

Op 14-01-19 om 11:59 schreef Robert Elz: > Date:Mon, 14 Jan 2019 06:59:14 +0100 > From:Martijn Dekker > Message-ID: <90a5f4e6-64ae-6d08-fd20-9b9addd6d...@inlv.org> > > | Let me start with a simple real-life example. > > I have a similar issue in tests I have

Re: In defence of compound aliases

Martijn Dekker wrote: > Op 14-01-19 om 12:20 schreef Joerg Schilling: > > Martijn Dekker wrote: > [...] > >> alias TEST='{ testFn() {' > >> alias ENDT='}; doTest; }' > >> > >> Now, each regression test function is delimited by TEST ... ENDT instead > >> of the normal function definition. The

Re: In defence of compound aliases

Robert Elz wrote: > > alias doit='my_command arg1 arg2;' > > with the ';' included to make sure the command ends there. > > Then some script used it like > > doit; something-else > > and it fails - on some shells - not all perhaps, because those two ';'s > have turned into the ';;'

Re: In defence of compound aliases

Op 14-01-19 om 12:20 schreef Joerg Schilling: > Martijn Dekker wrote: [...] >> alias TEST='{ testFn() {' >> alias ENDT='}; doTest; }' >> >> Now, each regression test function is delimited by TEST ... ENDT instead >> of the normal function definition. The ENDT alias calls a handler >> function

Re: In defence of compound aliases

Date:Mon, 14 Jan 2019 12:20:40 +0100 From:Joerg Schilling Message-ID: <5c3c7088./lfHrx74ZNre/ed5%joerg.schill...@fokus.fraunhofer.de> | I am not willing to make those things inspecified as long as there is an | example of an otherwise POSIX compliant shell that

Re: In defence of compound aliases

Martijn Dekker wrote: > I wish I had had the time to respond to the alias comment thread > earlier. Now, I'd like to make my point more coherently by starting anew > instead. > > Let me start with a simple real-life example. In the regression test > suite of my shell library under development,

Re: In defence of compound aliases

Date:Mon, 14 Jan 2019 06:59:14 +0100 From:Martijn Dekker Message-ID: <90a5f4e6-64ae-6d08-fd20-9b9addd6d...@inlv.org> | Let me start with a simple real-life example. I have a similar issue in tests I have written, and deal with it in an automated way without a

Re: In defence of compound aliases

Op 14-01-19 om 09:02 schreef Ingo Schwarze: > Hi Martijn, > > Martijn Dekker wrote on Mon, Jan 14, 2019 at 06:59:14AM +0100: > >> Indeed, it's not as if aliases are some sort of strange anomaly in the >> programming world. In other languages, similar features are usually >> called 'macros'. C

Re: In defence of compound aliases

Hi Martijn, Martijn Dekker wrote on Mon, Jan 14, 2019 at 06:59:14AM +0100: > Indeed, it's not as if aliases are some sort of strange anomaly in the > programming world. In other languages, similar features are usually > called 'macros'. C library sources are loaded with them. It depends. Some