dash's read() builtin seems to read the underlying file 1 char at a time. This doesn't work with some files under /proc, since procfs isn't fully POSIX compliant. With bash it works : $ bash -c 'read MAX < /proc/sys/kernel/pid_max; ec 32768 With dash it only reads the first character : $ dash -c 'read MAX < /proc/sys/kernel/pid_max; ec 3 If we use the cat(1) external program it works : $ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX' 32768 After a little digging, it only appears on files that contains just an integer value. When asked to read with a non-null offset (*ppos != 0), __do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [1]. [1] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371 I'm aware that the issue isn't strictly a dash one, since it has the right to read one character at a time. But since fixing procfs to be conforming to POSIX isn't a realistic option, would it be possible to have a workaround that doesn't involve an external tool like cat(1) ?
tags 595063 + upstream quit Hi Steve, Steve Schnepp wrote: Could you report this upstream? The address is dash@vger.kernel.org (no need to subscribe; the convention is to always reply-to-all there). Realistically, the phenomenon will only get fixed if someone suggests a patch. :) It really is possible that the best place to fix this is in the kernel. It comes down to what is simplest. Thanks for the report, Jonathan
Hi, I opened bug 595063 on the debian BTS [1] and I was suggested to resend the email upstream. So I copied the body of the bug below : dash's read() builtin seems to read the underlying file 1 char at a time. This doesn't work with some files under /proc, since procfs isn't fully POSIX compliant. With bash it works : $ bash -c 'read MAX < /proc/sys/kernel/pid_max; echo $MAX' 32768 With dash it only reads the first character : $ dash -c 'read MAX < /proc/sys/kernel/pid_max; echo $MAX' 3 If we use the cat(1) external program it works : $ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX' 32768 After a little digging, it only appears on files that contains just an integer value. When asked to read with a non-null offset (*ppos != 0), __do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [2]. I'm aware that the issue isn't strictly a dash one, since it has the right to read one character at a time. But since fixing procfs to be conforming to POSIX isn't a realistic option, would it be possible to have a workaround that doesn't involve an external tool like cat(1) ? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063 [2] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371
Hi, I opened bug 595063 on the debian BTS [1] and I was suggested to resend the email upstream. So I copied the body of the bug below : dash's read() builtin seems to read the underlying file 1 char at a time. This doesn't work with some files under /proc, since procfs isn't fully POSIX compliant. With bash it works : $ bash -c 'read MAX < /proc/sys/kernel/pid_max; echo $MAX' 32768 With dash it only reads the first character : $ dash -c 'read MAX < /proc/sys/kernel/pid_max; echo $MAX' 3 If we use the cat(1) external program it works : $ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX' 32768 After a little digging, it only appears on files that contains just an integer value. When asked to read with a non-null offset (*ppos != 0), __do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [2]. I'm aware that the issue isn't strictly a dash one, since it has the right to read one character at a time. But since fixing procfs to be conforming to POSIX isn't a realistic option, would it be possible to have a workaround that doesn't involve an external tool like cat(1) ? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063 [2] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371 -- Steve Schnepp http://blog.pwkf.org/
2010/9/1 Steve Schnepp <steve.schnepp@gmail.com>: Feel free to reply with your comments. NB: I just targeted dash-0.5.5.1, but it might apply to any version.
Given that other files in /proc do work, I don't see why the ones that only contain an integer value cannot be fixed. All the necessary state to produce the second and further bytes is available. Choosing a powerful abstraction like a regular file has its implications. Note that a change in the file between the single-byte reads will cause an inconsistent value to be read. This is also the case with regular files on a filesystem, so it is acceptable. If single-byte reads are really unacceptable, then the proper way to read these files needs to be documented, and clear violations that will not work properly should cause an error (in this case, this means that reading one byte from offset 0 should fail like reading one byte from offset 1 does).
2010/9/2 Jilles Tjoelker <jilles@stack.nl>: Thanks for your prompt reply. - if the procfs is made to support char per char reads, dash reading an inconsistent value is actually a feature ? - buffering should, therefore, always be explicit ? On a side note, the whole procfs seems to be designed around one unique page read if possible (1x 4K). I think it does so in order to be able to vastly simplify its usage/implementation by kernel modules. +1 for "the proper way to read these files needs to be documented" and I also think that emitting an error would be better than silently returning erroneous data. [ EOVERFLOW is coming to my mind ]
This patch assumes that the file descriptor is discarded afterwards (its
position does not matter). Therefore the very common construct
while read x; do
...
done
stops working.
A possible fix is to check first if the input supports seeking. If it
does, use the buffering and at the end of the line seek backwards for
the number of bytes remaining in the buffer. If it does not, read one
byte at a time.
2010/9/3 Jilles Tjoelker <jilles@stack.nl>:
Ohh.. thanks for that, I didn't see it.
Actually "while read x" continues to work.
But "reopening the file" doesn't as in :
read a b < datafile
echo ${a} ${b}
read a b < datafile
echo ${a} ${b}
I attached an updated patch that corrects this pb by discarding the
buffer when opening a new file.
I also put everything in new files (bufreadcmd.c & .h), in order to
ease its understanding.
You're right, it's even stranger than I expected. file description is shared. This happens if stdin is redirected inside a while read... loop. Furthermore, I think constructions like read x; cat and read x; (read y); read z should keep working. This requires that the input's file position be synced whenever another process may see it (fork/exit). Due to the highly dynamic character of the shell and the common use of fd 0, this probably means that you can't do better than syncing after each read builtin. (For example, 'read' could be overridden with a function after the third line.) Another thought: exec 3<&0; read x; read y <&3 or even sh -c 'read x; read y <&3' 3<&0 Different file descriptors may refer to the same open file description and the shell may not know this.
I'm with Jilles on this. I also don't particularly feel like bloating dash just because of the borked /proc interface when there is a perfectly adequate work-around in "cat". value=$(cat /proc/file) Cheers,
I wouldn't call that "a perfectly adequate work-around", but a painful and unadequate work-around. And this example will hopefully show why: $ dash -c 'loops=10000; while [ $loops -gt 0 ];do read MAX </proc/sys/kernel/pid_max; loops=$(($loops - 1)); done; times' 0m0.180000s 0m0.100000s 0m0.000000s 0m0.000000s total: 0.28s $ dash -c 'loops=10000; while [ $loops -gt 0 ];do MAX=$(cat /proc/sys/kernel/pid_max); loops=$(($loops - 1)); done; times' 0m0.280000s 0m1.330000s 0m3.840000s 0m1.560000s total: 7.01s That is, the first example is 24x more efficient than the second. And that realy _matters_, I would say. Cheers,
Hi Cristian, Cristian Ionescu-Idbohrn wrote: For what it's worth, here's what bash does (based on strace): 1. Determine whether the file is seekable. That is, seek using SEEK_CUR with offset 0. 2. If seekable, read a nice big chunk and then seek back to put the file offset back in the right place. If not seekable, read one byte at a time. This works in /proc because files in /proc are seekable. That said, I don't think borked /proc is a great reason to do this (it's a better reason to fix /proc). Speeding up the read builtin might be a good reason. Regards, Jonathan
Jonathan, Right. So, there are 2 options here. One is to to make dash work like bash on a proc filesystem, the other to "fix" the kernel. How many linux distributions depend on a "working" dash? Which alternative is the more realistic one? What are the ETAs odds? How do we proceed? Cheers,
The optimization is of limited benefit (still way more syscalls than strictly necessary) and does not apply to the common use case of reading from a pipe. Generally, if 'read' is too slow, it is better to spend a fork on a tool like grep, sed or awk which processes large amounts of text much more efficiently. As for value=$(cat /proc/file), there are at least two ways to make this faster. The traditional ksh way is the extension value=$(</proc/file) which is permitted but not required by POSIX. I do not really like this as it makes the scripts not POSIX compliant. In recent mksh I noticed another way: by making cat(1) a builtin under certain circumstances. These circumstances include the absence of options (other than "--") and should probably also exclude foreground commands in interactive job control shells (as builtins cannot be suspended). To avoid needing to implement extensions like FreeBSD cat's ability to read from Unix domain sockets, named files could also be excluded, requiring value=$(cat </proc/file).
tags 595063 - patch clone 595063 -1 retitle -1 dash: build in cat (no arguments case) severity -1 wishlist quit Jilles Tjoelker wrote: [...] I like this idea a lot. Cloning the bug so it isn't forgotten.