Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Eli Schwartz <eschwartz@archlinux.org>
Newsgroups: gnu.bash.bug
Subject: Re: alias problem -- conflict found
Date: Wed, 10 Jul 2019 23:13:10 -0400
Lines: 182
Approved: bug-bash@gnu.org
Message-ID: <mailman.889.1562814805.2688.bug-bash@gnu.org>
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> <fb6467a6-ffb2-f301-d87b-9c68af874314@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5ubWKmXodeEjiMPAAM7LRtBp9S5uoYUCi"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Openpgp: preference=signencrypt
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
In-Reply-To: <5D26A322.109@tlinx.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:15130

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5ubWKmXodeEjiMPAAM7LRtBp9S5uoYUCi
Content-Type: multipart/mixed; boundary="bIPLGU634Xxc50XJ3KrMxTYorrM2FWx6c";
 protected-headers="v1"
From: Eli Schwartz <eschwartz@archlinux.org>
To: bug-bash@gnu.org
Message-ID: <fb6467a6-ffb2-f301-d87b-9c68af874314@archlinux.org>
Subject: Re: alias problem -- conflict found
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>
In-Reply-To: <5D26A322.109@tlinx.org>

--bIPLGU634Xxc50XJ3KrMxTYorrM2FWx6c
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

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 wa=
s
> called from via FUNCNAME, *_SOURCE and *_LINENO while storing the varia=
bles
> 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 implemen=
ted
> as shell-aliases, while in others file-system aliases (links both hard
> and sym
> or softlinks).=20

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 unde=
r
> /etc/alternatives, and user-specific automounter-type mounts that gener=
ate
> 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=3D$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.
>=20
>     All of these can be used as substituting one thing for another, som=
e
> 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=
=2E
>=20
>     To claim this or that is superior or different from any of the othe=
r
> 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.
>=20
>     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 a=
nd
> 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.

--=20
Eli Schwartz


--bIPLGU634Xxc50XJ3KrMxTYorrM2FWx6c--

--5ubWKmXodeEjiMPAAM7LRtBp9S5uoYUCi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl0mqUYACgkQhIGKaBmv
Spti9w//Vxz5aO+r0sngXwq2oGlH9J6M0M8DUAUmDUANzAFSFlGtCwtk7lJL6Z36
J3YAPwVJPvt2moRB5rgDw7rby/5C+AQlLAg4arq/SAdw7To0pCZICVe/acEawvF8
bt3fmcVfflRp6E4N4cO5cjEW28is5jAh5aaNrVyvnBdflfEMFgVGRRKlONw7G0Oc
JoM//wlfN5xGlNBuh8h3VDM6iMkUsI6gXvg2So3czp4F+232CnRFuF9YcFkMN1gr
Ju6FazqKJa3Mq3AYK4ELQw+cyeU3we95+4wqpQb4HSFm8JUpWs6tJJGOqBdQzsrB
4gJTXafPGQcysY/KiAWDUFG1VDxNLCLUd7YeESje82Fk1RXo7RNdXJhujOwXAmaS
LNNbyjX8IReaiSnj1e0259oAZ2r9hugd9D/fAYyn1SBLwogU1ZNQJAt5wrTPEa//
Mh9Ql2U8WojkWATze+HQM1naMQjrV3QzV1YVpbG7RfvhceCNY3jsw3yrzBsCXExX
V3OERAhNuSJ9RPq7dzvtFhfJAWxgyV+VcIx5B85TLD+Kiw71MmvGBjmuDzHZ0pHg
XbLsRpoJfg4N4pNNd/LmhNuRdrlvFf9re4kJXx3aMh8PfxsIKM8/q+JRZ0MfyHGq
EiuEO7BwABU1S05Q2Y+TCPCqcy0EjVcdOUu9XHUPcyXZGvVEz92JAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXSapRgAKCRDOsWfvtXIr1rncEADfwJYP
dN9KAoY6Ykh4NXkMdTCTI2g3wY7gkm2it9k9WJZ1KhCF1cRUfYj7Xdqro+LHkcnF
I6x/BwJvmxgddG7j7P0tGzUM8eChj5hic2wuvz9K1vyUslq08gCUHrP9v3Wqsech
VnxzILxnPt69h8rbt5dbazEZRAdC+pxNgBy7Kor/dqIJYzsW1gbdvMzyxNuhv85y
GcuJFGXRbD3NNPoZ5loG81ZWcR30rt6PtPwUMCh7jnRpLzAQJEQTe6oq64GZdYx3
FjwTbIVWvjftNM8cJ6BnGsG6bbutGpq5QynX1bUTgZXD6yjKq9vXRHbfRS7bQ2Uj
QeKY7/mxSJ57ZsrSUtSuT9wOQJOAZdgueBNqx+Q8eeCwBIOKTMwswcmaNHZtZrmo
K/vwwOXTn14H9tiEqhoSzrWUsxw+L90zqpRgT6LDpUdF1MI7BFGCmzjuY6p7ROSk
RL15U6ldMUCV1r9IK2Uz1eB2Mt+juPHm4RGlcCZHPyooKTx/sNr99uMityNK5IQB
C7ViMsfsjbhZi2t6DMeOquJPnCXO6M6GkE3pbSJaIGNT/dS73wzS8h3IMedDwRc8
TUa5vmIe1aVvG92+fAraq4yBHPyjh45j/21C/2yBAK3FxYDDuVT0pLxOgW9ZsXtZ
P4cNJKBB/0ziOc/djROUHQdVpNq9M7UV6Q+w/Q==
=cXlP
-----END PGP SIGNATURE-----

--5ubWKmXodeEjiMPAAM7LRtBp9S5uoYUCi--