I'm talking about the shell that actually exists, not some hypothetical shell that doesn't exist and never will. You can't defend the "Unix Philosophy" by proposing a non-standard MONOLITHIC shell be universally adopted that totally goes against what the Unix Philosophy explicitly states: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
At least Apple figured out that floating point was useful early enough to replace INTEGER BASIC with APPLESOFT.
Forking "bc" from "bash" is the canonical way to multiply two floating point numbers in Unix, according to the "Unix Philosophy".
You too are blinded by the limitations of your tools. Of course the shell performs all kinds of computations. Just not a useful enough set of them that you don't still need "bc" and "awk" and "sed" and "grep" and many other ridiculous "Unix Philosophy Compliant" tools.
I complain my screwdriver sucks when it's made of plastic, and it's only good for driving plastic screws into styrofoam.
chsh - change login shell
DESCRIPTION
The chsh command changes the user login shell.
If you don't like the features of your shell, use a different shell.
> you don't still need ... "awk" and "sed" and "grep"
I don't need those programs - there are many other ways to solve most problems. I want to use them because they are both fast to start and execute, and make development time extremely fast.
> You too are blinded by the limitations of your tools.
You appear to be trying to use the shell for tasks that that should be done in a different language. You also don't seem to understand that some of use use the shell because discovered it was a much faster and easier to use tool for some problems than the other methods we've tried. For some tasks, complaining about the overhead to do some things like floating point or trivialities like the <100ms it takes to fork and run bc is a premature optimization.
If you don't find shell to be a useful tool for the problems you need to solve, that's fine; use whatever tool works best for you. We might be trying to solve different problems. Just because you don't like a particular tool doesn't mean it's "ridiculous".
What all those "ridiculous" tools allow, among other things, is:
- Cheap parallelism. Things as easy as `grep | cut | sort` will utilize multiple cores despite shell and all the tools it spawns being single-threaded. I can't imagine threading primitives in some supercharged version of bash without some ugly syntax and a number of additional questions about deadlocks on StackOverflow. That would not be bash, but some ugly Python parody instead. (Also note that even PowerShell seems to limit itself to job control primitives despite being more capable .NET-backed language: [1].) That usually saves me much more than ability of zsh to multiply floating point numbers without forking.
- (Inter)changeability. Want to multiply complex numbers? Use another calc. Want ridiculous regexes? pcregrep. Want to scan large hard disk efficiently? ffcnt [2]. Want to do something else, and to do it efficiently? Write a program without spending a time to learn your shell's C API [3], just read stdin or parse argv. Yeah, I too wish to not spend much time serializing and deserializing data in each and every pipe, but that would require not a new shell (we already have PowerShell) but, I guess, an entirely new OS as well as ecosystem designed just for that OS, which nobody would spend much time adapting to at this time.
[3] Really, who got time to spend on something like https://docs.python.org/2/c-api/index.html (I know, Cython exists, but there's no Cython for every language out there.)
(edit: formatting; replaced platter-walk (which is a library) with ffcnt (which uses said library))
The idea is that the tools are meant to be limited to avoid complexity (this is why bash, like most GNU tools, isn't really a good example of unix philosophy - it is too complex) and instead rely on composition.
If you browse through GNU documents, you sometimes come across strange ancient passages like
> "Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. "
What do you suppose the ancients meant by this? Some have taken it as evidence that in ancient times before GNU, Unix tools were not in fact "doing one thing and doing it well" as the Unix priests so often claim. This of course is blasphemy and the guilty are punished accordingly... but are they wrong?
As if the bash syntax for simple string manipulation and piping and quoting and escaping and even determining if a string is empty wasn't unnecessarily complex.
As I said, the "Unix Philosophy" of plugging together artificially limited tools by pipes is intellectually bankrupt (and terribly inefficient). That was my whole point.
It is inefficient, but that doesn't matter much for interactive use. After a shell script reaches a dozen lines, it's time to port it to Python. If the job needs absolute performance you rewrite in a performant language instead.
I'm not sure why you are upset to be honest? What design would you prefer? This one seems to hit all use cases.
In another thread I mention that fish has math and string manipulation builtins.
Plenty of Unix shells support floating point. For example, the conveniently-named ksh93 was released in 1993, and was / is available on a wide range of systems. I’d guess the hipster-compliant fish shell can do these things too, but can’t be bothered to RTFM.
I think the takeaway is that floating point shell use cases are so vanishingly rare that no one bothers to switch shells over it.
But at some point you need to delegate to other processes. You can't have /bin/bash embed your Chrome browser in it.
But that's not even Unix philosophy. That's how DOS used to work as well.