On Tue, Jun 09, 2020 at 11:46:22AM -0400, Chet Ramey wrote:
>
> In any event, I believe the changes in the next devel branch push should
> fix these.
Thanks Chet, that explanation made sense.
If i can find the time I will try to test the devel branch.
Regards,
--
Mike Jonkmans
On 6/9/20 5:19 AM, Mike Jonkmans wrote:
> On Mon, Jun 08, 2020 at 08:43:31PM -0400, Chet Ramey wrote:
>>
>> On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote:
>>
>>> Bash Version: 4.4
>>> Patch Level: 20
>>> Release Status: release
>>>
>>&
On Mon, Jun 08, 2020 at 08:43:31PM -0400, Chet Ramey wrote:
>
> On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Description:
> > Got a core dump (segmentation fault)
On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote:
> Bash Version: 4.4
> Patch Level: 20
> Release Status: release
>
> Description:
> Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-.
You tried to redo `.'. The way this happens is you are in command m
-Wall
-Wno-parentheses -Wno-format-security
uname output: Linux sint 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 20
Release Status: release
Description:
Got a core d
> > array_to_key() {
> ># Converts 1 2 3 -> 1,2,3, (comma at the end)
> >printf '%d,' "$@"
> > }
> >
> > multi_store() {
> >local array_name="$1"; shift
> >local value="$1"; shift
> >if unset -v "$array_name"; then
> > declare -A $array_name
>
On 4/27/17 3:56 PM, Vladimir Marek wrote:
> array_to_key() {
># Converts 1 2 3 -> 1,2,3, (comma at the end)
>printf '%d,' "$@"
> }
>
> multi_store() {
>local array_name="$1"; shift
>local value="$1"; shift
>if unset -v "$array_name"; then
> dec
2 ()
00469824 execute_command_internal () + 72c
00469026 execute_command () + 9e
00449f88 reader_loop () + 318
00447f37 main () + e9b
00446f3c ()
Confirmed on linux and solaris. The intention was to create something
similar to famous 'upva
Chet Ramey writes:
> I try to write to the current (well, ten-year-old) standards.
Nothing wrong with that. gnulib has a few macros to detect such
problematic implementations that you could borrow from.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7
On Thu, Nov 12, 2009 at 02:37:58PM -0500, Chet Ramey wrote:
> I try to write to the current (well, ten-year-old) standards. The
> replacement in lib/sh/snprintf.c behaves as C99 specifies; you might try
> using it by #undefing HAVE_VSNPRINTF and HAVE_SNPRINTF in config.h.
Ah, wonderful. I wasted
Andreas Schwab wrote:
> Greg Wooledge writes:
>
>> It doesn't mention a null pointer. The OpenBSD man page does explicitly
>> say the null pointer is allowed if size is zero. The GNU/Linux man page
>> says that SUSv2 and C99 disagree, but that the implementation follows
>> C99 (allowing the nul
Greg Wooledge writes:
> It doesn't mention a null pointer. The OpenBSD man page does explicitly
> say the null pointer is allowed if size is zero. The GNU/Linux man page
> says that SUSv2 and C99 disagree, but that the implementation follows
> C99 (allowing the null pointer when size is 0).
No
On Wed, Nov 11, 2009 at 09:41:29PM -0500, Chet Ramey wrote:
> If your version of vsnprintf doesn't behave like that, I claim it's a
> bug. The Posix and C standards explicitly allow the buffer to be NULL
> if the size argument is 0, and guarantee that no data will be written
> in this case.
Thank
Greg Wooledge wrote:
> The other two messages I sent today were just things I encountered while
> bringing my bash 4.0 up to the current patch level. This is the real
> problem I've been chasing.
>
> imadev:/var/tmp/bash-4.0$ bash-3.1.17 -c 'printf -v foo %s bar'
> imadev:/var/tmp/bash-4.0$ bash-
The other two messages I sent today were just things I encountered while
bringing my bash 4.0 up to the current patch level. This is the real
problem I've been chasing.
imadev:/var/tmp/bash-4.0$ bash-3.1.17 -c 'printf -v foo %s bar'
imadev:/var/tmp/bash-4.0$ bash-4.0.10 -c 'printf -v foo bar'
ima
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
This problem can be fixed by applying part of the update from 2.05a to 2.05b
in
lib/malloc/malloc.c. The relevent sections are as follows:
--- bash-2.05a.orig/lib/malloc/malloc.c 2001-10-04 12:13:16.0 +
+++ bash-2.05a/lib/malloc/malloc.c 2005-06-14 17:19:00.0 +
@@ -2
Configuration Information:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation :
uname output: Linux 2.4.20-31.9 i686
Machine Type: i686-pc-linux-gnu
Bash Version: 2.05a
Patch Level: ?
Release Status: release
Description:
I have seen bash dump core a few times. It is extremely difficult to
18 matches
Mail list logo
