Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: L A Walsh Newsgroups: gnu.bash.bug Subject: Re: alias problem -- conflict found Date: Wed, 10 Jul 2019 19:46:58 -0700 Lines: 93 Approved: bug-bash@gnu.org Message-ID: References: <5D25D398.7010300@tlinx.org> <5D255A6E.4060600@tlinx.org> <5D23C417.5060108@tlinx.org> <20190709132112.GW2450@eeg.ccf.org> <10340.1562742284@jinx.noi.kre.to> <11760.1562772554@jinx.noi.kre.to> <5D260BD8.8010800@tlinx.org> <480d3363-dce0-6629-b1f6-bca0b006cc88@case.edu> <5D26A322.109@tlinx.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1562813232 1248 209.51.188.17 (11 Jul 2019 02:47:12 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Robert Elz , bug-bash@gnu.org To: chet.ramey@case.edu Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <480d3363-dce0-6629-b1f6-bca0b006cc88@case.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <5D26A322.109@tlinx.org> X-Mailman-Original-References: <5D25D398.7010300@tlinx.org> <5D255A6E.4060600@tlinx.org> <5D23C417.5060108@tlinx.org> <20190709132112.GW2450@eeg.ccf.org> <10340.1562742284@jinx.noi.kre.to> <11760.1562772554@jinx.noi.kre.to> <5D260BD8.8010800@tlinx.org> <480d3363-dce0-6629-b1f6-bca0b006cc88@case.edu> Xref: csiph.com gnu.bash.bug:15129 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.