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: Fri, 12 Jul 2019 14:51:00 -0400
Lines: 401
Approved: bug-bash@gnu.org
Message-ID: <mailman.1043.1562957481.2688.bug-bash@gnu.org>
References: <5D26A322.109@tlinx.org> <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> <9139.1562820381@jinx.noi.kre.to> <5D28C1CA.3000002@tlinx.org> <d59b3149-c458-84df-99ab-96bc4bbbce3d@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BlUg4XxkkztRWbUc1rk90Z43y1QYQfGy7"
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: <5D28C1CA.3000002@tlinx.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:15139

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BlUg4XxkkztRWbUc1rk90Z43y1QYQfGy7
Content-Type: multipart/mixed; boundary="12LUesUkrbZUbc0SKn7EzR0xZwUCh8hr6";
 protected-headers="v1"
From: Eli Schwartz <eschwartz@archlinux.org>
To: bug-bash@gnu.org
Message-ID: <d59b3149-c458-84df-99ab-96bc4bbbce3d@archlinux.org>
Subject: Re: alias problem -- conflict found
References: <5D26A322.109@tlinx.org> <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>
 <9139.1562820381@jinx.noi.kre.to> <5D28C1CA.3000002@tlinx.org>
In-Reply-To: <5D28C1CA.3000002@tlinx.org>

--12LUesUkrbZUbc0SKn7EzR0xZwUCh8hr6
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

On 7/12/19 1:22 PM, L A Walsh wrote:
>> Hidden optimisations - things that make execution faster but do not
>> otherwise change the results are fine.
>>
>> Mechanisms that are being used for no other useful purpose than to
>> obscufate the code are something entirely different.
>>  =20
> ----
>     They make the scripts easier to type.  I don't find people unable
> to understand the simple usage that I confine things to in released scr=
ipts.

Good grief.

=2E.. How often do you need to re-type out a production script, that you
feel a strong desire to optimize for ease of re-typing out rather than
readability?

I am mind-boggled that you don't grasp a very very simple programming
need-to-do: use functions (or aliases if you really feel like it) when
it lets you group complex tasks that need to be repeated, use variables
when something can potentially have multiple meanings, and otherwise
just *say what you mean*.

You keep insisting that typedef'ing bash into perl makes it easier for
you to type. But you don't type a script every hour/day/week/whatever,
you *run* it at those intervals, and you should be optimizing for what
*actually* matters, which is readability of static production code.
Since you're not constantly typing it, it doesn't matter how many
keystrokes you're saving, because at the end of the day, you're not
using a single keystroke regardless of which way you do it.

>>   | Various commands can be implemented via separate programs or via
>>   | bash-builtins.
>>
>> That's true, but what has that got to do with anything?
>>
>>   | The bash-builtins are a form of a built-in alias for
>>   | the command in that they are both intended to have a similar funct=
ion,
>>
>> Nonsense.
>>  =20
> ----
>     So you are saying the built in 'test' isn't meant to be POSIX compl=
iant
> in the same way /bin/test is?  For that matter, you are saying they
> aren't intended to be a POSIX compatible, drop-in replacements for thos=
e
> commands?  If that's your position, you are wrong.

You just went completely, wildly offtopic. The only response I can find
is "pink elephant".

Please don't do that again.

>> The "alias" we
> You
>>
>> You keep confusing the English word "alias" (two names for the same
>> thing) with the command "alias" which is a very specific thing which
>> is not the same as "two names for the same thing" though in limited
>> use it can be used that way.  Aliases, the command, allow more,
>> and it is that more that is the problem, not the "let this name mean
>> the same as that name" which is relatively harmless.
>     They are the same.

No they aren't.

See, I can throw unexplained assertions around too!

