read() builtin doesnt read integer value /proc files (but bashs does)

[Denys Vlasenko]

On Wednesday 15 December 2010 14:12, Cristian Ionescu-Idbohrn wrote:
> On Wed, 15 Dec 2010, Bob Dunlop wrote:
> >
> > Not a fix but a work around:
> >
> > > $ ./busybox ash -c 'read MAX </proc/sys/kernel/pid_max; echo $MAX'
> > > 3
> >
> > $ busybox ash -c 'MAX=$(cat /proc/sys/kernel/pid_max) ; echo $MAX'
> > 32768
> >
> >
> > Files in /proc are generated on the fly.  They can be fussy about how
> > they are read.
> 
> Yes.  Same suggestion as Herbert Xu's, who stated:
> 
> 	'a perfectly adequate work-around in "cat"'
> 
> Unfortunately, that work around is neither perfect nor adequate.  I'd call
> it painful, as:
> 
> 	read MAX </proc/sys/kernel/pid_max
> 
> is so much more efficient (about 25x faster, on my box) than:
> 
> 	MAX=$(cat /proc/sys/kernel/pid_max)
> 
> I hope you noticed, this is a problem _only_ with /proc files holding
> integers >9.  No such problems with files containing strings.

The fix is hard. Consider that read should work properly here:

exec </proc/some/file
read line
cat

If read "reads ahead" 128 bytes, but finds '\n' after 5th byte,
how can it "roll back" so that cat starts reading at the right
position?

-- 
vda