3 ms·
I'd argue that most of the work in a bash program is done by functions like find, grep, etc, and that the time to fork is not all that relevant. We don't progra
by SubiculumCode 5y ago
I'd argue that most of the work in a bash program is done by functions like find, grep, etc, and that the time to fork is not all that relevant. We don't program the same kinds of things in bash that we might in C++
- fiddlerwoaroof 5y agoYeah “fork is slow” is the sort of microbenchmark that is mostly irrelevant for shell scripts: every command you run in a script is basically a fork.
- VWWHFSfQ 5y agoif you want to fork your function call then you do it explicitly with $(my_function). I'm aware that people are always discovering things for the first time but there is literally decades of thought that has gone into why bash behaves the way it does. and there's a pretty good reason why the bash authors decided not to make function calls fork by default...
- deleted 5y ago[deleted]
- dataflow 5y ago> every command you run in a script is basically a fork Not for built-in commands. > Yeah “fork is slow” is the sort of microbenchmark that is mostly irrelevant for shell scripts Maybe if you're on a Linux kernel, but not everywhere else.
- Spivak 5y agoWhere are you running bash where forks are expensive? Like sure Windows exists but bash on WSL is running a Linux kernel.
- chasil 5y agoWhen I am using busybox sh/bash, I am very, very careful not to fork unless I must. For mass processing, I will use xargs to minimize the number of processes created.
- dataflow 5y agoNot quite. WSL2 uses a Linux kernel. WSL1 uses a Windows kernel and fork is much slower there. Also there's userspace variants like MSYS2, Cygwin, etc.
- plorkyeran 5y agoAssuming that fork is fast everywhere is how you end up with things like ffmpeg's configure script that runs in seconds on linux and _minutes_ on Windows.