On 30/12/2021 14:52, Bastian Blank wrote:
On Mon, Dec 27, 2021 at 11:31:21PM +0100, Vincent Danjean wrote:On a plain (with more than two bytes) file, the second poll succeed. On /proc/bus/input/devices, the second poll hangs. Note: this is an old behavior. I initially observe it on an embeded system with a 4.1 kernel./proc is no real filesystem. It simply does not support poll, because the output is generated while you are reading it, so it does not know when anything changes. See also https://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux?rq=1 If you want to know about hardware changes, use udev or listen to kernel netlink messages.
I understand that /proc is different. But I'm not monitoring it.
My goal was only to read it totally from a busybox shell with a
"while read" loop to find the eventX associated with the
touchscreen of the e-reader.
And the first read from busybox shell never complete (instead of
returning the first line of the file) due to the fact that
busybox use poll, then read a byte, then use poll again.
Do you think I should reassign this bug to busybox?
Or do you think I'm wrong trying to read the /proc file
from a shell script without to copy it elsewhere before?
Stalling:
busybox sh -c 'while read l ; do echo $l ; done < /proc/bus/input/devices'
Working (but bash is not present on the initial target system):
bash -c 'while read l ; do echo $l ; done < /proc/bus/input/devices'
As workaround, I'm currently using a copy of the file
("busybox cp" works). It should probably also be possible
to get the same kind of info from /sys files but this seems
less easy.
I just saw that other files seems to work:
Ok:
busybox sh -c 'read l < /proc/bus/input/handlers ; echo $l'
Stale:
busybox sh -c 'read l < /proc/bus/input/devices ; echo $l'
Regards,
Vincent
Bastian