Re: alias problem -- conflict found

[L A Walsh]

On 2019/07/10 11:04, Chet Ramey wrote:
> On 7/10/19 12:01 PM, L A Walsh wrote:
>
>   
>> What do you think aliases are?  They are both a simple hash substitution.
>>     
>
> They might appear superficially similar, and they use similar internal
> abstractions.
>
>   
>> declare -A BASH_CMDS=([ls]="/usr/bin/ls" )
>> declare -A BASH_ALIASES=([ls]="/bin/ls" )
>>     
>
> And I made them both available using array syntax, using a different
> internal mechanism, but:
>
>   
>> Aliases are store/implemented using hashes the same as stored paths
>> are.  They are effectively the same.
>>     
>
> Which is not at all what you said initially.
>   
----
    But it was what I was thinking when I said they were the same.

    Both are a simple substitution that bash gives the
appearance of being the same mechanism.

    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.

    Various commands can be implemented via separate programs or via
bash-builtins.  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,
however, the disk based and builtin functions often have differences,
but not usually when used within some standard, documented subset.

    Similarly while bash has variables builtin, it seems conceivably
possible that 'declare' could be implemented as an external command
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.

    It is very common for aliases to be used to give alternate forms to
'ls', like 'dir', 'll', etc.  In some implementations they are implemented
as shell-aliases, while in others file-system aliases (links both hard
and sym
or softlinks).  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.

    Not too long ago, some people pushed for restrictions on what you
could have a pointer (symlink no less) on disk point to -- even though
it can't override filesystem protections -- sorta reminds me of links
on the internet pointing at a topic and people going after the people
pointing to the topic with the link as "offenders" or "intruders"...
Both seem equally lame.

    All of these can be used as substituting one thing for another, some
proving a simple macro-type name substitution, while others can change
what you think you are using entirely, while others, some believe,
create invasions or intrusions...whatever.

    Certainly, functions can be subjected to more abuse than aliases as
was evidenced when security related problems surfaced with functions.  Some
spoke 'feature-hate' about functions just as some do about aliases here.

    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.

    These are technical features.  I get that you worship some features over
others.  That's nice, just don't expect to convert me with propaganda and
opinion.


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