4 ms·

Could killing the PID like that create zombies?

ykonstant 3y ago
Perhaps, but in any case I would never write code like this. First of all, sending sigkill is literally overkill and perpetuates a bad practice. Send `TERM`. If it doesn't work, figure out why. Secondly, subshells should be made as clear as possible and not hidden in pipes. Related, looping over `read` is essentially never the right thing to do. If you really need to do that, don't use pipes; use heredocs or herestrings. Fourth, if you cannot avoid subshells and you want to terminate the full script on some condition, exit with a specific exit code from the subshell, check for it outside and terminate appropriately.
- gpvos 3y ago
  > looping over `read` is essentially never the right thing to do Why? I do it quite often, though admittedly usually in one-time scripts.
  - ykonstant 3y ago
    See my reply to qazxcvbnm and study the links carefully if you want to do robust shell scripting.
- qazxcvbnm 3y ago
  Do enlighten me on why it is a bad idea to use loops over read; it's perhaps one of my favourite patterns in bash, and combined with pipes, appears to me one of the cleanest ways to correctly and concisely utilise parallelism in software.
  - ykonstant 3y ago
    Stéphane Chazelas has already explained this extensively, so I will link to two of his most information-dense posts: https://unix.stackexchange.com/questions/169716/why-is-using-a-shell-loop-to-process-text-considered-bad-practice/169765#169765 https://unix.stackexchange.com/questions/169716/why-is-using... https://unix.stackexchange.com/questions/209123/understanding-ifs-read-r-line/209184#209184 https://unix.stackexchange.com/questions/209123/understandin... Both of these posts must be read carefully if you really wish to write robust scripts.
    - qazxcvbnm 3y ago
      The provided points don't seem to be reasons for generally avoiding the subshell loop pattern. Reasons of 1) performance, 2) readability, and 3) security are provided as points against the pattern, and the post itself acknowledges that the pattern is a great way to call external programs. I'd think that the fact that one is using shell to begin with would almost certainly mean that one is using the subshell loop pattern for calling external programs, which is the use case that your post approves of. In this case, subshells taking the piped input as stdin allows the easy passing of data streamed over a file-descriptor, probably one of the most trivially performant ways of data movement, and the pattern is composable, certainly easier to remember, modify, and to extend than the provided xargs alternative, without potential problems such as exceeding max argument length. Having independent subshells also allows for non-interference between separate loops when run in parallel, offering something resembling a proper closure. In these respects, subshell loops provide benefits rather than pitfalls in performance and readability. Certainly read has some quirks that one needs to be aware of, but aren't much of an issue when operating on inputs of a known shape, which is likely the case if one is about to provide them as arguments to another command. Regarding "security", the need to quote applies to anything in shell, and has nothing specifically to do with the pattern.

Perhaps, but in any case I would never write code like this. First of all, sending sigkill is literally overkill and perpetuates a bad practice. Send `TERM`. If it doesn't work, figure out why. Secondly, subshells should be made as clear as possible and not hidden in pipes. Related, looping over `read` is essentially never the right thing to do. If you really need to do that, don't use pipes; use heredocs or herestrings. Fourth, if you cannot avoid subshells and you want to terminate the full script on some condition, exit with a specific exit code from the subshell, check for it outside and terminate appropriately.

gpvos 3y ago
> looping over `read` is essentially never the right thing to do Why? I do it quite often, though admittedly usually in one-time scripts.
- ykonstant 3y ago
  See my reply to qazxcvbnm and study the links carefully if you want to do robust shell scripting.
qazxcvbnm 3y ago
Do enlighten me on why it is a bad idea to use loops over read; it's perhaps one of my favourite patterns in bash, and combined with pipes, appears to me one of the cleanest ways to correctly and concisely utilise parallelism in software.
- ykonstant 3y ago
  Stéphane Chazelas has already explained this extensively, so I will link to two of his most information-dense posts: https://unix.stackexchange.com/questions/169716/why-is-using-a-shell-loop-to-process-text-considered-bad-practice/169765#169765 https://unix.stackexchange.com/questions/169716/why-is-using... https://unix.stackexchange.com/questions/209123/understanding-ifs-read-r-line/209184#209184 https://unix.stackexchange.com/questions/209123/understandin... Both of these posts must be read carefully if you really wish to write robust scripts.
  - qazxcvbnm 3y ago
    The provided points don't seem to be reasons for generally avoiding the subshell loop pattern. Reasons of 1) performance, 2) readability, and 3) security are provided as points against the pattern, and the post itself acknowledges that the pattern is a great way to call external programs. I'd think that the fact that one is using shell to begin with would almost certainly mean that one is using the subshell loop pattern for calling external programs, which is the use case that your post approves of. In this case, subshells taking the piped input as stdin allows the easy passing of data streamed over a file-descriptor, probably one of the most trivially performant ways of data movement, and the pattern is composable, certainly easier to remember, modify, and to extend than the provided xargs alternative, without potential problems such as exceeding max argument length. Having independent subshells also allows for non-interference between separate loops when run in parallel, offering something resembling a proper closure. In these respects, subshell loops provide benefits rather than pitfalls in performance and readability. Certainly read has some quirks that one needs to be aware of, but aren't much of an issue when operating on inputs of a known shape, which is likely the case if one is about to provide them as arguments to another command. Regarding "security", the need to quote applies to anything in shell, and has nothing specifically to do with the pattern.