Greg Wooledge writes:
> Perl is a programming language. It makes sense that perl would evolve
> in a way that makes it more useful for writing programs.
>
> Bash, on the other hand, is first and foremost a *shell*. It's designed
> to act as an interface for executing commands, either interactive
On Thu, Apr 30, 2020 at 10:43:53PM -0400, Dale R. Worley wrote:
> This is a common issue in language design. The Perl language originally
> only had "local" declarations that behaved the same way as bash local
> declarations. But the above behavior got to be so much of a problem for
> large progr
>>> f() { local x=a; }
>>> declare -r x
>>> f # bash: local: x: readonly variable
>>>
>>> This^^^ should not fail; it hinders reusability of shell functions and
>>> makes
>>> them context-dependent.
It's "natural" to think that a variable that is local to a function
should be ind
On 4/28/20 2:28 PM, Greg Wooledge wrote:
> On Tue, Apr 28, 2020 at 08:14:28PM +0200, andrej--- via Bug reports for the
> GNU Bourne Again SHell wrote:
>> f() { local x=a; }
>> declare -r x
>> f # bash: local: x: readonly variable
>>
>> This^^^ should not fail; it hinders reusability
On Tue, Apr 28, 2020 at 08:14:28PM +0200, andrej--- via Bug reports for the GNU
Bourne Again SHell wrote:
> f() { local x=a; }
> declare -r x
> f # bash: local: x: readonly variable
>
> This^^^ should not fail; it hinders reusability of shell functions and makes
> them context-de
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/ba
