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, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
