Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15116 > unrolled thread

Re: alias problem -- conflict found

Started byGreg Wooledge <wooledg@eeg.ccf.org>
First post2019-07-10 09:37 -0400
Last post2019-07-10 09:37 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: alias problem -- conflict found Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-10 09:37 -0400

#15116 — Re: alias problem -- conflict found

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2019-07-10 09:37 -0400
SubjectRe: alias problem -- conflict found
Message-ID<mailman.821.1562765913.2688.bug-bash@gnu.org>
On Tue, Jul 09, 2019 at 08:24:30PM -0700, L A Walsh wrote:
> > On Mon, Jul 08, 2019 at 03:30:47PM -0700, L A Walsh wrote:
> >> alias my='declare ' Export='\-x '  Map='-A '   Int='-i '

>     All of them are shorter than their original forms

By what metric is "Export" shorter than "-x", or "Map" shorter than "-A",
or "Int" shorter than "-i"?  Certainly not character or byte counts.  Nor
keystrokes.

> and are easier
> to type and read.

Only to YOU, because you have developed this completely unique coding
style and have been using it for years.

To anyone else, it is completely opaque.  Not least because it relies
on an extremely peculiar, little-known "feature" of aliases (that putting
a trailing space in one alias affects how a different alias works -- come
on, seriously, WHO COULD POSSIBLY EXPECT THAT?!).

Also not least because aliases are not even ENABLED by default in scripts,
so you first have to turn them on.  Which adds even more length and
complexity to your code -- but you didn't bother to factor that in,
did you.

But the real issue here, as I have told you many times already, is that
you are trying to dress up one language to look like a different language.
I've been down this road before.  It does NOT lead to a good place.

In your case, you are trying to dress up bash to look like perl.  You
are trying to HIDE bash's warts and peculiarities behind a veneer of
perl syntax, because obviously you are a perl programmer and you would
like bash to look more like perl.

The problems with this are at least two:

1) You hide all of the things that make bash bash.  This includes both
   the flaws and the benefits.  You've taken away all the bash-ness.
   If there's something that bash can do really well, you won't be
   allowed to see it, because you've tossed the whole bash feature set
   into the oubliette.  Every common bash idiom?  Gone.  You won't ever
   use it, you won't understand it when you see it in someone else's
   script, you won't even know that there *is* an idiomatic way to do
   whatever you're doing.

2) Instead of one layer of syntax to debug, now there are THREE layers
   of syntax to debug, when an inevitable problem occurs.  The first
   layer is the actual bash code, which is not even directly visible --
   it's generated on the fly by a series of alias expansions.  The second
   layer is this strange interface of aliases that you've hand-crafted,
   with who knows how many bugs in it.  The third layer is your private
   artisanal pseudo-language, this perl-like syntax that you are
   writing in, on top of your custom aliasing API, on top of bash.

I'm sure I could come up with more, and I probably have done so in the
past, and you have probably already ignored my past advice, and you will
probably continue to ignore my present advice.

Thus, dead horse, beating.

Maybe someone else out there is reading and will learn from this.  That's
my only hope at this point.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web