[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 09:05:53 -0800
User-agent: Thunderbird

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

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

reply via email to

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