> -----Original Message---- > From: Robert Elz <k...@munnari.oz.au> > Sent: Tuesday, January 15, 2019 1:56 AM > To: Martijn Dekker <mart...@inlv.org> > Cc: austin-group-l@opengroup.org > Subject: Re: In defence of compound aliases > > Date: Mon, 14 Jan 2019 16:24:24 +0100 > From: Martijn Dekker <mart...@inlv.org> > Message-ID: <8e92dc0f-1629-caa0-6ae0-064f78033...@inlv.org> > > | This "mangled syntax" qualification is gratuitous disapproval and > | nothing more. You have still not come up with any actual argument > | against it.
> I was referring to the particular syntax, not the idea - the idea has > existed, and been used, for many decades - Korn didn't invent it either - > think back to RATFOR (wich was a preprocessor, rather than langage macros, > but to a similar effrect, and is one of cases with less > issues, as it was better specified, but still has all the problems caused > because what gets executed, and from which any coding bugs > need to be debugged, is still FORTRAN) , and then the initial C++; and has > almost invariably turned out in hindsight to have been the > wrong thing to do (the wrong way to accomplish the goal, though at the time > it might have seemed to be the only practical solution.) Although I understand Robert Elz's reservations with respect to macro expansion, it remains a technique with a lot of bang for the buck -- witness, besides the examples listed above, m4, macro assembler (not found in traditional Unixs), and, last but not least, the shell itself -- the $VAR construct substituting the contents of VAR into the command line, and according to https://multicians.org/shell.html, with Strachey's General Purpose Macrogenerator GPM as the inspiration for the design of shells in general. The principle of not giving oneself enough rope to hang oneself is clearly not the Unix philosophy. > > | Yes, there are implementation differences. Many other shell > | functionality has implementation differences as well. > > Yes, they do, which is why (unfortunately) the standard has so much > listed as unspecified. It would be good if shell authors could agree on > what should be done in some of these cases, so there are less differences and > less that needs to be unspecified - at least when the > relevant shells' > posix environment is enabled, when there is one. However, no-one wants > to risk breaking their users' scripts, so it is difficult to get changes made. > Even something so useful as "local" cannot be specified, because of the > variations in how it works (and the underlying model of what the > namespace for variables looks like). > 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? > | -- the problem appeared when my new loop construct started using > | FIFOs intensively; I was making use of aliases long before that.) > > I doubt that fifo's have anything to do with it, I suspect (and this is just > a guess for now) that the issue relates to the agressive use of > pushing and popping file descriptors (n>&m on compound statements) which > increased a lot with the use of fifos. > > While aliases are very unlikely to be directly influencing anything, and that > the same bug would exist if the code were simply written out > longhand (with the aliases all expanded) here, the problem is that all of > that file descriptor manipulation is buried in multiple layers of > aliases, which do more than just manipulate file descriptors, and unravelling > all of that to work out what is going on is exceedingly > difficult and tedious, as while I suspect I know the area in which the bug > exists, that's currently little more than intuition - and it certainly > takes something quite complex to trigger it, so working out what is going on > is exceedingly difficult. > > That's what I was referring to in an earlier message, and the "any actual > argument against it" from the beginning of this message. Everything is > so convoluted, and so intertwined, that determining what is really happening > in terms of the underlying shell constructs is not at all easy. If there had > been no aliases, and the same code was just written, then the particular > failing construct would be much easier to spot, and then to work > out what had actually led to the situation where the bug exists. Why not use set -x?
