cipitaua
cipitaua
I've tried but unfortunately the behavior is the same
here's the backtrace with `#define HAVE_POLL 1` commented out: ``` Waiting for data... (interrupt to abort) Program received signal SIGINT, Interrupt. 0x00007ffff7e452c6 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace #0...
yes it iteratively gets there: ``` Breakpoint 1, iread (fd=4, buf=0x5555555a1dd4 "", len=7944) at os.c:195 195 n = read(fd, buf, len); (gdb) continue Continuing. Waiting for data... (interrupt to abort)...
I've tried, but `n` is always zero: ``` Waiting for data... (interrupt to abort) Program received signal SIGINT, Interrupt. 0x00007ffff7e452c6 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) break os.c:196 Breakpoint 1...
> Well, that's pretty baffling. I don't know why read() would not be returning the data that you added to the file. Are you still using a /dev/shm file for...
i've updated the previous post
> However, I now notice that the two machines showing the bug are with AMD Ryzen, while my work desktop is Intel based. Could it be a library compiling issue...
closing due to no response
I finally discovered that the problem was in the LESSOPEN env variable: ``` echo $LESSOPEN | /usr/share/source-highlight/src-hilite-lesspipe.sh %s ``` by launching `less` with the `-L` flag it can follow the...
in alternative, when the follow mode is enabled, `less` could reload the file and bypass the LESSOPEN script (force the -L flag)