Re: Memory leak in wait

[Dave Rutherford]

On Mon, Mar 2, 2015 at 2:33 AM, Jean Delvare  wrote:
> Which brings another question: is there any plan to implement sleep as
> a bash builtin?

It's already available as a loadable builtin (examples/loadables/sleep.c).

Re: Memory leak in wait

[Jean Delvare]

Hi Dave,

On Mon, 2 Mar 2015 04:38:43 -0500, Dave Rutherford wrote:
> On Mon, Mar 2, 2015 at 2:33 AM, Jean Delvare  wrote:
> > Which brings another question: is there any plan to implement sleep as
> > a bash builtin?
> 
> It's already available as a loadable builtin (examples/loadables/sleep.c).

Very nice, thanks a lot for the pointer, I was totally unaware of this
mechanism and code. This should improve the performance of a number
of my scripts significantly.

Maybe a better integration into the ./configure script would help
improve the visibility of this code?

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: certain strings both legal and illegal as associative array keys

[Greg Wooledge]

On Sun, Mar 01, 2015 at 12:05:53AM -0600, vampyre...@gmail.com wrote:
> A string is either legal or not legal as a key for an associative array.
> However, bash accepts certain keys in some contexts but not in other
> contexts, 

It's all about the quoting.

> #!/bin/bash
> 
> declare -A foo
> 
> foo[a]="one"
> foo["a'b"]="two"
> 
> echo "${foo[@]}"

That's all correct so far.  (Note, however, "declare -p foo" is much
better for showing you the contents of a variable, especially an array.)

> echo ${foo[a]}
> echo ${foo["a'b"]}

Missing quotes.  VERY bad.

imadev:~$ echo "${foo[a]}"
one
imadev:~$ echo "${foo["a'b"]}"
two

> unset foo[a]
> unset foo["a'b"]

Again, missing quotes.  If you have a file named "fooa" in the current
working directory, the first one expands to "unset fooa".  You don't want
that.

imadev:~$ unset "foo[a]"

Now, the second one is MUCH harder.  Your best bet is to store the
index in a variable instead of trying to deal with multiple levels
of quoting in the same argument.

imadev:~$ i="a'b"
imadev:~$ unset 'foo[$i]'
imadev:~$ declare -p foo
declare -A foo='()'

Re: [Bug-readline] Problem with CTRL-z and readline()

[Hans Lub]

2015-03-02 10:47 GMT+01:00 Hans Lub :

> and defers the restoring until after wakeup (cf signals.c
> ).
>

Now I realize that rlwrap doesn't restore terminal attributes after a
SIGTSTP, and will leave them modified when killed by a fatal signal, so
this is no better than not restoring the terminal al all.

H

-- 
Hans Lub +31 (0)30 2899249
Dolomieten 74 3524 VH Utrecht (Nederland)  hanslu...@gmail.com

Re: [Bug-readline] Problem with CTRL-z and readline()

[Hans Lub]

2015-03-02 2:14 GMT+01:00 Chet Ramey :

> Any ideas are welcome.
>

I have never thought very deeply about this, but rlwrap (which uses the
alternate interface and has its own signal handlers) remains suspended in
the SIGTSTP signal handler (by resetting the SIGTSTP disposition and then
sending a SIGTSTP to itself)  and defers the restoring until after wakeup
(cf signals.c
).

Yes, it's a bit of a hack, and rlwrap is very careless about any non-fatal
signal (other than SIGCONT) that could arrive while it is suspendend, but I
think these could be handled as well.

regards

Hans


-- 
Hans Lub +31 (0)30 2899249
Dolomieten 74 3524 VH Utrecht (Nederland)  hanslu...@gmail.com

Re: [Bug-readline] Problem with CTRL-z and readline()

[Dave Wysochanski]

