Re: Incorrect alias expansion within command substitution

[L A Walsh]

On 2022/02/03 07:02, Alex fxmbsw7 Ratchev wrote:
> On Thu, Feb 3, 2022, 04:20 Robert Elz <kre@munnari.oz.au 
> <mailto:kre@munnari.oz.au>> wrote:
>
>         Date:        Wed, 02 Feb 2022 17:18:08 -0800
>         From:        L A Walsh <bash@tlinx.org <mailto:bash@tlinx.org>>
>         Message-ID:  <61FB2D50.7010403@tlinx.org
>     <61FB2D50.7010403@tlinx.org">mailto: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.
----
   Uh, No.
> u're tralla
>
>     There's no need for it, it just makes your script harder to
>     follow.  
---
   I write scripts for myself.  aliases make scriptes easier to create
modify and maintain.  You can type 'declare -i x=1', I prefer 'int x=1' 
I find 'declare -xxyz' harder to write, read and parse than 'my', 
'array' 'map'

We aren't talking 100 aliases, but these:
alias my='declare ' int='my -i ' array='my -a ' map='my -A '

are used in nearly all my scripts.

I use functions frequently I start off many of my scripts:
nalias include >& /dev/null
if [[ $(type -t include) != function ]]; then source ~/bin/include; fi
include stdalias

Even though I have an stdalias.shh file, I rarely use the aliases in it 
-- except
for the ones listed above.  It depends on the script, but having aliases
matching types can help in more complex scripts.  I can define something 
with an alias, then check if a parameter matches its 'type'.  my 
Types.shh include file even
includes a builtin-test suite:
>  Types.shh
Types v0.2 include file. Usage (in a script):

include Types

Cmdline options:
-h for this help
-t for self-test

>  Types.shh -t
test01: Define & Identify Basic Types: PASS
test02: define w/aliases+combos+identify: ...
 0. type(myarray)=array                  : PASS
 1. type(mymap)=map                      : PASS
 2. type(myint)=int                      : PASS
 3. type(int_array)=array Int            : PASS
 4. type(int_map)=map Int                : PASS
 5. type(exp_int_array)=array Int Export : PASS
 6. type(exp_int_map)=map Int Export     : PASS
 7. type(low_array)=array Lower          : PASS
 8. type(up_array)=array Upper           : PASS
 9. type(exp_int_const)=int Const Export : PASS

---
The above routines break down type-defining aliases and
I can check that parameters passed to a subroutine are of the right type.
like:
if I had passed something declared with
alias 'int_map' to a function, I can test if it
is a 'map' (hash) with keys that point to integers.

For dual types (like declare -al), I can use
array Lower foo=(...)
>     Simply expand any aliases you"d use interactively,
>     and you will no longer care about this.
---
   Except every time I type or read them, which is sorta the point.

There is no way you can tell me that:
declare var='v'
declare -i ivar=1

are more clear than:

my var='v'
int ivar=1