(But they really aren't.)

>>    The effects
>> of the (very bizarrely defined) trailing space in the definition are
>> one of those bizarre, and dangerous, extra features - it changes=20
>> the interpretation of the following word in a way that simple name
>> aliasing (English word sense) never would.
>>  =20
>     In a way, that isn't necessary in spoken language, because such
> doesn't have
> a limiting syntax.  That it allows the next item to be an alias is your=

> claim that something is "bizarre".  You really need to get out more.
>=20
>> If you're unable (or simply unwilling) to separate technical specific
>> use of a word...
>     Anytime you you a word to refer to two different things, you will
> see differences.  People use the word computer to refer to iphones and
> Crays.
> The reason the technical implementation was called an alias is because =
it is
> one.  That different instantiations of of a word have differences is so=

> entirely common place as to pass with little comment.  I would assert
> you will
> get less far in the world than I would if you are unable to group thing=

> together
> or note similarities.  It's called "deductive reasoning".

The problem here is that, to use your Cray/iphone analogy, you posted to
a mailing list about Crays, started discussing the engineering
implementation that defines how a Cray works and what makes it different
from other technological devices, and then halfway through the
conversation you referenced the word "computer" but you were actually
referring to an iphone.

Not only is it highly understandable for someone reading that
conversation to be confused, it's also mendaciously dishonest to use the
word in that context. I deduce, therefore, that you *wanted* to be
misunderstood.

>>   | however, the disk based and builtin functions often have differenc=
es,
>>   | but not usually when used within some standard, documented subset.=

>>
>> They occasionally do, as they come from different sources, and one som=
etimes
>> gets extended without the other getting the same treatment.   That's=20
>> unfortunate but not surprising really.   This still has nothing whatev=
er
>> to do with aliases.
>>  =20
>     Doesn't it? Aliases were extended to allow usage other than at the
> beginning
> of a phrase, by including a space.  They were extended.  In a similar
> way, paragraph formatting functions of some programs extend the
> formatting to the next line based on a following space.  It's not
> something weird, but something
> used for the same purpose elsewhere.

That's very nice, but it's also unrelated to the thing which you just
quoted and purport to be responding to.

>> In a script the normal form ought always be used (which is why, even t=
hough
>> it is not posix conformant, the bash "no aliases by default in non-int=
eractive
>> shells" behaviour makes a lot of sense).=20
> ----
>     If it made alot of sense, it would be the POSIX default.

Oh, you sweet summer child.

> To get the
> POSIX default in bash, you need to start with a prologue, like
> 'shopt -o expand_aliases',
>>   All using aliases does there is
>> slow down execution
>     But no where near as much as functions slow things down.  Functions=

> are over 60% slower.  So if that's your reason for hating aliases, hate=

> functions more.

That is entirely true. If you use a stupid programming paradigm, it's
just as stupid whether you use a function or an alias.

Typedef'ing bash to be perl is a stupid programming paradigm. It's just
as stupid as a function.

I believe Robert's point is that he doesn't actually believe aliases
have a legitimate use case in non-stupid programming, while functions
do. (But either way, the reason this conversation has gone on as long as
it has is because a bunch of people believe that you are engaging in a
stupid programming paradigm, which is the reason you are using aliases
in the first place as it has more ways to be abused.)

>> Those are not the same thing at all.   One is a manipulation of the
>> shell parser, and the other is just a command name, or (more commonly)=

>> shell script.   (If a hard link works to make "ll" be "ls -l" then the=

>> ls command has to be parsing its (effectively) $0 to make  that happen=
,
>> a few commands do that, most do not.)
>>  =20
> ---
>     All of coreutils can be build as 1 binary with all of the commands
> being a hardlink to the main binary.   All of the commands used everyda=
y
> have that logic built-in to their source.

While it is true that the GNU coreutils project supports such an option
(and so does busybox!), that is a very far cry from disproving Robert's
assertion that "a few commands do that, most do not".

Of course, you are more than welcome to do a full research project on
the literally millions of programs that exist in the entire world, and
formally prove that the majority include such options.

Even if you were able to prove this pointless point, I would not go
around congratulating yourself on disproving a throwaway, irrelevant
assertion. The part of the paragraph which was not hidden away in
parentheses, and which it is plainly obvious is the only thing Robert
actually cares about debating, is that a command which *does* implement
its own internal argv0 processing in order to change what it does
depending on how it is called, is very different from an alias, which is
doing the same thing by typedef'ing the shell parser before ever
emitting a subprocess call in the first place. The former actually
knows, itself, what is happening.

Commands which implement "alternative functionality like making ll run
ls -l" based on symlinks are actual commands, not "aliases". (This is an
important distinction if you believe that the word "alias" has a
programming meaning, and it is not an important distinction if you would
rather pretend to be an English professor just to stir up trouble.) The
fact that they both happen to use the same source code, and even go one
step further and share the binary install space as a space-saving
measure, is not actually pertinent -- you could just as easily implement
it as a stripped-down version of the original program sources.

>> eg: while "alias ll=3D'ls -l'" seems like a useful thing to do, and
>> you get in the habbit of using "ll" all the time (less typing, ...) fo=
r
>> your interactive use, and that's fine, but it could also be done as
>> 	ll() { ls -l "$@"; }
>> and have the exact same effect and usage.   But then when you type
>> 	ll -C
>> and don't like the output,=20
> ----
>     1) I only use ll when I want a long listing, not because it is easi=
er
> than 'ls'.=20
>     2) The last option on the command line takes precedence, so I know =
with
> an alias, that everything I type will come after included options.  The=
 same
