Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= <vq@larryv.me>
Newsgroups: gnu.bash.bug
Subject: Re: Return from function depending on number of parameters
Date: Sat, 4 Jul 2020 12:23:45 -0400
Lines: 50
Approved: bug-bash@gnu.org
Message-ID: <mailman.951.1593879834.2574.bug-bash@gnu.org>
References: <b1c19d38-64c0-f1ae-d08a-1ada435a0022@gmail.com> <506AA493-0D79-4A9A-A53E-279FDA72CED5@larryv.me> <0b8f32e5-0644-526e-59a4-1bad5a474262@passchier.net> <ACF6AB75-5321-42EC-805E-D84048F539C9@larryv.me>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bug-bash@gnu.org
To: pepa65 <pepa65@passchier.net>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <0b8f32e5-0644-526e-59a4-1bad5a474262@passchier.net>
Received-SPF: pass client-ip=66.111.4.25; envelope-from=vq@larryv.me; helo=out1-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <ACF6AB75-5321-42EC-805E-D84048F539C9@larryv.me>
X-Mailman-Original-References: <b1c19d38-64c0-f1ae-d08a-1ada435a0022@gmail.com> <506AA493-0D79-4A9A-A53E-279FDA72CED5@larryv.me> <0b8f32e5-0644-526e-59a4-1bad5a474262@passchier.net>
Xref: csiph.com gnu.bash.bug:16538

> On Jul 4, 2020, at 8:12 AM, pepa65 <pepa65@passchier.net> wrote:
>=20
> On 04/07/2020 04.39, Lawrence Vel=C3=A1zquez wrote:
>> It might tell you something that $[...] is not even mentioned in
>> the man page for bash 3.2.57, which is decidedly not the current
>> version.
>=20
> About that, is it for sure that $[] is going to be obsoleted/removed =
in
> the future?

Only Chet knows for sure, but "obsolete" need not mean "removed".
Given how thoroughly it's been memory-holed, $[...] is about as
obsolete as it can get. Removing it would break a lot of old scripts,
though.

> I happened to use it recently

Inadvisable.

> and thought it was more readable than $(()) and caused less visual
> clutter. Any reason $(()) was preferred?

Quoting Chet liberally from
https://lists.gnu.org/archive/html/bug-bash/2012-04/msg00034.html:

> On 4/7/12 4:45 PM, Linda Walsh wrote:
>=20
>> In modifying some released code on my distro,    I ran into the =
extensive use
>> of   $[arith]  as a means for returning arithmetic evaluations of the
>> expression.
>>=20
>> I vaguely remember something like that from years ago, but never see =
any
>> reference to
>> it -- yet it works, and old code seems to rely on it -- and
>> "$[(1+2)/3]"  looks cleaner than "$(((1+2)/3))".  So what's up with =
that?
>=20
> It dates from Posix circa 1990 (1003.2d9, of which I've lost my paper
> copy).  I implemented it after the Berkeley guys, mostly Marc
> Teitelbaum, put it into Posix.  It ended up getting dropped in favor
> of the ksh $((...)) expansion, at which point everyone deprecated the
> old $[...].  I removed it from the manual sometime later, but it still
> works as it always has.


vq=