Date: Fri, 12 Jul 2019 10:22:18 -0700
From: L A Walsh <b...@tlinx.org>
Message-ID: <5d28c1ca.3000...@tlinx.org>
| They are both substitution mechanisms.
No, they're not. The hash table is an optimisation which speeds the
search for the pathname of a command, and that's all - everything works
just the same if it did not exist (other than its minor spec issues which
are rarely noticed). aliases are nothng like that.
| But as you point out, functions can replace almost every usage of aliases.
| So why wouldn't they be just as terrible?
The uses of aliases that functions can replace are the less terrible
parts - and functions are also more flexible where aliases (in this usage)
are almost too simple to bother with. The worse parts of aliases are
the things that functions don't do.
| They make the scripts easier to type.
There are many ways to make typing easier - most (good) editors allow
abbreviations, etc to be defined which are expanded as entered.
For interactive use, I don't mind a few aliases (or equivalent functions)
to save typing, in a script, either using the power of a good editor
to expand things as entered, or entering shorthand and then doing global
replaces (you could even have a script which does just that to your
finished typing) is a much better idea than writing scripts containing
aliases when they're finished.
| So you are saying the built in 'test' isn't meant to be POSIX compliant
| in the same way /bin/test is?
It should be, ideally it would be the same. bash's test has been
extended (in some parts in meaningless ways I don't much like, and
never use) - but this has nothing whatever to do with aliases.
Here you're talking about the same name having two different meanings
depending upon which version gets used, which is the very opposite of
any kind of alias, which is two different names for the same object.
| For that matter, you are saying they aren't intended to be a POSIX
| compatible, drop-in replacements for those commands?
I am fairly certain I said nothing even slightly like that.
What I said was that your claim that bash's built in test is some kind
of alias for the external command test, was nonsense, which it was (and is).
They are not even aliases in the generic English word usage, let alone
being an alias in the sense of the shell command of that name, which is
what is the subject of this discussion.
The built in test might be considered as a replacement, or superset,
of the external command test (or they could just be two commands that
happen to have the same name (which does *not* make them aliases) which
do similar but different things. Both should do what POSIX demands,
both are likely extended, perhaps each in ways that differ from the
other (depending upon with just which version of the external command
test you are comparing the bash builtin version).
For me, with the shell I use for script writing (not bash), the builtin test
and /bin/test are 100% identical. That does not make them aliases
in any form at all, or anything like any kind of alias.
| > You keep confusing the English word "alias" (two names for the same
| > thing) with the command "alias"
| They are the same.
They are not. The english word alias has nothing in its definition
about the effect of a space at the end of the definition, nor does it
have any restrictions on where the alias can be used - the command does.
They are not anytything like the same - though the name for the command
comes from the English word because one specific use case has some
similarities to the English word.
(If you like, this is more or less the same as how the "test" command
is derived from the English word "test" - without there being much
similar about how they get used or what they can do - especially as the
command is only even similar to the word as a verb, not a noun.)
| Anytime you you a word to refer to two different things, you will
| see differences. People use the word computer to refer to iphones and
| Crays.
Yes, They both are (or contain) computers. That's not odd. one
is just large and old, and today, not all that fast really, the other
is smaller, newer, etc - but they both have the same essential
cfomponents inside.
What has this got to do with anything? iphones are not aliases for crays,
neither of those are aliases for computers, they're just specific types of
computer.
| The reason the technical implementation was called an alias is because
| it is one.
Because one limited use of the command makes what is effectivelty
an alias. That's the part no-one cares much about - while it can
be used to make thngs harder to understand, only in a limited way.
But the alias command can do more than that, and that extra is
wrere using aliases gets really poor. And just like use of
aliases (unrelated to chell commands) in the world complicates life
for everyone - both the user of the alias and others - so does
the use of (even this limited form) of aliases in the shell. In a
few cases the costs actually provide enough benefit to make it all
worth while, but those are rare - mopstly it is much easier for
everyone if we just agree on what we call a thing (or person), and
all use the same name.
| That different instantiations of of a word have differences is so
| entirely common place as to pass with little comment.
Usually yes. But when you start using one meaning (which has little
to worry about) to justify the other (different) version, you will elicit
comments.
| It's called "deductive reasoning".
Only if it follows the principlies of that discipline - and simply
asserting that thwo things are the same, and hence if one is good
(or at least OK) then the other must be as well, is not deductive
reasoning, it is nonsense.
| Saying something could be done isn't the same as wanting it to be done.
That's true, but saying it could be done doesn't mean that it can be
done either.
| > what would your external disk based database do with that?
| >
| It would do the same as the builtin. That was the point.
How? That was the question.
| But never mind.
Oh, I see, it cannot (in any simple fashion, without extending the
shell to know what this external command is doing and assist it - ie:
it would not really be an external command at all). That's what I thought.
| If it made alot of sense, it would be the POSIX default.
You clearly do not understand POSIX. What POSIX defines is not what
makes sense (large parts of it are sheer lunacy) - what it does is
writes down what the implementations do - and since they're mostly all
copied from what the first implementation did - good or bad - in order
to be compatible, that's what POSIX specifies. Its purpose is to let
the users know what will happen when they do X, and to let the implementors
know what they need to make happen when the user does X to be compatible
with all of the other implementations (so the user's script will work).
There is absolutely nothing in the guidelines that says anyything needs
to make any kind of sense at all.
aliases are specified they way they are because that is how they were
implemented in ksh88 which is the shell (largely) used as the basis for
the shell specification in POSIX.
Go to POSIX and tell them they should change something from the way
everyone does it, to something different, because it would be better that
way (even if everyone agrees with that premise) and you'll simply be
ignored (if not actively laughed at ... though that would probably only
happen if you persisted).
| To get the POSIX default in bash, you need to start with a prologue, like
| 'shopt -o expand_aliases',
Yes, that's because bash (quite sensibly) does not believe that anyone
should normally ever use aliases in scripts. That is a very commonly
held view.
ksh88 allowed it however, and most other shells simply copied that,
so POSIX allows it, as dumb an idea as it is.
| But no where near as much as functions slow things down. Functions
| are over 60% slower. So if that's your reason for hating aliases, hate
| functions more.
No, it is one reason for not using aliases which do nothing more than
rename commands. I wouldn't use functions for that in a script either.
Both just make the script harder to understand (and slower) for no
practical benefit at all.
I use functions in scripts for the same reasons people uses functions
in any programming language - to simplify the code and add clarity.
aliases never do that. Paying for those benefits with some execution
time penalty is justifiable.
| All of coreutils can be build as 1 binary with all of the commands
| being a hardlink to the main binary. All of the commands used everyday
| have that logic built-in to their source.
So? Sure that is a case where the command name is used to decide
which code to run - but only to separate out the independent binaries
that have been linked into one object, which isn't much different from
deciding when (separate) command binary to run amongst the commands in
/bin based upon the name of the command.
This is not quite the same as things like grep/egrep/fgrep which (these
days, though not originally) is one example of a command which has three
front ends which modify the default operating mode based upon the command
name (but which are really all just one command with different option
ettings internally).
None of this has anything to do with aliases. egrep is not an alias for
grep, it is not really even an alias for "grep -E" (though close to that
in the English language sense) - it is definitly not any kind of shell alias
or anything even similar.
| While that may be true, how many people, especially ones who indicate
| a concern about power consumption use a CRT for a display these days?
Almost none - I was simply explaining the history of my choices in
this area, and that they were not simply based upon personal taste.
That is, sometimes there are hidden reasons behind even the most
seemingly arbitrary choices. That it is not always immediately
obvious does not mean there isn't a good reason behind some choice.
| 2) The last option on the command line takes precedence, so I know with
| an alias, that everything I type will come after included options. The same
| is not true in functions. I have functions for some commands for specific
| situations -- that don't work with other options because with functions,
| you never know how the cmd options are mixed in with the built-in options.
You never know? Don't you read the function? Or at least its doc?
| Aliases are much clearer and more predictable in how they are
| applied and the order in which they are used.
You obviously don't really have much experience with the true world of
aliases - you're only using them in one very restricted way.
| I will never have to look at the source of an alias to find out
| what order it is applying flags in or whether or not
| their function handles new switches/options.
So if you saw me using an alias "lr" that was clearly using ls
as the command, you'd immediately know what it is doing, without
looking at it? Really?
Aliases are not better this way, they're simply more restricted.
You need to look at the alias code, or its documentation, to find out
what it does, just the same as you would a function.
| Sorry, but alot of people don't know how to write a function that modifies
| behavior, but they do know how to create a short-hand or abbreviation for
| a command. For most people aliases are easier to understand and use.
So now you're advocating perpetuating ignorance - the people don't know,
so let's not tell them.
I prefer education - teach the people how to use functions - as in everything
start with simple cases, and then allow more and more to be added. Soon
those people will have no problems with functions at all. They are not
all that difficult to master, and no-one needs to use anything more than
they are comfortable with. That the syntax is different is (in the
overall scheme of things) just noise.
| Functions offer more to programmers, not users who don't know programming.
They are just as useful to non-programmers as aliases. One does not have
to write programs in a function (though it is possible) - it is just as
easy to do simple command substitutions, addition of options, or whatever
else is needed. But then when the user asks "Could I do ...?" you can
answer yes, if functions are being used, and explain how - with aliases
usually all you can say is "no, sorry, aliases can't do that".
| Because they are more powerful, they almost always are more prone to
| failure than something simple like an alias.
If you believe that then you really do not understand how aliases work.
There is nothing clean and simple about them - though they can appear that
way in very simple usages. But it is very easy to get into an absurdly
complicated (and hard to debug) mess with aliases.
Functions are much easier to work with, as they appear as real objects
in the shell, all the shell's normal debugging/tracing mechyanisms work
for ovserving what a function is doing. For aliases ....
kre
