[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect alias expansion within command substitution

From: L A Walsh
Subject: Re: Incorrect alias expansion within command substitution
Date: Thu, 03 Feb 2022 12:23:28 -0800
User-agent: Thunderbird

On 2022/02/03 11:02, Chet Ramey wrote:
On 2/2/22 10:18 PM, Robert Elz wrote:
     Date:        Wed, 02 Feb 2022 17:18:08 -0800
     From:        L A Walsh <bash@tlinx.org>
     Message-ID:  <61FB2D50.7010403@tlinx.org>

   | My posix non-conformance issue has to do with bash not starting with
   | aliases enabled by default in all default invocations.

If you're using aliases in scripts, then just stop doing that.
There's no need for it, it just makes your script harder to
follow.  Simply expand any aliases you"d use interactively,
and you will no longer care about this.

There's no problem with using aliases in private scripts you write for your
own purposes.
Going against the POSIX standard in enabling aliases on startup would be no
problem if it was in your private shell for your own purposes...
 If you want to impose some personal style you find easier to
read, so be it. Even advocating for that style is ok, if you don't expect to be 
taken seriously unless you provide evidence of concrete benefits.
   If you want to impose your personal bash startup options on the general
shell used by default on most systems, so be it.  But please don't
expect to be taken seriously when you arbitrarily disable default
posix options at startup unless you provide evidence of concrete benefits.

   In a similar way when one does a 'read var < fn' and you decide to add
a warning if 'fn' ended with a binary '0', that would be fine if it only affected you, but you added the warning claiming it was solving some problem complained about by some users. When I asked for concrete evidence of benefits or the large number of users askign for that, I was attacked. Yet you ask to be taken seriously when
you implement changes that no one had asked for on bug-bash.

The issue is expecting others to understand or be able to help with scripts
written in that style, or expect them to invest time learning it. That's
just not reasonable.

If you are claiming it takes them significant time to learn what:

shopt -s expand_aliases; alias int='declare -i '
means, How do you expect them to learn shell basics from 'man bash'?

More than one person has commented the level of clarity of bash documentation.

I've have yet to find someone who doesn't understand what
'int var=1' means.

Documentation that has confused more than one poster on this list
is hardly a standard one should aspire to.  It is, at best, 'terse'.

versus my alias usage that attempts to improve clarity.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]