Re: alias problem -- conflict found

[Eli Schwartz]

On 7/10/19 10:46 PM, L A Walsh wrote:
>     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.

Don't worry, I hate the idea of using either one for the purpose of
turning bash into some typedef perl/C wannabe. My disdain is truly
equal-opportunity.

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

So now you think that `builtin echo` is an "alias" for /bin/echo simply
because they have similar functionality?

Is printf by any chance an alias for echo -n, because it sometimes does
the same thing, and therefore their effects are "similar"?

Are we on camera? Is this just deliberate trolling?

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

Why don't you go implement a disk-based database for bash's internal
stack. Let's see how that goes.

It's conceivably possible that someone might drill an air hole in their
own head, but I don't consider it very likely or reasonable. The fact
that there is no law of physics forbidding it is not actually a great
proof to, well, anything.

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

None of that is attempting to typedef an internal feature of the
programming language itself.

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

Offtopic? /etc/alternatives is there to let a system administrator
choose what "foo" is on a specific computer as opposed to in a vendor's
default configuration.

FUSE filesystems that expose different content depending on which user
accesses it, is not even something I've seen used before for
manipulating the available *commands* on a system -- that's going to be
used for (typically networked) *data*.

I have no idea what an "expandable paths in Windows" are, but if you're
suggesting the equivalent of "PATH=$HOME/bin:$PATH" in /etc/profile,
then that's hardly a Windows feature, plus, it's still not remotely
comparable to using "bash: revenge of the typedef".

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

Changing what you think you are using entirely seems pretty silly,
wouldn't you rather *know* what you're using?

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

They all suck. They suck the way you are using them, and they will
continue to suck even if you implement them via functions instead.

It's not a matter of which is better or worse because it is capable of
being subjected to more abuse. It is a matter of "omg, this Linda Walsh
person is a person who habitually goes around trying to figure out ways
to abuse every tool she can get her hands on".

That, right there, is the problem. You want to abuse things. And lo and
behold, you have found ways. Don't go around expecting other people to
*not* look askance when they see you do it.

-- 
Eli Schwartz

signature.asc
Description: OpenPGP digital signature