> is not true in functions.  I have functions for some commands for speci=
fic
> situations -- that don't work with other options because with functions=
,
> you never know how the cmd options are mixed in with the built-in optio=
ns.
>=20
>     Aliases are much clearer and more predictable in how they are
> applied and
> the order in which they are used.  I will never have to look at the sou=
rce
> of an alias to find out what order it is applying flags in or whether o=
r not
> their function handles new switches/options.

If your function is designed to exactly resemble an alias because it
inserts "$@" after the command and included commands, then it's very
predictable. If you don't trust the person making the function, though,
why do you trust the person making the alias? Instead of sneakily
inserting flags after the "$@", they could also just make the alias
prepend "rm -rf ~; ", which is also pretty sneaky and totally possible
to do in an alias.

Alternatively, what about this nice alias:

alias ll=3D'f() { ls "$@" -l; }; f'


Surely aliases will save you!

Aliases will *always* apply included options only before manually
applied options, regardless of whose unvetted aliases I have in my
bashrc that may or may not conform to my personal beliefs about how
aliases and functions should be designed to operate (because I didn't
write them and cannot predict exactly what they will do, but I know it
will be good anyway because it's an alias, so um yeahhh mkay).

I will never, ever, ever have to look at an alias's source, regardless
of "why", because aliases are beautiful things and the world is a
beautiful place and aliases are my best friend!

(In case you somehow mussed my meaning: no, aliases are not beautiful
wonderful things. Aliases are tools to do what you tell them to do, just
like functions are tools to do what you tell *them* to do, and each
happen to work in somewhat different ways, and if you don't trust your
functions to do what you explicitly designed them to do then you really
should not trust aliases either.)

>> if you're wedded to the alias form, there's
>> nothing you can do,=20
>     There's nothing you need to do -- it just works.

Conveniently, so do functions.

Oh right -- except for when they are incomprehensible typedefs in a
non-interactive shell. Then they don't work, but not because of a flaw
in the language specification -- just because of a flaw in the human fact=
or.

>> But with the function, you can just extend its definition to examine t=
he
>> args, and if -C is found, don't add the "-l" and so now "ll -C" become=
s
>> just the same as "ls -C" and your brain/fingers can keep on using "ll"=
=2E
>>  =20
> Sorry, but alot of people don't know how to write a function that modif=
ies
> behavior, but they do know how to create a short-hand or abbreviation f=
or
> a command.  For most people aliases are easier to understand and use.

Which is why even Robert would agree that aliases are fine in an
interactive shell.

Of course, none of these people you refer to are going to write
production scripts.

At least, I hope they aren't. If they don't know what a function is, I'm
not sure I trust them to know any of the many, many important things one
should know when writing shell scripts.

>> Functions simply offer more, they're more useful, and almost never fai=
l
>> to be usable.
>>  =20
> ---- =20
>     Functions offer more to programmers, not users who don't know
> programming.
>     Because they are more powerful, they almost always are more prone t=
o
> failure
> than something simple like an alias.  But functions are necessary for
> many things.  But only those who know how to program can effectively us=
e
> them, which
> may include most on this list, but not so much the general public.

And if they don't know how to program effectively, I would suggest they
need to learn how, before writing complex production scripts that
typedef bash into perl using aliases.

Using functions will be more reliable, more rewarding, more powerful,
and more effective than using aliases. Of course, becoming a perl
programmer would also be more powerful and more effective than being a
bash programmer -- as for reliable and rewarding, well,
$insert_perl_joke_here.

--=20
Eli Schwartz


--12LUesUkrbZUbc0SKn7EzR0xZwUCh8hr6--

--BlUg4XxkkztRWbUc1rk90Z43y1QYQfGy7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl0o1pQACgkQhIGKaBmv
Spt0oQ/+OcoDuN9M3cEqAxvVqS+qPOAkcfGJZoGolVABsaqIbnRSqVUXhhA0C19n
1CxA8Brz/Vir+FmUnjOP18bvFnMk4lWeeuR9lwGT9Q49N+1o0U9RFXKmBDbFVrIA
4YpUIkIbo05dGI2ZOF0aX3uBDC7cHK/PvQjDX6U6luvW8Ui6YAHrSlPDMyg5HyNN
TMG5hOE6pBQTtT2lBEZLizDJvAVQZTve+4zd+iH9KNoLRGGBUT4peyxRRsLZtW2B
MmLV22o4AYhA9fLa2B/aRnyhp7gmLbISdAtOf5yvxUqDp3gHkybpfsDFp4NLE94a
6wlvF8+TY161IhmMPv1PLS2rPW/iK73cSST9ZVkx1xfjemLcANIsNiNk3fwdDTgU
RrJnQoXUnQYroiLL8tazMW4BRHbkxR0VfTXHzvmjGNUDe9ByawiWhkocQoh06t0o
vH+iX1X4VHxUWFsjGlC13BheVQSVqwAQP3VYzOL7JNtai0+PKIKTJln8NfvUqokS
nidEQEU6/u2Sb/Xo7RLZGmZqRYnSVbVRWOCLzdYgIngLhTCqW/25Uxxwkd3UZxc9
/OpZcwD2HtkPaPo71GBfVA/OkYxXtdw2lk79jvpvZicsBxw/zf0WXDUoW45Hc2ZI
dA1U3PDUnrps38XcTX4b2iA0dv9oPBWRWS+0J9ciCE1UTijpsMuJAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXSjWlAAKCRDOsWfvtXIr1hCiD/42540k
7Gau909On5m194aSgPKUaGeKY6fga9FgN4RZJXdf+RwzmTASpodMtbWwAnPYO0Yp
C0l/L2XYkhmZOL66GIwj7TYToEs330GGMpJBZ78Tgd/8jxQKdxmy3R0nJDqBkB5l
Z3uf8XR8YaVjTJ+2gGoKz8lIW9KmKJaOtAefcJqXJCHfJ7pfI1XcJREXh1xAkRqp
Q59NQaN1W/5TJ+XoyaLFbmYFuPjHqvLr5/GRyhsjOQo579DbtegmHPzxKVrx240R
xmOlL38ixE/6GBefsqMgv571QPTdM3y4qN/lMB3mExLDqV3jWjd4qko3CFajKLNI
/yxSvstAZuF0z64FQUUyOXUVp0x8ZIwaGB4FBHNHgXBy0RzNdu65rJ3EYa62sHLH
D98f52IKaL60bzRck5eeOKWyHKOeAtIXXniyz3VR/AXKJO8cqEMFPR8hBh5TV1xV
PKEr4rhnfMV2N4w9CLrRyEXQgwLq3i+RNrtkq2Z8XkvskthQ9zVbwsk2HQbo8IQ2
Z5yEvJozCfDtLeMclWU67F2ocrIf41RkaXuweU8LmYHCt7uRG3U/FKCBMeETEiaK
kjUqWOA2+ET6Qu8l/AXcfp0M8NOicKKCUkoy+iUaJW9hKcYv02j9GeoOhTXPy8m6
ioPbuzgeRuFCj27JZpwWq7Y+JeEPV5gIVkZVTg==
=NrK0
-----END PGP SIGNATURE-----

--BlUg4XxkkztRWbUc1rk90Z43y1QYQfGy7--