Re: alias problem -- conflict found

[L A Walsh]

On 2019/07/10 21:46, Robert Elz wrote:
>   |     Both are a simple substitution that bash gives the
>   | appearance of being the same mechanism.
>
>
> 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.)
>   
    They are both substitution mechanisms.  One allows more flexibility.
But as you point out, functions can replace almost every usage of aliases.
So why wouldn't they be just as terrible?  Some people outside of this list
said they were just as bad and would like for them to have been removed. 
Everyone has an opinion.

> 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.
>   
----
    They make the scripts easier to type.  I don't find people unable
to understand the simple usage that I confine things to in released scripts.

>   | 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.
>   
----
    So you are saying the built in 'test' isn't meant to be POSIX compliant
in the same way /bin/test is?  For that matter, you are saying they
aren't intended to be a POSIX compatible, drop-in replacements for those
commands?  If that's your position, you are wrong.

> The "alias" we
You
>
> 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.
    They are the same.

>    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.
>   
    In a way, that isn't necessary in spoken language, because such
doesn't have
a limiting syntax.  That it allows the next item to be an alias is your
claim that something is "bizarre".  You really need to get out more.

> If you're unable (or simply unwilling) to separate technical specific
> use of a word...
    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.
The reason the technical implementation was called an alias is because it is
one.  That different instantiations of of a word have differences is so
entirely common place as to pass with little comment.  I would assert
you will
get less far in the world than I would if you are unable to group thing
together
or note similarities.  It's called "deductive reasoning".

>   | 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.
>   
    Doesn't it? Aliases were extended to allow usage other than at the
beginning
of a phrase, by including a space.  They were extended.  In a similar
way, paragraph formatting functions of some programs extend the
formatting to the next line based on a following space.  It's not
something weird, but something
used for the same purpose elsewhere.
>
>   |     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? 
---
    Saying something could be done isn't the same as wanting it to be done.
>
> 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?
>   
    It would do the same as the builtin.  That was the point. But never
mind.
> 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). 
----
    If it made alot of sense, it would be the POSIX default.  To get the
POSIX default in bash, you need to start with a prologue, like
'shopt -o expand_aliases',
>   All using aliases does there is
> slow down execution
    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.
> 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.)
>   
---
    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.
> 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.
>   
    The first thing that has to be true before comparing them is that they
need to work.  Having 0% contrast in text doesn't work for enabling humans
to read it.  It doesn't work.  Beyond that, it gets less clear.

> 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
    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?


> 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, 
----
    1) I only use ll when I want a long listing, not because it is easier
than 'ls'. 
    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.

    Aliases are much clearer and more predictable in how they are
applied and
the order in which they are used.  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.
> if you're wedded to the alias form, there's
> nothing you can do, 
    There's nothing you need to do -- it just works.
> 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".
>   
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.
> Functions simply offer more, they're more useful, and almost never fail
> to be usable.
>   
----  
    Functions offer more to programmers, not users who don't know
programming.
    Because they are more powerful, they almost always are more prone to
failure
than something simple like an alias.  But functions are necessary for
many things.  But only those who know how to program can effectively use
them, which
may include most on this list, but not so much the general public.