3 ms·

could you instead just add a count to how many times the sleep was invoked, and then add that check into the `until` condition to quit after X numbers of sleeps

• xelxebar 1y ago
  For the author's stated purpose, it sounds like this would work well. However, curl can take a long time to timeout of whatever, depending on server state. I'm curious how people would approach a guaranteeing a maximum time to response or error.
  • chii 1y ago
    In the case of curl, there is a timeout parameter for requests and connections etc. It's what i'd use for checking for a server being up. But in the general case, where the command being invoked does not have such an option, then it does make a lot of sense to do a check like that via the `timeout` utility.
    • diggan 1y ago
      For curl: --connect-timeout = Times out if the connection wasn't established within N seconds --max-time = Times out if the entire request wasn't completed within N seconds But then I don't remember if connect-timeout takes DNS lookups into account, or TLS handshakes. I seem to remember there is another sort of timeout that tends to be hard to get right when the connections are flaky/drops a lot of packets, so you end up having to wrap curl anyways if you want a hard limit on the timeout.
      • SoftTalker 1y ago
        I've had many, many cases of processes in Linux getting wedged up bad enough that they cannot be killed. Usually this seems to involve them waiting on I/O.
        • chgs 1y ago
          Kill -9 won’t help in those cases though
  • cb321 1y ago
    It's not POSIX, but both bash & zsh have real time queries built-in (of course, $(date) is an even older school substitute): t1=$((EPOCHSECONDS + 60)) while [ $EPOCHSECONDS -lt $t1 ] do # curl ... && break # or whatnot done There is also EPOCHREALTIME which gives you a floating point to micro or nanoseconds (for bash/zsh), but only Zsh provides FP arithmetic. There are string-manipulation workarounds, of course. And, yes, with Zsh you might need a `zmodload zsh/datetime` in there. These variables seem "under known". EDIT: For example, you can get a quickie wall time measurement from a Zsh shell function like this: dt () { t0=$EPOCHREALTIME "$@" printf "%.7f wallSec\n" "$((EPOCHREALTIME-t0))" >&2 } And then you can actually run in your shell dt echo hi, moon without even a single fork/clone. (which you can confirm with an off to the side `strace -fv -o/dev/shm/dt.st -p WHATEVER_PID`, although I guess the culture these days is often to have even prompt printing launch a zoo of activity)
    • michaelcampbell 1y ago
      > These variables seem "under known". I speak only for me but TIL these; thanks!
• crabbone 1y ago
  Not really (at least, not very easily). There's no guarantee that for whatever reason curl won't hang. To do it properly, you'd need some code before the loop to start a separate process that would check on the parent process... but, really, you don't want to go there, not in Bash anyways. But, assuming curl won't hang, you could compare timestamps. It's better than counting iterations (in terms of emulating timeout command). But then, you might want to get fancy and implement exponential backoff or whatever other strategy you fancy to not overload the whatever thing you are polling... again, probably not in Bash.