On Sun, 2015-03-01 at 20:14 -0500, Chet Ramey wrote:
> On 2/27/15 12:10 PM, Dave Anderson wrote:
> > 
> > This issue was first reported with respect to the crash utility,
> > which is an interactive program that uses the readline library.  
> > 
> > The problem occurs only if the crash utility is run from within 
> > an executable bash script, i.e., like so:
> > 
> >   $ cat doit
> >   crash
> >   $
> > 
> > If crash is invoked as above, the crash utility does its initialization
> > and eventually calls readline().  Then, if CTRL-z is entered, the parent 
> > bash shell itself is blocked, but the crash utility spins at 100% cpu usage.
> > Debugging it shows that the crash utility is stuck spinning in the readline
> > libary's _set_tty_settings() function, where the tcsetattr() call repeatedly
> > fails with an EINTR, where _rl_caught_signal contains SIGTTOU.  
> > 
> > But taking the crash utility out of the picture, I can reproduce it with
> > readline-6.3.tar.gz, where I simply build it with "configure; make", then 
> > go into the examples subdirectory, and enter "make".  If I then put the
> > simple "rl" command in script file, and do the same thing, this happens:
> > 
> >   $ cat doit
> >   ./rl
> >   $ ./doit
> >   readline$ ^Z
> >   [1]+  Stopped ./doit
> >   $
> >   $ top
> >   top - 12:02:33 up 23:12,  5 users,  load average: 0.37, 0.09, 0.04
> >   Tasks: 159 total,   2 running, 154 sleeping,   3 stopped,   0 zombie
> >   Cpu(s):  3.4%us, 21.6%sy,  0.0%ni, 75.0%id,  0.0%wa,  0.0%hi,  0.0%si,  
> > 0.0%st
> >   Mem:   3917056k total,  3709052k used,   208004k free,88732k buffers
> >   Swap:  4063228k total,0k used,  4063228k free,  3049316k cached
> >   
> > PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  
> > 
> >   12336 root  20   0  100m 1016  788 R 100.0  0.0   1:12.13 rl
> >   1 root  20   0 19356 1532 1216 S  0.0  0.0   0:02.89 init
> >   2 root  20   0 000 S  0.0  0.0   0:00.02 kthreadd
> >   3 root  RT   0 000 S  0.0  0.0   0:00.19 migration/0
> >   ...
> > 
> >
> > If I attach gdb to the rl process above, it shows the same ultimate trace as
> > the spinning crash utility does:
> > 
> >   # gdb -p 12336
> >   GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
> >   Copyright (C) 2010 Free Software Foundation, Inc.
> >   License GPLv3+: GNU GPL version 3 or later 
> > 
> >   This is free software: you are free to change and redistribute it.
> >   There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> >   and "show warranty" for details.
> >   This GDB was configured as "x86_64-redhat-linux-gnu".
> >   For bug reporting instructions, please see:
> >   .
> >   Attaching to process 12336
> >   Reading symbols from /root/readline-6.3/examples/rl...done.
> >   Reading symbols from /lib64/libtinfo.so.5...Reading symbols from 
> > /usr/lib/debug/lib64/libtinfo.so.5.7.debug...done.
> >   done.
> >   Loaded symbols for /lib64/libtinfo.so.5
> >   Reading symbols from /lib64/libc.so.6...Reading symbols from 
> > /usr/lib/debug/lib64/libc-2.12.so.debug...done.
> >   done.
> >   Loaded symbols for /lib64/libc.so.6
> >   Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
> > /usr/lib/debug/lib64/ld-2.12.so.debug...done.
> >   done.
> >   Loaded symbols for /lib64/ld-linux-x86-64.so.2
> >   0x0033f52dff48 in tcsetattr (fd=0, optional_actions= > out>, termios_p=0x62cb60)
> >   at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
> >   84  retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
> >   (gdb) bt
> >   #0  0x0033f52dff48 in tcsetattr (fd=0, optional_actions= > optimized out>, termios_p=0x62cb60)
> >   at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
> >   #1  0x00406f8d in _set_tty_settings (tty=0, tiop=0x62cb60) at 
> > rltty.c:476
> >   #2  0x00406fe3 in set_tty_settings (tty=, 
> > tiop=) at rltty.c:490
> >   #3  0x004072d0 in rl_deprep_terminal () at rltty.c:688
> >   #4  0x00413352 in rl_cleanup_after_signal () at signals.c:536
> >   #5  0x00413731 in _rl_handle_signal (sig=20) at signals.c:232
> >   #6  0x004137e5 in _rl_signal_handler (sig=) 
> > at signals.c:155
> >   #7  0x00415575 in rl_getc (stream=0x33f558e6c0) at input.c:480
> >   #8  0x00415a60 in rl_read_key () at input.c:462
> >   #9  0x0040340d in readline_internal_char () at readline.c:564
> >   #10 0x004037d3 in readline_internal_charloop (prompt= > optimized out>) at readline.c:629
> >   #11 readline_internal (prompt=) at readline.c:643
> >   #12 readline (prompt=) at readline.c:369
> >   #13 0x004025b6 in main (argc=1, argv=0x7fff0af285d8) at rl.c:149
> >   (gdb) 
> >   (gdb) c
> >   Continuing.
> >   
> >   Program received signal SIGTTOU,

Re: certain strings both legal and illegal as associative array keys

[vampyrebat]

Thank you, Greg, for the quick, helpful response.

> Your best bet is to store the
> index in a variable instead of trying to deal with multiple levels
> of quoting in the same argument.

In the script where this problem arose, the index is indeed stored in a 
variable, and I tried various ways of quoting it.

> imadev:~$ i="a'b"
> imadev:~$ unset 'foo[$i]'

However, I did not try that way, because -- according to the bash documentation 
-- it shouldn't work.  Single quotes should prevent the expansion of $i.  Even 
knowing now that this does work, I can't find where this exception to 
single-quote behavior is documented.