Re: Question on /proc API & bug in sysctl

Matthias Urlichs (smurf@smurf.noris.de)
Sun, 24 Mar 1996 11:03:14 +0100

In linux.dev.kernel, article <01I2OL6RQ582001FY2@VAX1.ROCKHURST.EDU>,
Aaron Ucko <UCKO@vax1.rockhurst.edu> writes:
> >
> >The reason for this behaviour is that most /proc entries do NOT supp=
ort
> >lseek().=20
>=20
> Therefore the bug is in dd and not in the kernel: if dd finds that ls=
eek
> fails with such-and-such an error, it should just read the specified =
amount
> of data itself and ignore it.
>=20
The bug is in the kernel, since the lseek() in question DOES NOT return=
an
error. Anyway, being able to read stuff in more than one chunk is essen=
tial
if you want to use files in /proc with shell scripts (the shell reads b=
y
one character until it finds a newline, for things like "read xyzzy").

It might also be a good idea to advertise a file length > 0, so that
utilities which actually check the length of a file before reading it (=
like
"less") work on /proc. Why not set the "length" of every file in /proc =
to
4096? You can't actually read that much, of course, but any program tha=
t
can't deal with files which suddenly get shorter is broken anyway. Back=
up
utilities excluded, of course, but you don't backup /proc anyway. ;-)

--=20
I remember your name perfectly, but I just can't think of your face.
--=20
Matthias Urlichs \ XLink-POP N=FCrnberg | EMail: urlichs@smurf.=
noris.de
Schleiermacherstra=DFe 12 \ Unix+Linux+Mac | Phone: ...please use =
email.
90491 N=FCrnberg (Germany) \ Consulting+Networking+Programming+etc'i=
ng 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE=20
Click <A HREF=3D"http://smurf.noris.de/~smurf/finger">here</A>.