Op 14-01-19 om 11:59 schreef Robert Elz:
> 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.
This "mangled syntax" qualification is gratuitous disapproval and
nothing more. You have still not come up with any actual argument
against it.
And, I repeat, it didn't require any "inventing". As I just showed, it's
David Korn himself who came up with the basic idea sometime in 1987 or
before.
It is also trivial. It's just a pair of shorthand macros for a simple
shell block with a function definition and a function call in it.
Nothing is being "mangled" whatsoever.
And it is useful and productive. It was an easy, straightforward,
functional and efficient way of solving an actual problem.
Where did I claim it's the *only* way? Of course it isn't. But that
doesn't make it bad.
I am willing to bet, though, that using that little pair of aliases is
the most efficient way, both in terms of maintenance and in terms of
execution. In fact it executes the tests even more efficiently than the
old alias-less way, because it eliminates the need for a loop that
checks if each function exists. And converting the regression tests to
this new method was about five minutes of work.
> | 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.
Yes, there are implementation differences. Many other shell
functionality has implementation differences as well.
But defining a shell block using two aliases, e.g. one starting with a
'{' and the other ending with a '}', is very straightforward, and works
consistently on *all* the current shells that support aliases. Fact.
By now, you know better than many that my library regression tests tend
to test the shell (as well as the library) to its limits. So I think I
have a fairly solid basis for claiming this.
(I'm sure you'll agree that triggering segfaults in your NetBSD sh
development version doesn't count as my method not working, and I
suspect aliases have nothing to do with that anyway -- the problem
appeared when my new loop construct started using FIFOs intensively; I
was making use of aliases long before that.)
So, any outright claim that the new draft text "documents what actually
works in the wild" would be false. I think you know this, hence your
added qualifier, "(and is reasonable to specify)".
Somehow I get the feeling you're not going to consider anything that
sanctions an alias usage you disapprove of "reasonable".
The historical practice with defining shell blocks using aliases is
clearly useful, clearly portable, and would be perfectly reasonable to
specify. The standard developers just need to find the accurate wording
for it.
If it is not the scope of the POSIX standard to deprecate a historically
established usage that works consistently on all shells in the wild,
then please don't.
> | 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
[...]
This is literally just another way of saying that your objections are of
a dogmatic nature.
> 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.
Then, please, show me the problems.
Particularly the real, concrete, practical problems with this:
alias TEST='{ testFn() {'
alias ENDT='}; doTest; }'
doTest() {
function calling testFn and handling result goes here
}
TEST
test code goes here
ENDT # and many more of these
What problems does this cause for the regression test scripts?
How does this not work well, on any POSIXy shell in the wild that
supports aliases? Can you break this on even one shell?
How is this in any way convoluted or difficult to understand?
Show me.
> | 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.
It is not the job of the POSIX standard to stop users from shooting
themselves in the foot.
That is a job I intend to take on with the modernish library, with the
safe mode, pervasive command hardening, etc.
> 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).
...yet, as far as you know.
Modernish consistently triggers segfaults. Anything could trigger those
intermittently, without you necessarily hearing about it. Users restart
the computer, find it works the second time around, shrug, and move on.
> 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,
This is because you're running the regression test suite, which is
designed to do exactly that -- it loads everything, uses everything, and
tries hard to make modernish fail, and in the process it inevitably also
tries hard to make the shell fail.
In the end, that has been for the benefit of both modernish and many
shells, as while fixing modernish bugs I also report all the shell bugs
I find.
Individual functionality on my current code (which has been developed
and refactored quite a lot since last time I sent you a tarball) seems
to be working fine, on the latest NetBSD 8.0 sh binary you sent me:
# /root/SH-2018-11-30 bin/modernish -c 'echo init ok'
init ok
# /root/SH-2018-11-30 bin/modernish --use=safe --use=var/loop \
-c 'LOOP find textfile in /usr -type f -name *.txt; DO
shellquote -f textfile;
putln "found text file $textfile";
DONE'
found text file "/usr/share/doc/papers/mckusick84-ffs/mckusick84-ffs.txt"
found text file "/usr/share/doc/papers/mckusick85-fsck/mckusick85-fsck.txt"
found text file
"/usr/share/doc/papers/morris78-password/morris78-password.txt"
(etc... many more)
(Try that again while exporting _loop_DEBUG=y to see the actual 'find'
utility command it uses -- also try it on directories containing file
names with newlines and other nonsense; everything "just works".)
So it looks like the basics definitely work. In the next few days, I'll
try to test all the module functionality individually, let you know if
anything breaks, and send you reports of any shell bugs I find. If
anything changed since 2018-11-30, please send me your latest sh binary
compiled for NetBSD 8.0.
Thanks,
- M.
