Re: Passing variables by reference conflicts with local
On Monday, April 23, 2012 04:56:09 PM Clark Wang wrote: > On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote: > > It appears that `unset' is capable of traversing down the call-stack and > > ... I reverse engineered most of this behavior a few months ago and wrote a detailed explaination and example here: http://wiki.bash-hackers.org/commands/builtin/unset#scope Hopefully most of that is correct. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [Help-bash] /proc/.../cdrom/info not completely read
On 4/30/12 2:42 AM, humpty wrote:
> hi,
>
> I encounter a problem when I try to read /proc/sys/dev/cdrom/info
>
> whatever method I try, bash doesn't read the whole file
>
> $ file=/proc/sys/dev/cdrom/info
> $ while read line...done <"$file"
> only outputs the first line
>
> $ exec {foo}<"$file"
> $ while read -u line
> outputs about six lines, as does
> $ mapfile -t myArray <"$file"
> and
> $ echo "$(<"$file")"
>
> if I copy "$file" anywhere (say /tmp/) there is no problem any more.
> This happens with BASH 4.2 on Debian, and openSuse (and BASH 3.3.4 on
> archlinux (I've been told))
>
> what could be the reason for such a behaviour?
This came up on one of the Linux distribution bugzilla sites (I think it
was debian). The problem is that lseek is either a no-op or doesn't work
correctly on special files in /proc.
Bash reads 128 characters at a time and uses lseek to move the file pointer
back to the last character `read' consumes. The negative offset to lseek
causes some kind of problem, but it doesn't return an error. When bash
goes back for more, it gets short reads and incomplete data.
It's a kernel bug apparently introduced in 3.2. It doesn't require bash
to test.
(I guess it was debian:
http://lists.debian.org/debian-kernel/2012/02/msg00874.html . The original
report thread is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659499 .)
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: [Help-bash] /proc/.../cdrom/info not completely read
On Mon, Apr 30, 2012 at 09:57:16AM -0400, Chet Ramey wrote:
> Bash reads 128 characters at a time and uses lseek to move the file pointer
> back to the last character `read' consumes. The negative offset to lseek
> causes some kind of problem, but it doesn't return an error. When bash
> goes back for more, it gets short reads and incomplete data.
>
> It's a kernel bug apparently introduced in 3.2. It doesn't require bash
> to test.
>
> (I guess it was debian:
> http://lists.debian.org/debian-kernel/2012/02/msg00874.html . The original
> report thread is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659499 .)
That's... interesting, since I got exactly the same failures on a stock
Debian 6.0 system (bash 4.1.5, kernel 2.6.32-5-686).
Is this something that was broken until kernel 3.0 or 3.1, then fixed
briefly, and then broken again? (I haven't used a Linux 3.x kernel yet.)
Since this fails:
#include
main() {
char s[20];
int n;
while ((n = read(0, s, 20)) > 0) {
write(1, s, n);
}
}
I cannot consider this anything but a kernel bug. Successive reads
from an open file descriptor without any intervening close() or lseek()
should get the full content of the "file". The kernel should be putting
the full set of data into a nonvolatile buffer when such a "file" is
opened, and only releasing that buffer when it's closed.
