Date: Tue, 15 Jan 2019 11:55:52 +0000
From: "Schwarz, Konrad" <[email protected]>
Message-ID:
<a45b1767f1002449a37508c2cc6003d704b84...@defthw99ej1msx.ww902.siemens.net>
| 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 message as in any way being
opposed to macro processing - as used in things like m4, and some assemblers,
and other places it is a very nice facility.
I would also note that a macro that cannot have parameters is at at a decided
disadvantage to ones that can, in the usefulness stakes, and macros that cannot
recurse are not nearly as useful as ones that can.
| and, last but not least, the shell itself -- the $VAR construct
substituting the contents
| of VAR into the command line,
That kind of thing is fine, $VAR cannot alter the syntax of the language, it is
simply a variable expansion (it can turn one word into many, or none, but not
until the structure of the command has first been discovered.)
| The principle of not giving oneself enough rope to hang oneself is clearly
| not the Unix philosophy.
I understand, and even generally like that ability, which it is why it
is possible to use #define to make what looks to be syntax (there is some
of it in NetBSD, though personally I do not much like it) and for aliases
to define new syntax (our shell allows that). But I see no reason that
we ought to make any of that something that users are told that they
can safely rely upon in general.
| 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, that would be
a reasonable thing to attempt. But it is not, this is not a legislature
(no standards body should be, regardless of how some of them act.)
The task here is to document what does work, not what we think should.
If you're asking why some shells do not implement aliases exactly like
that, then I cannot answer - but obviously some do not, as there are
different outcomes from some shells than others, which must indicate
different underlying implementation methods.
If you're asking why shells that don't do it this way don't change, then
I can't really answer that either, but I can guess ... if an implementation
has been around, and is working as designed (ie: we're not talking
about something which is clearly just a bug) then the implementors are
going to be reluctant to possibly break their users' scripts (or just usage
habits on the command line) - and especially not when the reason is
only so that it becomes possible to have enough rope to hang yourself.
[On my debugging problems...]
| Why not use set -x?
That, itself, would be barely useful, Martijn's scripts have so much
I/O redirection, where stderr is either sent to /dev/null or elsewhere
that a good fraction of the output would be lost.
The NetBSD shell has -X though (in addition) which is just like -x,
except all the output goes to what is stderr when the option is
enabled (so "set -X 2>/tmp/trace-output" works) which avoids that
particular issue.
I have used that, but the output is not really adequate for what you're
suggesting I think (for unravelling the source) - as it gives both the
function calls, and the code executed inside, and some constructs
never get adequately represented at all (redirects on structures that
are never actually executed as commands tend not to appear, for
example, and there are lots of those in the script .. and redirect
processing, or some particular artifact of it, as it works (apparently)
everywhere else, is what I currently believe is the bug to be fixed.
kre
