3 ms·

As others have already menti9oned, running 'bc' isn't actually that expensive. Comparing it to Bitcoin is ridiculous. Let's investigate the actual cost of that

by pdkl95 7y ago

As others have already menti9oned, running 'bc' isn't actually that expensive. Comparing it to Bitcoin is ridiculous. Let's investigate the actual cost of that sum: $ cat foo.sh #!/bin/bash a="1.5" b="0.5" sum="$(echo "${a} + ${b}" | bc)" echo "The sum of ${a} and ${b} is ${sum}" $ /usr/bin/strace -q -D -w -c ./foo.sh The sum of 1.5 and 0.5 is 2.0 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 55.53 0.001225 123 10 read 9.75 0.000215 215 1 execve 5.53 0.000122 7 18 mmap 4.03 0.000089 8 11 3 open 3.04 0.000067 7 10 mprotect 2.99 0.000066 5 13 rt_sigprocmask 2.54 0.000056 56 1 clone 2.45 0.000054 5 10 close 2.40 0.000053 5 11 rt_sigaction 1.81 0.000040 5 8 fstat 1.41 0.000031 8 4 lseek 1.22 0.000027 5 5 3 stat 0.91 0.000020 20 1 write That was 56us to clone(2) the process and 215us to execve(2) 'bc'. All together just 12.74% of the time spent running syscalls, and an even smaller portion of the total time to launch and execute this simple example. Most of the time is sent launching bash itself at the beginning. Using a language such as python or launching a custom binary will have similar costs to to launch the program. If we're talking about a single persistent process (e.g. an interactive shell), then we're still talking about paying just 0.25ms of CPU time to perform a useful calculation. Compared to intentionally wasting time by design maximizing hash prefix guesses to "mine" Bitcoin "ain't the same fuckin' ballpark, it ain't the same league, it ain't even the same fuckin' sport"[1]. However, the actual cost to launch an external program like 'bc' isn't particularly important. It could be multiple orders of magnitude slower and it would still be acceptable because we're talking ab9ut a cost that only needs to be paid a few times. Yes, compared to "full" programming languages like python, running an external program to perform a simple calculation might seem like a wasteful, half-assed solution. As Gary Bernhardt explained[2], "Half-assed is OK when you only need half of an ass." I don't care about the cost of running 'bc' to do simple floating point calculations because I usually don't need to do floating point calculations (which are a lot harder to use safely[3] compared to simple integer math) for the type of task I would implement in a shell script. If the task required more than a few calculations (or other complex features such like a GUI), using something other language like python/ruby/C/rust would be a better tool than shell script. Learning how to choose the appropriate tools to use when solving a problem is an important skills for any engineer. Shell scripting languages like Bourne (sh) are designed to be a glue language that you use for simple (often interactive) tasks. They are the user interface (or "IDE") of Unix. Asking why shell d9oesn't have built-in support for efficient floating point math or complex GUI features is kind of like asking why Eclipse or Visual Studio don't have a built-in spreadsheet or email client. Yes, you could probably make that happen as a half-assed hack, but it's obviously not the type of task those tools were designed for. As for the syntax, if you find it confusing or ugly and prefer to use other tools, that's fine. There are a lot of great languages available, so use the tool that is best for you. If it had #!/bin/sh art the top, you can probably substitute any language you prefer without and problems. However, remember that for some of us Bourne shell is the easy, reasonably efficient tool we prefer to use for some problems. [1] https://en.wikiquote.org/wiki/Pulp_Fiction#Dialogue https://en.wikiquote.org/wiki/Pulp_Fiction#Dialogue [2] https://www.youtube.com/watch?v=sCZJblyT_XM https://www.youtube.com/watch?v=sCZJblyT_XM [3] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

