Date: Wed, 10 Jul 2019 19:46:58 -0700
From: L A Walsh <b...@tlinx.org>
Message-ID: <5d26a322....@tlinx.org>
| But it was what I was thinking when I said they were the same.
None of us are mind readers, we cannot know what you were thinking,
only what you said (typed). If you're unable to be clear when you
say (or type) something, best not to say/send it at all.
| Both are a simple substitution that bash gives the
| appearance of being the same mechanism.
Nonsense.
The hash table is an optimisation that speeds repetitive path lookups.
It ought to be implemented in a way that is 100% invisible to the
user/script - but because of the way it was initially done, it wasn't,
and so (very occasionally) it is necessary to know it is there and
manipulate it (99% of the time it is best to simply ignore it, but be
pleased it exists as it speeds execution).
Aliases are a user interface that exists entirely for the user to
manipulate to achieve various results.
The two are not even slightly similar (regardless of what the
implementations happen to be, and regardless of mechanisms added
(only in bash) that allow scripts to more easily examine their state.)
| To have some horrible disdain for one form of substitution
| but have no problem with the other being done automatically, doesn't
| appear to be a very rational point of view.
Nonsense.
Hidden optimisations - things that make execution faster but do not
otherwise change the results are fine.
Mechanisms that are being used for no other useful purpose than to
obscufate the code are something entirely different.
| Various commands can be implemented via separate programs or via
| bash-builtins.
That's true, but what has that got to do with anything?
| The bash-builtins are a form of a built-in alias for
| the command in that they are both intended to have a similar function,
Nonsense.
The "alias" we are talking about here is the specific command in
extended Bourne shells (extended as the original had nothing even
slightly similar).
You keep confusing the English word "alias" (two names for the same
thing) with the command "alias" which is a very specific thing which
is not the same as "two names for the same thing" though in limited
use it can be used that way. Aliases, the command, allow more,
and it is that more that is the problem, not the "let this name mean
the same as that name" which is relatively harmless. The effects
of the (very bizarrely defined) trailing space in the definition are
one of those bizarre, and dangerous, extra features - it changes
the interpretation of the following word in a way that simple name
aliasing (English word sense) never would.
If you're unable (or simply unwilling) to separate technical specific
use of a word, from generic English (or sometimes other language) use
of a word spelled the same, you will never be able to get very far, in
computing, or almost any other field (including just reading a contract,
which tend to define specific meanings for what would otherwise be
normal generic words.)
| however, the disk based and builtin functions often have differences,
| but not usually when used within some standard, documented subset.
They occasionally do, as they come from different sources, and one sometimes
gets extended without the other getting the same treatment. That's
unfortunate but not surprising really. This still has nothing whatever
to do with aliases.
In the NetBSD sh (which I currently maintain) only echo suffers from that,
all the other builtin commands (which also have filesystem equivalents)
are implemented from the exact same code, and so generally behave
identically when used, built in or not. Of course there is nothing to
stop someone writing a printf (or whatever) command, sticking it in their
private bin directory, and having it do something entirely different if
they want. That wouldn't be an alias under anyone's definition however,
simply stupidity.
| Similarly while bash has variables builtin, it seems conceivably
| possible that 'declare' could be implemented as an external command
Huh??? You want to be able to manipulate internal shell state with
a command that is living entirely in a separate address space? Sure,
if the shell knew the command was for that purpose (ie: had half of it
implemented internally anyway) and set up some private communication
channel to allow the command to tell the shell what changes it should
make, it could be made to work, but why would anyone bother to create
all of that mechanism?
| with all of the flags it supports. It could get context of where it was
| called from via FUNCNAME, *_SOURCE and *_LINENO while storing the variables
| in a disk-based database.
And you'd be happy with the shell needing to go consult a disk based
database for every variable reference? Really?
And that's quite distinct from the issue or how you'd implement local
variables in such a system, or have the effects of changes made in a
subshell environment magically vanish when the subshell environment exits:
declare -x foo=hello; (unset foo; declare -i foo=3; echo $foo); echo $foo
what would your external disk based database do with that?
And why is any of this relevant in any way to a discussion of the
alias command?
| It is very common for aliases to be used to give alternate forms to
| 'ls', like 'dir', 'll', etc.
Yes, it is, and if aliases are used only that way, and only in interactive
shells (to avoid typing) they are tolerable. They're not necessary for
any of that, it can all be done using functions, but aliases were originally
from csh (actually, ashell which preceded csh) which (at least at the time,
and probably still) has/had no functions or anything similar, and people
got used to doing that simple task that way.
In a script the normal form ought always be used (which is why, even though
it is not posix conformant, the bash "no aliases by default in non-interactive
shells" behaviour makes a lot of sense). All using aliases does there is
slow down execution (every command word needs a lookup of the alias table
if alias processing is enabled, and even if there are no aliases, that takes
time, and as more aliases get added, the time for every command, whether an
alias or not, increases - false hits on hash lookups are not frequent when
the hash table is nearly empty, but when it is full, they happen every
lookup). When the command being parsed actually is an alias, then the
text of the alias value needs to be substituted into the command line, and
the whole thing reparsed (the parsing that has already happened is wasted).
Why would anyone want to subject their scripts to all of that?
| In some implementations they are implemented as shell-aliases,
| while in others file-system aliases (links both hard and sym
| or softlinks).
Those are not the same thing at all. One is a manipulation of the
shell parser, and the other is just a command name, or (more commonly)
shell script. (If a hard link works to make "ll" be "ls -l" then the
ls command has to be parsing its (effectively) $0 to make that happen,
a few commands do that, most do not.)
| Some OS's besides implementing them as a link in the file
| system, can/do list them using some form of database: expandable paths
| in Windows, multi-valued destinations for different tools in linux under
| /etc/alternatives, and user-specific automounter-type mounts that generate
| different paths for different users.
I see no relevance to any of that. Some of it is just as barbaric as
aliases (including incidentally, cd -L and pwd -L which are truly evil).
| Some spoke 'feature-hate' about functions just as some do about
| aliases here.
"Some spoke" is 100% useless as an argument for anything, except when
the issue is whether or not something causes confusion (ie: should be
clarified, or specified more clearly). In that circumstance that different
people came to different conclusions about what something means is useful
information. Otherwise (as here) it simply means some people are wrong.
| To claim this or that is superior or different from any of the other
| multitude of technologies that provide similar functionality, but with
| variable features seems like arguing about what colors are ugly and
| distasteful for use in TTY backgrounds and text.
In some ways, yes - that's correct - but your implication that this is
a stupid/meaningless argument is incorrect. While colour choices might
seem like a random personal taste issue, they're not really, arguing that
black on black for use in TTY background and text is a valid choice is
simply insane - not everything is equally good - and some choices simply
are superior to others.
Eg: I use green on black for most terminal windows - back background as
that is "all off" and consumes less power. green foreground as (at least
in the past when I selected this method) as that is (was) generated by a
single beam from the CRT guns, and so remained crisp and readable even
on slightly misaligned CRT monitors (blue and red have the same characteristic,
white does not ... blue on black has poor contrast, so I avoid that,
red on black is kind of glary - I use that but only for terminal windows
that are somehow worthy of more standout appearance - ie: not often).
Again, there are reasons for these choices, just as there are reasons
for perferring functions to aliases (even to csh aliases which are much
more powerful than anything that any sh equivalent offers).
eg: while "alias ll='ls -l'" seems like a useful thing to do, and
you get in the habbit of using "ll" all the time (less typing, ...) for
your interactive use, and that's fine, but it could also be done as
ll() { ls -l "$@"; }
and have the exact same effect and usage. But then when you type
ll -C
and don't like the output, if you're wedded to the alias form, there's
nothing you can do, and you have to remember to use ls instead of ll in
that case, even though your brain is telling you that it is much easier to
type 'l' twice than 'l' and then 's'..
But with the function, you can just extend its definition to examine the
args, and if -C is found, don't add the "-l" and so now "ll -C" becomes
just the same as "ls -C" and your brain/fingers can keep on using "ll".
Functions simply offer more, they're more useful, and almost never fail
to be usable.
If that were all, there would be no use retaining aliases, as simply a
less powerful duplicate mechanism. But as they've been around a long
time, no real harm keeping them either. Unfortunately aliases can do
some things that functions cannot. That sounds strange, the "un" that
started the sentence looks as if it is misplaced. But it is not, all
of the things that aliases can do that functions cannot are best avoided,
no-one should ever be doing any of that (the possible sole current
exception, in some shells, is to compensate for function naming limitations,
which ought be fixed by simply removing those limits and allowing anything
that can be any command name to be a function name).
| > This isn't ksh, using `tracked aliases' to expose hashed pathnames.
| >
| Don't know what those are, so can't really say I'm trying to use them or
| not.
They're what you described the command hash table (incorrectly) to be,
more or less. Yet another different implementation for that, and one
best forgotten.
kre
