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: Tue, 9 Jul 2019 23:39:46 -0400
Lines: 116
Approved: bug-bash@gnu.org
Message-ID: <mailman.773.1562730008.2688.bug-bash@gnu.org>
References: <5D23C417.5060108@tlinx.org> <20190709132112.GW2450@eeg.ccf.org> <5D255A6E.4060600@tlinx.org> <7530eecd-c1f3-cba4-4058-30bae97c19c9@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d6hRfY2pc9aGKnA3QRxP5RrJv7UrE8oQ1"
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: <5D255A6E.4060600@tlinx.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:15109

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--d6hRfY2pc9aGKnA3QRxP5RrJv7UrE8oQ1
Content-Type: multipart/mixed; boundary="aliQkHNn5hjfVPRyk2k8HzDMyC9z5Tt6z";
 protected-headers="v1"
From: Eli Schwartz <eschwartz@archlinux.org>
To: bug-bash@gnu.org
Message-ID: <7530eecd-c1f3-cba4-4058-30bae97c19c9@archlinux.org>
Subject: Re: alias problem -- conflict found
References: <5D23C417.5060108@tlinx.org> <20190709132112.GW2450@eeg.ccf.org>
 <5D255A6E.4060600@tlinx.org>
In-Reply-To: <5D255A6E.4060600@tlinx.org>

--aliQkHNn5hjfVPRyk2k8HzDMyC9z5Tt6z
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

On 7/9/19 11:24 PM, L A Walsh wrote:
> On 2019/07/09 06:21, Greg Wooledge wrote:
>> On Mon, Jul 08, 2019 at 03:30:47PM -0700, L A Walsh wrote:
>>  =20
>>> alias my=3D'declare ' Export=3D'\-x '  Map=3D'-A '   Int=3D'-i '
>>>    =20
>> Because the dead horse is still equine-shaped, I will beat upon it som=
e
>> more: this is utterly horrible coding and you should stop doing it.
>>  =20
> ----
>     Why?  What makes clarity "horrible".  If someone didn't know shell'=
s
> way of assigning different attributes to 'declare', vs. most languages
> having
> different keywords or variable notations would be more familiar.

I guess the most obvious reason why your clarity is horrible is due to
the fact that it apparently wasn't a very clear type of clarity. You
confused yourself pretty badly by turning bash into typedef hell, and as
a result, neither you nor anyone else had any remote clue what your code
was doing.

>     I rarely use the forms above, with the exception of 'my', since
> it's alot shorter to type 'my' than its expanded form.  The most common=

> ones for me are:
>=20
> my, int, array and map. =20
>=20
>     All of them are shorter than their original forms and are easier
> to type and read.  So what is so horrible about them that it
> should require longer repetitive strings that are not words?

They're easier to type, yes, but they are definitely nowhere near easier
to read. Now in order to know what the code is doing, you not only need
to know bash, you also need to know your own homebrew typedef
specification crudely bolted on.

>     I made a mistake in developing an older program and didn't use
> -u on the front of it.  It did just like you said -- it allowed a progr=
am
> with an undefined variable in it to run in cases where it would have gi=
ven
> the right answer in many or most cases.  However, due to a lack of test=
ing,
> the cases that failed due to that undefined variable were not detected
> by me
> until recently.=20
>=20
>     The '-u' didn't hide something unimportant -- it hid a symptom of a=
n
> error that remained hidden for years.=20

Okay, there's a wild and context-free assertion. I'll just ignore that,
then.

--=20
Eli Schwartz


--aliQkHNn5hjfVPRyk2k8HzDMyC9z5Tt6z--

--d6hRfY2pc9aGKnA3QRxP5RrJv7UrE8oQ1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl0lXgIACgkQhIGKaBmv
SptEIg/9G8koaI5KVmVb+eRRVtPICfRyQ1xwFCJSKCDriy3iW8BJB6siTF4jG8FL
ghqKbSZUGLOoFoDI2yTD8alwjsXtiLG1woc6brPTYWCEbskUC88TypBQC5dMdnyT
UYtDebo9EBVuNCmV8kTDgEUx9tD2fizeJjNMganZ+8AEjlbgQMcgcx8PyukXVV16
PajM0CiDqATdfTtXM4LC+hpgSj1QrdAJvbT+A753uJ+dtv17SMpSeWmt5+MXgJAK
3l3ELUCMj3JFCe/Rs3okipSfM7k9xNszt51JlL20RlMVV0w0y65JBICzthoHQMO1
YRXAGM+M97Y2juWpAOg1Gk6XgMBFFvVPKyz9I1K5NaoE9Ci0HddskD5wE8M8HhjK
Vu7d5Euxs05sUJL2Lv91qjlvjnKxruiAHshAU7hHyMZ5JVzPPAPkCFk/w182Aj9h
3CsLOX7nzW04Kra8FWY1EHpPn6XgrtZSeDTC1LxWmxvF2TA9Lr17mrUDZEQckcBE
mlcs7U3FyUbRL47tetqxGU5NUEJQmr9BglPMYWxfQxS5b2HwCzpZE89UpAX0zEYg
3VMCaNPsJtQGvJMH8PSQazfGQofocvfc2D4Xc9Df4cGTCyV0Wpgu1JFYFKxgWl7j
wKSz0xTXBPReA3htjo2/6mtxi1dUXYTbKHySPQS0w0+RDfI/PS+JAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXSVeAgAKCRDOsWfvtXIr1rNtD/4pIHS0
mkvO5PHGJgMkcn7VkKrDRU/BtF5ddsOMwdYQ+FBDXfeVzRa8qHzeFslT+zkmJ0U6
+n9uom2Gn0880iPx1jwMGZtFIRtY+3TfmNXV18p7Zasd2yjh0qGDR3Yv7NXJs2RS
DL/jq+bFCbfboijYCVAgKOmR1Zgfr0fGP5D/lptlFP45cFQqs3MPZYiCn79PVZAF
D9fb24NBjJBJfsm89wBZfj+HYgP5FJM3iteJI5LSqOKgIY4g/F4LJLyhKQQMAZqZ
IrstWCI4+MrnwsuuC8m7y+L0HcYwE+2LUHmyEP4ug0WlqsG/AHK29uwSsutDQ7J8
eoKq07FXyD1Kay13b4m5IGx/y2tzxOXerdkH4dTpF2Db4melII4GVvp5G2n0msf+
0IxpT6jfthKrfh/0MCzs28GT+lnZwyys4iBhw5Bifhlqs+gdjWyyftPPWLEWh17b
mPCP/e01rrudoIqIFl7eaJ9DiTI4yItQq08h84JFF+67EGd+a5045kesUSuut641
D9lCzdpZVeU/eRROzalMi65CmYdug3ZhpiUjHA+IrVbc9Lr+ss+i0DxqoFcBaqZa
bTdCJNG2vNqopWUTMUhRKgFfaGhXAmoJMT7DOcRjGK8vRUMDJIK3dAK6kg3oyWCW
e9nc6lOCz4oiugbO0dhuozS1WSOnCV0GzzTH/Q==
=smPV
-----END PGP SIGNATURE-----

--d6hRfY2pc9aGKnA3QRxP5RrJv7UrE8oQ1--