Date: Mon, 14 Jan 2019 06:59:14 +0100
From: Martijn Dekker <mart...@inlv.org>
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 single alias in sight. That you have
chosen to invent mangled syntax to deal with this doesn't mean
by any means that it is the only way, or even a good one.
| I'm frankly astonished that there seems to be a growing consensus to
| de-specify this long-standing type of alias usage. Please, reconsider.
Ths issue is that the standard documents what actually works in the
wild - as much of aliases as seems to work everywhere (and is reasonable
to specify) is being retained. That is not much - if you have time to read
everything (going back years to when this was first discussed - before my
time here) you'll see examples of different implementation choices in all
kinds of areas.
If you're particularly careful in exactly what you do you can probably
avoid many of the pitfalls, but the standard cannot specify everything
that would be required to make that work - the best we can do is tell
users that they can use the part that we expect works everywhere.
| The only objections I can see are of a dogmatic nature.
Then you haven't really looked - there are some of us (perhaps
just me) who believe that aliases are a terrible idea for everything
(with perhaps the sole exception that, with an expanded definition of
what can be in an alias-name, it allows a command named / which is
one thing that cannot be done any other way) and should simply be
removed. That isn't going to happen (or not anytime soon anyway)
and even if it did, it is very unlikely that any shells (even the one I
am currently maintaining) would delete the support they currently have.
The actual objections that have caused changes (such as it is, the
definition in the current published standand is gibberish), or perhaps
that have limited what is proposed to be specified, are all based upon
real practical problems.
| As Korn wrote there: "The combination of aliases and functions can be
| used to do things that canât be done with either of these separately."
I expect that it does, the question is whether that is really a good idea.
Modern practice is to tighten up on the rules for programmimg everywhere,
because it results in better outcomes (less bugs). More flexibility tends
to just mean more ways that you can shoot yourself in the foot.
| 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'.
They're not really, aliases are much weirder than that, because of
the way they're implemented and defined (macros apply everywhere
the macro occurs, they are at least consistent, aliases get expanded,
sometimes, depending on ...)
| Nobody calls that a bad idea,
Do you recall the original Bourne shell - that is the one Steve Bourne
actually wrote - which he wrote it using that technique, to make the sources
look like it was written in a kind of Algol68 syntax. Ever wonder why
there are no descendants, or clones, of that shell that still exhibit
even the tiniest bit of that mistake?
| Please, let's not throw out the baby with the bathwater. Fix the spec if
| necessary, but keep aliases working as they are.
If the point of the spec was to define what is supposed to work, that
might be possible, but it isn't. It is to define what does work (ignoring
admitted bugs). The differences in the way aliases work are implementation
choices in general, not bugs (though I'm sure there are also bugs.)
One more data point, I am sure you're aware that I am trying to find
a bug in the NetBSD sh that your scripts trigger (but apparently has
never been seen elsewhere). And that this one is taking longer
(much longer) than any of the others that you've directed my way
(for which you have my gratitude.) The reason is that because of the
way your scripts are written, all kinds of new stuff intertwined,
making it impossible to extract whatever it is that is causing the problem,
and without being able to work out just what is happening when it
is breaking (I have an idea, or perhaps just a guess, what kind of
problem it might be, but I cannot make any test cases that are simple
enough to actually use for debugging). I have nobbled as much as
I seem able to (replaced lots of stuff with do nothing dummies, etc)
and there's still more and more of it. Attempting to debug it the way
it is written is astonishing difficult. It is not just that it is big, I have
debugged issues with even bigger scripts before - but in a "normal"
shell script it is possible to work backwards from where the fault
actually happens to discover what caused it. That doesn't seem
realistic with your script, as going back one (apparent) line can
mean thousands of lines of execution.
kre
