bug-bash
[Top][All Lists]
Advanced

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

Re: Incorrect alias expansion within command substitution


From: Alex fxmbsw7 Ratchev
Subject: Re: Incorrect alias expansion within command substitution
Date: Thu, 3 Feb 2022 22:37:47 +0100

btw u just need a two teee's there
one l.int local int ome g.int for with -g
and the setting for non g may not be a function

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

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