On Mon, Apr 19, 2021 at 01:16:48AM -0400, Grisha Levit wrote:
> I think you can do something similar to the patch directly in the shell by
> temporarily unsetting HISTFILE and then deleting history entries in a
> certain range and restoring HISTFILE when you are ready
I still think my solution fit
$ e哈=1
bash: e哈=1: command not found
OK, but on man bash is it ever mentioned that a variable name must be all ASCII?
ENVIRONMENT
When a program is invoked it is given an array of strings called the
environment. This is a list of name-value pairs, of the form
nam
What a 'name' is, is further defined under "Definitions": "name: A word
consisting solely of letters, numbers, and underscores, ..."
But it seems you're right that it doesn't say the locale's idea of letters
isn't taken into account. Some other shells do accept those.
On Mon, Apr 19, 2021 at 4:28
On Mon, Apr 19, 2021 at 08:28:54PM +0800, 積丹尼 Dan Jacobson wrote:
> $ e哈=1
> bash: e哈=1: command not found
> OK, but on man bash is it ever mentioned that a variable name must be all
> ASCII?
>
> ENVIRONMENT
>When a program is invoked it is given an array of strings called the
>
On 4/19/21 8:28 AM, 積丹尼 Dan Jacobson wrote:
$ e哈=1
bash: e哈=1: command not found
OK, but on man bash is it ever mentioned that a variable name must be all ASCII?
name A word consisting only of alphanumeric characters and under-
scores, and beginning with an alphabetic character or
On 4/18/21 7:12 PM, Ananth Chellappa wrote:
Chet, Lawrence,
Sincerely appreciate your time. Far as I understand, there is no
way to accomplish what I want - concisely : *get a true private mode* (no
logging to HISTFILE *OR* recall with history command after exiting
private-mode (togg
Attached patch demonstrates a solution that solves the current issues
of unset discussed in
https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html
while avoiding breakage of scripts and keeping the expansion of
subscripts consistent with expansion in references.
The patched code is also
I looked at this code plenty of times and I really think the returned
value to expand_assignment_string_to_string (v, 0) needs to be freed
too when aval != 0.
diff --git a/arrayfunc.c b/arrayfunc.c
index 8231ba1e..48c43294 100644
--- a/arrayfunc.c
+++ b/arrayfunc.c
@@ -568,8 +568,6 @@ assign_assoc
> On Apr 19, 2021, at 7:18 AM, Greg Wooledge wrote:
>
> On Mon, Apr 19, 2021 at 01:16:48AM -0400, Grisha Levit wrote:
>> I think you can do something similar to the patch directly in the shell by
>> temporarily unsetting HISTFILE and then deleting history entries in a
>> certain range and restori
2021年4月20日(火) 0:16 konsolebox :
> Attached patch demonstrates a solution that solves the current issues
> of unset discussed in
> https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html
> while avoiding breakage of scripts and keeping the expansion of
> subscripts consistent with expansio
On Mon, Apr 19, 2021 at 11:27:13PM +0800, konsolebox wrote:
> I looked at this code plenty of times and I really think the returned
> value to expand_assignment_string_to_string (v, 0) needs to be freed
> too when aval != 0.
>
> ...
The patch seems to be correct.
Moreover, I think that the line
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix6.1.9.0
Compiler: gcc -maix64
Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security
uname output: AIX aixutil07 2 7 00C07A304B00
Machine Type: powerpc-ibm-aix6.1.9.0
Bash Version: 5.0
Patch Level: 18
On 4/19/21 11:27 AM, konsolebox wrote:
I looked at this code plenty of times and I really think the returned
value to expand_assignment_string_to_string (v, 0) needs to be freed
too when aval != 0.
Thanks for the report. I think you're right.
Chet
--
``The lyf so short, the craft so long to l
On 4/19/21 3:48 PM, Mike Whitton wrote:
Bash Version: 5.0
Patch Level: 18
Release Status: release
Description:
I have a script that I wrote in bash and have been using for
years. It worked fine up until I updated bash to the latest version from
IBM, 5.0 Patch 18. Previously I ran it
On 4/19/21 3:22 PM, Mike Jonkmans wrote:
On Mon, Apr 19, 2021 at 11:27:13PM +0800, konsolebox wrote:
I looked at this code plenty of times and I really think the returned
value to expand_assignment_string_to_string (v, 0) needs to be freed
too when aval != 0.
...
The patch seems to be correct
On Tue, Apr 20, 2021 at 2:08 AM Koichi Murase wrote:
> AFAIK `1 << 31' causes undefined behavior when int is 32-bit signed
> integer. Instead, I think you may write `(int)(1u << 31)' for
> conforming C compilers. `u << 31' is defined for unsigned integers,
> and the conversion between signed and
2021年4月20日(火) 9:14 konsolebox :
> On Tue, Apr 20, 2021 at 2:08 AM Koichi Murase wrote:
> > AFAIK `1 << 31' causes undefined behavior when int is 32-bit signed
> > integer. Instead, I think you may write `(int)(1u << 31)' for
> > conforming C compilers. `u << 31' is defined for unsigned integers,
On Tue, Apr 20, 2021 at 9:35 AM Koichi Murase wrote:
> In addition, you need to change `1 << 31' to `1u << 31'. The literal
> `1' has the type `(signed) int'. One needs to use `1u'---the literal
> of the type `unsigned int'.
I see, but I think I'll just skip that as I would also have to modify
18 matches
Mail list logo
