Re: [PATCH] silent job monitor when 'set +m'
> > Nothing wrong, but can be made more efficient because "| grep" means > > another subprocess which can be eliminated if the shell silents the > > Terminate command in the first place. Then why not try the approach I outlined in the previous message, instead of sticking with something that you don't like? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] silent job monitor when 'set +m'
> oups sorry you want to see the other errors from kill ... Then invoke kill before redirecting stderr. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
4.0 patch 25 breaks older gcc
make[1]: Entering directory `/var/tmp/bash-4.0/lib/glob' rm -f glob.o /net/appl/gcc-3.3/bin/gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I../.. -I../.. -I../../include -I../../lib -DHPUX -g -O2 glob.c glob.c:1026:69: missing terminating ' character make[1]: *** [glob.o] Error 1 make[1]: Leaving directory `/var/tmp/bash-4.0/lib/glob' make: *** [lib/glob/libglob.a] Error 1 The code in question, with patch 25 applied, is: #if 0 /* If we want all directories (dflags & GX_ALLDIRS) and we're not being called recursively as something like `echo **/*.o' Looks like the */ inside the comment is being interpreted by gcc, even though the whole comment's inside an #if 0 block. Breaks with gcc 3.3.5 on HP-UX 10.20, though I'm informed that gcc 4.3 simply gives a warning.
siglist.c missing #include "bashintl.h"
/net/appl/gcc-3.3/bin/gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -ltermcap -lglob -ltilde -lmalloc lib/intl/libintl.a /usr/ccs/bin/ld: Unsatisfied symbols: _ (code) This is due to a missing #include "bashintl.h" in siglist.c.
4.0 core dump from printf -v foo %s bar
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' imadev:/var/tmp/bash-4.0$ bash-4.0.10 -c 'printf -v foo %s bar' Segmentation fault (core dumped) imadev:/var/tmp/bash-4.0$ ./bash --version | head -1 GNU bash, version 4.0.35(2)-release (hppa2.0-hp-hpux10.20) imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo bar' imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo %s bar' Segmentation fault (core dumped) I looked into printf.def using gdb, but I only partially understand what's happening. I don't understand why this works on other platforms but fails on HP-UX 10.20, but maybe that's my ignorance In the "printf -v foo bar" case, there's no format specifier with a percent sign. So, even though the vbuf variable is never initialized beforehand, the first macro that it calls is PC, which calls vbadd, which allocates space for vbuf. In the "printf -v foo %s bar" case, vbuf is still not initialized, but the first macro that gets called is PF. PF calls vbprintf, which calls vsnprintf (vbuf + vblen, ) but vbuf is still NULL. If my understanding is correct, the vbprintf function either needs to do the nlen vs. vbsize check before calling vsnprintf(vbuf+...), or it needs to call vsnprintf with a locally allocated buffer first, and then copy the result into vbuf once it's been resized. I have no idea how "printf -v foo %s bar" works on other platforms, given what appears (to me) to be a dereferenced NULL or nearly-NULL pointer.
read + ^V
using ^V to pass an ascii character to read, the behavior is incoherent beetween simple read, and read -nx $ read ^V^A $ hd <(echo -n $REPLY) 01|.| 0001 $ read -n1 ^V $ hd <(echo -n $REPLY) 16|.| 0001 $ read -n2 ^V^A (30)[armada:xterm0]/home/user1 $ hd <(echo -n $REPLY) 16 01 |..| 0002 I'm on bash 3.2.39 so forgive me if in your new bash this "problem" does not arise bye
qwerty
$ printf "%s\n" ok - ok - why that score in the newline? $ printf "%d %s\n" 1 ok - 1 ok -bash: printf: -: invalid number 0 why getting error here, and not in the previous? why "invalid number" ? what is that zero? $ printf "%2s\n" qwerty qwerty strings larger than fixed-width are entire written? I'm using BASH_VERSION 3.2.39, so please forgive me if this issue are already fixed and thanks for your great job bye
Re: qwerty
On Thu, Nov 12, 2009 at 01:47:52AM +0100, Antonio Macchi wrote:
> $ printf "%s\n" ok -
> ok
> -
>
> why that score in the newline?
Your pattern has one format operator, but there are two arguments,
so the pattern is applied again.
>
>
> $ printf "%d %s\n" 1 ok -
> 1 ok
> -bash: printf: -: invalid number
> 0
>
> why getting error here, and not in the previous?
> why "invalid number" ?
> what is that zero?
Again, you have more arguments than operators, so it makes another pass,
and on the second pass tries to format - as a number... Don't know
about the zero, but I guess %d maybe starts with a default of 0...?
>
>
> $ printf "%2s\n" qwerty
> qwerty
>
> strings larger than fixed-width are entire written?
It's not fixed width but minimum width.
> I'm using BASH_VERSION 3.2.39, so please forgive me if this issue are
> already fixed
There's nothing to fix. It might help if you provide some markers
in your test patterns so you can see where each argument begins and
ends, e.g.,
$ printf "(%d) {%s}\n" 1 ok -
(1) {ok}
-bash: printf: -: invalid number
(0) {}
Ken
--
Ken Irving, fn...@uaf.edu, 907-474-6152
Water and Environmental Research Center
Institute of Northern Engineering
University of Alaska, Fairbanks
Re: qwerty
There's nothing to fix. It might help if you provide some markers
sorry, and thanks for your patience...
in your test patterns so you can see where each argument begins and
ends, e.g.,
$ printf "(%d) {%s}\n" 1 ok -
(1) {ok}
-bash: printf: -: invalid number
(0) {}
... and for your trick!
bye
Re: qwerty
Ken Irving wrote: >> $ printf "%d %s\n" 1 ok - >> 1 ok >> -bash: printf: -: invalid number >> 0 >> >> why getting error here, and not in the previous? >> why "invalid number" ? >> what is that zero? > > Again, you have more arguments than operators, so it makes another pass, > and on the second pass tries to format - as a number... Don't know > about the zero, but I guess %d maybe starts with a default of 0...? When bash detects an integer conversion error, it returns 0. That's not strictly Posix-conformat, so the next version of bash will return whatever strtoimax/strtoll/strtol returns, which is supposed to be the value accumulated up to the point of the error. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: 4.0 core dump from printf -v foo %s b
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-4.0.10 -c 'printf -v foo bar' > imadev:/var/tmp/bash-4.0$ bash-4.0.10 -c 'printf -v foo %s bar' > Segmentation fault (core dumped) > imadev:/var/tmp/bash-4.0$ ./bash --version | head -1 > GNU bash, version 4.0.35(2)-release (hppa2.0-hp-hpux10.20) > imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo bar' > imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo %s bar' > Segmentation fault (core dumped) > > I looked into printf.def using gdb, but I only partially understand > what's happening. I don't understand why this works on other platforms > but fails on HP-UX 10.20, but maybe that's my ignorance The behavior depends on the behavior of vsnprintf. > > In the "printf -v foo bar" case, there's no format specifier with a > percent sign. So, even though the vbuf variable is never initialized > beforehand, the first macro that it calls is PC, which calls vbadd, > which allocates space for vbuf. > > In the "printf -v foo %s bar" case, vbuf is still not initialized, > but the first macro that gets called is PF. PF calls vbprintf, which > calls vsnprintf (vbuf + vblen, ) but vbuf is still NULL. > > If my understanding is correct, the vbprintf function either needs to > do the nlen vs. vbsize check before calling vsnprintf(vbuf+...), or > it needs to call vsnprintf with a locally allocated buffer first, and > then copy the result into vbuf once it's been resized. This is where the behavior depends on vsnprintf. The idea is that you pass vsnprintf the currently-allocated size of vbuf (vbsize) less what you've already written (vblen) as its `len' argument. That's the number of characters currently available in the buffer. vsnprintf is guaranteed to write no more than that number of characters to the buffer that's passed, and in addition to return the number of character that would have been written if the `len' argument had been large enough. Once you find out how many characters you need, you make sure the buffer is big enough and go on. So far, so good. Since the `len' argument in your example is 0, vsnprintf should write no characters into the buffer and return the number of characters that would have been required. The check performs as desired, the buffer is allocated, and the vsnprintf is called again with the appropriately-sized buffer. 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: read + ^V
Antonio Macchi wrote: > using ^V to pass an ascii character to read, the behavior is incoherent > beetween simple read, and read -nx When using the -n option, bash puts the terminal into character-at-a-time non-canonical mode, which disables the tty special characters. When using read without that option, the terminal stays in canonical mode and does erase, kill, and literal-next processing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