DonHopkins 7y ago
>"for the type of task I would implement in a shell script" And therein lies the rub. Let's put the donkey before the cart: The reason you would not do many kinds of task in a shell script, is that shell scripts are not any good for many kinds of tasks, not because you are wrong to want to to some kinds of tasks. The term "shell script" is an artificial construct, just like the shell scripting language itself. There is no reason you need to limit your imagination, aspirations and abilities by defining yourself as a "shell scripter" who cannot add 1.5 and 0.5 to get 2, and who cannot draw a pie chart. Of course you should learn other languages, then you won't need to write shell scripts. Their disadvantages vastly outweigh their advantages in important ways specific to scripting and unix administration (like dealing with file names with spaces, or performing arithmetic and statistics, for examples).
- saagarjha 7y ago
  > shell scripts are not any good for many kinds of tasks Shell scripts are good for gluing together tools that do disparate things and simple automation. Most shell scripts end up becoming "real programs" once they start containing actual logic in them.
  - naniwaduni 7y ago
    More importantly, it doesn't matter that there are many kinds of tasks that shell scripts aren't good at. It matters that there are tasks that shell scripts are good at, and indeed better suited to than any popular general-purpose language. When you have a pipeline between two nontrivial programs, for example, or any kind of fd manipulation.
    - DonHopkins 7y ago
      Yet the problem remains that bash scripts are NOT actually good for what they're designed for: dealing with file names. Because some file names have spaces in them, and some file names begin with hyphens, and so many careless bash programmers don't give a shit, and would rather blame their audacious uncontrollable users for daring to put spaces or hyphens in their file names, than write scripts that don't suddenly and inexplicably crash, years after they're written and the programmer has long since left. Python and JavaScript are also good for gluing together tools that do disparate things and simple automation. But they can do arithmetic and graphics, too! And without the enormous overhead of forking a process to perform simple arithmetic and string manipulation. Bash scripts aren't good for many useful tasks because bash is badly designed, not because there's some universal law of computing that proclaims that scripts should never use floating point numbers or draw graphics. Apple figured all this out in 1979 when they made a deal with Microsoft and switched from INTEGER BASIC to APPLESOFT BASIC, and added floating point and HIRES graphics. Even Apple ][ DOS 3.2 could deal with file names with spaces in them! How long will it take the Unix community to figure that out, too? https://www.youtube.com/watch?v=RiWE-aO-cyU https://www.youtube.com/watch?v=RiWE-aO-cyU

by pdkl95 7y ago

DonHopkins 7y ago

>"for the type of task I would implement in a shell script" And therein lies the rub. Let's put the donkey before the cart: The reason you would not do many kinds of task in a shell script, is that shell scripts are not any good for many kinds of tasks, not because you are wrong to want to to some kinds of tasks. The term "shell script" is an artificial construct, just like the shell scripting language itself. There is no reason you need to limit your imagination, aspirations and abilities by defining yourself as a "shell scripter" who cannot add 1.5 and 0.5 to get 2, and who cannot draw a pie chart. Of course you should learn other languages, then you won't need to write shell scripts. Their disadvantages vastly outweigh their advantages in important ways specific to scripting and unix administration (like dealing with file names with spaces, or performing arithmetic and statistics, for examples).

saagarjha 7y ago
> shell scripts are not any good for many kinds of tasks Shell scripts are good for gluing together tools that do disparate things and simple automation. Most shell scripts end up becoming "real programs" once they start containing actual logic in them.
- naniwaduni 7y ago
  More importantly, it doesn't matter that there are many kinds of tasks that shell scripts aren't good at. It matters that there are tasks that shell scripts are good at, and indeed better suited to than any popular general-purpose language. When you have a pipeline between two nontrivial programs, for example, or any kind of fd manipulation.
  - DonHopkins 7y ago
    Yet the problem remains that bash scripts are NOT actually good for what they're designed for: dealing with file names. Because some file names have spaces in them, and some file names begin with hyphens, and so many careless bash programmers don't give a shit, and would rather blame their audacious uncontrollable users for daring to put spaces or hyphens in their file names, than write scripts that don't suddenly and inexplicably crash, years after they're written and the programmer has long since left. Python and JavaScript are also good for gluing together tools that do disparate things and simple automation. But they can do arithmetic and graphics, too! And without the enormous overhead of forking a process to perform simple arithmetic and string manipulation. Bash scripts aren't good for many useful tasks because bash is badly designed, not because there's some universal law of computing that proclaims that scripts should never use floating point numbers or draw graphics. Apple figured all this out in 1979 when they made a deal with Microsoft and switched from INTEGER BASIC to APPLESOFT BASIC, and added floating point and HIRES graphics. Even Apple ][ DOS 3.2 could deal with file names with spaces in them! How long will it take the Unix community to figure that out, too? https://www.youtube.com/watch?v=RiWE-aO-cyU https://www.youtube.com/watch?v=RiWE-aO-cyU