Re: Incorrect alias expansion within command substitution

[Alex fxmbsw7 Ratchev]

aliases are the way not to write duplicate code

On Thu, Feb 3, 2022, 18:06 L A Walsh <bash@tlinx.org> wrote:

>
>
> 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
>
>