3 ms·
Yeah, definitely not a proper fix. Maybe a more serious fix is something like "read -t $N". If you think stdin might not be usable (like maybe it will close pr
by dpkirchner 11mo ago
Yeah, definitely not a proper fix.
Maybe a more serious fix is something like "read -t $N". If you think stdin might not be usable (like maybe it will close prematurely) this option won't work, but maybe you can open an anonymous FD and read from it instead.
- qhwudbebd 11mo agowhile wait && [[ $SECONDS -lt $1 ]]; do read -t $(($1 - SECONDS)) done <><(:) although if you're not too concerned about finishing early if a signal interrupts, probably { wait; read -t $1; } <><(:) would be fine. You want the wait because otherwise bash won't reap the zombie from the process substitution until after the read times out. Interestingly, it does reap on a blocked read without -t, so potentially the behaviour on -t would be considered a bug rather than as-designed. There's also a loadable sleep builtin supplied with bash which calls into the internal fsleep() so should be reliable and without forking.
- nh2 11mo agoIt's just all hacks. It should use `sleep`, period. Sleeping is an OS scheduling task. Use the OS syscall that does that. As is suggested on the Github issue that Microsoft has been ignoring for half a year.