Re: alias problem -- conflict found

[L A Walsh]

On 2019/07/10 00:04, Robert Elz wrote:
>     Date:        Tue, 09 Jul 2019 20:24:30 -0700
>     From:        L A Walsh <bash@tlinx.org>
>     Message-ID:  <5D255A6E.4060600@tlinx.org>
>
>   |     Why?  What makes clarity "horrible".
>
> It isn't the clarity (if you call it that, it is really obscurity
> as no-one else can read your scripts/commands and have any idea
> what they really do) but the using of aliases that way to achieve it.
>   
I doubt that.
You are going to tell me that saying
int i=1 is too obscure to be deciphered by most, versus
declare -i i=1;

Including those that have never seen a unix shell?

There's alot more people who experienced DOS and command.com than
unix, I'm guessing they'd be able to figure it out, even if unix users
couldn't
(which I doubt).

Try write a function to emulate "int" in a posix compatible shell.


> You could easily do what you want, much more effectively, and with
> less disruption using functions instead ... with a function, the
> conversion from "Export" to "-x" would only happen inside the "my"
> function,
I actually don't use Export.  Ever.  Just included it for testing and
uncovered
a conflict.  If it has been a function one would have overwritten the other
and I would have had some other problem farther away from the source of
the error.  Errors are best when they happen close to the source.

>  so you would be able to just use "export" (and even allow
> abbreviations) if you wanted - without it conflicting with "export"
> used as a command.
>   
I don't know, I don't have a function named export.  At least in my
testing I used Export and not 'export'...similarly, I use 'map' rather
than 'hash'.

> Aliases are disgusting, and always have been - they remain really only
> because POSIX says they should (because David Korn thought he needed
> to copy that bit of csh which needed to do things this way because of
> other limitations in the underlying implementation) - and because of
> other dumb rules there are just a few things that functions cannot do,
> which aliases can ... but in those cases the best solution is to write
> a function with a different name (which is always the sole problem) 
no - it's not.
> and
> then use an alias to make the name you want to use to the name that will
> work for the function, and no more than that.
>   
----
    So if you have a function that returns the names of options, howdo you
declare the name in the function and have it be in global scope without
using
the bash-only flag for defining at global scope?  You can so it with an
alias+function, but not functions only.  Functions can't process their
arguments
in the current scope.  Like you said above, if 'my' was a function then
it tried to use a function named Export to export variables that came
after it,
it wouldn't be at global scope.

    I use functions where appropriate, but there are things not
appropriate for
functions.  aliases are simple substitutions.  For the most part, they
are done
as the file is read in.  They take no memory -- they are like a macro
preprocessing language, but not as advanced.  Functions are executed at
run time.  You can change their definition at run time.  With aliases
you can't
do that.  Aliases are used internally by bash to store path lookups, by
default.
They are simply more efficient.  If functions were better, bash would
implement
path lookups by defining a function for each -- but that would just be
ridiculous.