The rest of your post appears to be about shell (presumably Bourne) script, leaving this claim unsupported. "UNIX philosophy" != "writing shell scripts".
> You shouldn't have to fork a process from the shell to multiply two floating point numbers
I can't remember a single time in the >25 years I've been writing Bourne shell (or bash) scripts where I've wanted to "multiply two floating point numbers". I've sent large lists of floating point numbers to various programs for processing, but other languages are far more appropriate for problems that requires any amount of actual calculation (especially floating point calculations). If I did need to multiply two floats for some reason, it would be such a rare event that the few hundred milliseconds "wasted" in spawning bc is utterly irrelevant.
You seem to be complaining about shell by selecting a feature that is not actually needed in common use. What, specifically, were you doing that you needed fast floating point match but needed to use Bourne shell instead of C/Python/whatever?
> fork a process ... do simple string manipulation.
For many types of string manipulation, you don't. Manipulating strings (command lines) is what the shell was designed to do! Sometimes sed/awk/etc is useful for complex tasks, but the shell's variable expansion and other builtins are generally enough for most simple needs.
And if your needs actually are complex, the cost to start another process (which is probably much smaller than you think) is insignificant.
And no, the kind of stuff you need to fork sed or awk to do is not "complex". It's simple. It only seems complex because you're writing a shell script, and the backflips you have to do to escape the parameters and fork the processes to do that simple string manipulation is complex, not the string manipulation itself.
https://fishshell.com/docs/current/commands.html#math
I have already proposed an extremely practical, totally open, standards compliant, easily predictable, inevitable solution. What is your response to my posts about pushing something like Electron down to the bare metal?
It's not as if there aren't already thousands of extremely talented people across hundreds of different companies and organizations, all working towards towards making that possible and efficient. It's not as if the tooling doesn't already exist and isn't widely supported and rapidly evolving.
There is no need for X-Windows, and no need for Wayland, because a web browser running on bare metal could do everything they do, and so much more, in a vastly more flexible, standards compliant, modular, powerful, efficient way.
And it would be a much better platform for implementing a shell, user agent, desktop, window manager, and even a visual programming environment than the half-assed mish-mash Turing Tarpit of shell scripting languages Unix has suffered with for so many decades, which themselves don't even adhere to the so-called "Unix Philosophy".
AND it would be truly extensible (even capable of gasp multiplying floating point numbers and doing non-trivial string manipulation without forking heavy weight processes), which X-Windows and Wayland are not, which means it can be fundamentally much more efficient, by downloading code to implement application specific protocols and local interaction, like NeWS did decades ago, but X-Windows and Wayland foolishly and stubbornly refused to do by design. (It's not like the ideas behind NeWS were unknown to the designers of X-Windows and Wayland -- they just chose to ignore them. And now here we are.)
You've got JavaScript and WebAssembly for programming, WebGL and <canvas> and <video> and DHTML and CSS for drawing (including low latency rendering with desynchronized canvases), JSON and XML and ArrayBuffer for data representation, HTTP and WebSockets and WebRTC for networking. What is it missing?
https://developers.google.com/web/updates/2019/05/desynchron...
That design has been well proven and is widely used throughout the industry. It's not a new idea, but kids these days refer to it as "AJAX". There's no need for a bunch of useless layers underneath the web browser any more. It's time for X-Windows and Wayland to fade away into the depths of history.
I find web programming inelegant honestly, with three languages instead of one, a clumsy interpreted programming language that doesn’t multithread. Webasm may help with the last parts, perhaps. What about performance? How to run native code in windows?
At least I’d know how to use it, that’s a big plus. There would need to be some standardization around gui widgets, don’t like how they have to be built from scratch in every project.
Gnome3 uses js and css in its desktop widgets.
Finally Wayland is pretty lean, folks complain it doesn’t do enough already. You’d have to implement a driver and drawing layer anyway, right? So not much is “useless,” perhaps the window manager.
(Plus the other languages you need to switch to and rewrite from scratch once your bash script becomes more than 12 lines long.)
"After a shell script reaches a dozen lines, it's time to port it to Python." -mixmastamyk
Why would anyone in their right mind ever start out with a language that can only handle 11 line scripts?
And are you under the impression that bash is multithreaded? That it has good performance? A just in time compiler? An ahead of time compiler? A module system? A large ecosystem of reusable modules that can plug together and call each other without conflicts? An object oriented programming system? A debugger? An IDE?
Can you compile C++ and other languages into compact BashAssembly code, call it back and forth directly from Bash, and run it really fast across all platforms?
In case you weren't aware, a hell of a lot of people write JavaScript code that runs in node.js, instead of bash scripts, and are very happy with it. And of course Electron can run any code that runs in node.
So yes, running JavaScript in node or Electron is a fine alternative to running bash scripts. It can even handle file names with space in them without shitting itself! What rocket science! And you don't even have to rewrite your scripts in another language once they reach 12 lines -- what a relief!
What I was describing that you didn't understand is implementing a visual programming shell in Electron. And if you prefer a text command line shell with a different syntax than plain JavaScript, then simply implement that syntax and the command line interpreter in JavaScript itself, so you have the complete power of JavaScript and all its libraries to draw from (including extravagant luxuries you're not used to, and couldn't imagine you'll ever need, like floating point math and string manipulation), and you can import and call any JavaScript module. That blows bash out of the water.
You say you're not even aware that there are libraries of user interface widgets for JavaScript, and falsely claim they have to be "built from scratch in every project". But there are many, some of them quite good.
So have you ever even heard of or used the Chrome debugger JavaScript console window, or have any clue what high power integrated convenience and debugging features it supports?
Google Chrome Developer Tools Crash Course
https://www.youtube.com/watch?v=x4q86IjJFag
How does that compare to your favorite bash integrated development environment and debugger? Care to tell me which one you use, and link me to a tutorial that shows how much better it is than the Chrome debugger?
Or do you firmly believe that ALL people who write bash scripts NEVER need to debug them, set breakpoints, catch errors, examine stack traces and scopes, single step through code, browse the values of variables and data structures at runtime, just like they never need to use floating point or do non-trivial string manipulation?
I admit that might be the case if you always rewrite your bash scripts in Python once they reach a dozen lines, as you say. But in the real world, most bash scripts are much longer than that, and often suffer from lots of bugs.
You sound like one of those people who complains about hating Lisp because it has too many parenthesis, then goes and writes code in bash or perl with so much punctuation and different kinds of parens and brackets and braces and single letter abbreviations and syntactic syrup of ipecac, that it looks like you lifted the phone out of your 300 baud modem's acoustic coupler and shouted into it.
As I said, you're blind to the problems and limitations of your favorite tools, and hypocritical in your criticisms of better tools.
The preface of the Unix Haters handbook perfectly describes the problem you're suffering from:
https://web.mit.edu/~simsong/www/ugh.pdf
“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act.” — Ken Pier, Xerox PARC
There are languages optimized for interactive use, and others for writing batch scripts and programs. Fish is great for interactivity, Python not so much. So they compliment each other quite well. There have been a few attempts to do both (xonsh/iPython), but none have been big hits yet.
Performance is important for long-running and/or computationally expensive apps, which are typically not interactive. When I brought it up, was thinking of Gimp filters, not "ps -ef | grep FOO".
Javascript is probably good enough these days. If you want to create a "jsh" interactive shell with the good parts have at it. Believe it is doable by a single person in a reasonable time. I'd guess a few might already exists and could use contributors.
Re: widgets, meant that few are standardized/built into the browser already and have to be downloaded, not that none exist. A silly situation (as someone who wrote GUI apps in a single language in the 90s), yet could be rectified.
But in thread about GUI Window systems you are going on and on about the limits of bash, which is why your arguments are not well received. It's really neither here nor there regarding Wayland. Shell scripting hasn't held me back since '98 or so, if it ever did. It's like complaining about vi when Sublime Text and VSC exists.
I get that you appreciate good software design, me too. But "worse is better" is the reality we live in. Things get better, eventually.
More seriously I can't imagine what "points" you're trying to score. Yes the shell is good at launching external processes, and yes the built-in facilities for other things are lacking in some ways. On the whole people work around them by using perl, python, and other tools.
It might be, as you say, that people resort to using such external scripts/languages because their shells suck. But I have to ask: So what? They get the job done. A "super-shell" doesn't need to be present, even if people do things the "hard-way".
Why would I waste my time trying to fix something that's fundamentally flawed, and that nobody would use because it wasn't "standard"?
We already have Python, JavaScript, Perl, etc. Even PHP is overwhelmingly better and more modular than bash! Why try to put lipstick on a pig like bash?
My point (which I already stated) is that the "Unix Philosophy" in intellectually bankrupt, not that the shell should be extended with string manipulation and floating point to make it unnecessary to fork "sed", "awk" and "bc".
So, what's the problem with that? I read it almost like "that doesn't mean that you never need to retrieve data, it just means you need to switch to SQL". People develop DSLs for a reason.
Your attitude about not being able to imagine any reason why you'd ever need to use floating point reminds me of the HP technical support person that Steve Strassmann quoted in his email to the Unix-Haters mailing list on Apr 10, 1991:
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
The fact that the basic shell could use more builtins instead of delegating everything to external processes (like calculating a simple expression) is totally unrelated to the Unix Philosophy being bankrupt.
If fork and processes weren't so expensive, I still think multiple processes are the best way to parallelise on multicore CPUs. In fact, there's a resurgence in programming environments based on multiple communicating, yet isolated, processes, see Erlang/Elixir.
Though I definitely would like to see someone seriously exploring a different paradigm than UNIX.
EDIT: Unix philosophy also is "everything is a file", and what is a file exactly? A bag of bytes. Everything we deal with is a bag of bytes if you think about it, so I find it perfectly fitting to model our world that way.
But then again, the current construct to represent this idea such as labels organised in directories, might be a bit long in the tooth and we're due for some paradigm shift on this front as well, but I digress.
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.
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".
https://stackoverflow.com/questions/12722095/how-do-i-use-fl...
>You can't. bash only does integers; you must delegate to a tool such as bc.
Use the right tool for the job, do not complain that you screwdriver sucks because you cannot cut wood with it.
I complain my screwdriver sucks when it's made of plastic, and it's only good for driving plastic screws into styrofoam.
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.
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.
> "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?
chsh - change login shell
DESCRIPTION
The chsh command changes the user login 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".
- 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.
[1] https://stackoverflow.com/questions/3325911/how-does-threadi...
[2] https://github.com/the8472/ffcnt
[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))
I think the takeaway is that floating point shell use cases are so vanishingly rare that no one bothers to switch shells over it.
https://unix.stackexchange.com/questions/40786/how-to-do-int...
Everything as a file is an abstraction, an enormously useful abstraction. The point isn't that it has to behave like a file in every way. At the C level, the fact that open(), read(), write(), or e/poll() behave the similarly is extremely helpful.
I can have a whole suite of functions that do not care what type of file descriptor they hold, but just that those functions behave in a predictable way. Maybe only 10% of my code has to care about the differences between them, instead of 70%.
I don't think it's a great investment in time redesigning the whole socket API since you need to keep the old one around, unless you want to lose 35 years of source code compatibility.
The BSD socket API can definitely and easily be improved and redesigned, if only there was some new players in the field that wanted to drop POSIX and C compatibility and try something new.
I meant that many new and forked UNIX-like kernels have been written over the past 35 years. Just the successful ones (for their time) include at least three BSDs, OSX, several commercial UNIXes (AIX, IRIX, Solaris, UnixWare...), and many others I'm unfamiliar with (e.g. embedded ones).
It's common to add new and better APIs while keeping old ones for compatibility. Sockets are a userland API, so if everyone had adopted a different one 20 years ago, the original API could probably be implemented in a userland shim with only a small performance hit.
However, a new file-based paradigm from sockets would probably work better with kernel involvement; that's why I mentioned kernels. We've seen many experiments in pretty much every other important API straddling kernel and userland. IPC, device management, filesystems, async/concurrent IO, you name it. Some succeeded, others failed. Why are there no widely successful, file-based alternatives to BSD sockets? The only one I know firsthand is /dev/tcp and that's a Bash internal.
Government, Politics, resistance to change, NIH syndrome, "us vs them" and a bunch of other issues all conspired to keep BSD Sockets alive.
The first is the origin of BSD Sockets at all - UCB got paid by the government to port TCP/IP to Unix and, AFAIK, provide it royalty-free to everyone, because DoD needed a replacement for TOPS-20 as fast as possible and widely available, and there were tons of new Unix machines on anything that could get paging up (and some that couldn't).
Then you have the part where TLI/XTI ends up in Unix Wars, associated with slow implementations (STREAMS), despite being superior interface. NIH syndrome also struck in IETF which left us with the issues in IPv6 development and defensiveness against better interfaces than BSD Sockets because those tended to be associated with the "evil enemy OSI" (a polish joke gets lost there, due to "osi" easily being turned into "axis").
Finally, you have a slapped together port of some features from XTI that forms "getaddrinfo", but doesn't get much use for years after introduction (1998) so when you learn programming BSD Sockets years later you still need to manually handle IPv4/IPv6 because no one is passing knowledge around.
Name one shell that's "Unix Philosophy Compliant". To the extent that they do comply to the "Unix Philosophy" by omitting crucial features like floating point and practical string manipulation, they actually SUFFER and INTRODUCE unnecessary complexity and enormous overhead.
Precisely that! It's post-hoc rationalization and bullshit, that's the point I was driving at.
ioctl, mmap, sockets could be represented as files, why not?
`echo 1 > /root/some-file/%lock` instead of fcntl(F_SETLK) -- I just made up this syntax
`echo SIGTERM > /proc/15683/signal` instead of kill
Not sure about mmap, since its very purpose it to map a file to memory.
The fact that they're not may be a clue to answering that question.
The Unix way pays to fork a process for a floating point operation in shell, then delegates the expensive work to something written in an appropriate (probably compiled, maybe vectorized/gpu optimized) language. Forking the process took 10-100s of usec. If the hard work is comparable to this, the prompt returns immediately, so it is fast enough. If the hard work is non-trivial, the fork for the floating point op is << 1% of the runtime. Either way, the fork is effectively free.
The “modern” ways (which Unix mostly killed off in the 70’s, but that are currently in revival), are to write the hard work in a high-level, and usually interpreted language or write the process control logic in a lower level language.
In the case of the high level language, the hard work is now ~2-10x slower than unoptimized logic in a compiled language, so you spend ~50-90% of your time in useless overhead.
If you move the process control to a low level language, then it is more verbose, and you also have to recompile (or jit) the bulk of the program, which is much more expensive than forking a process. It likely takes 10s or even 10,000s of milliseconds!
There is a reason Unix won back when machines were orders of magnitude more expensive than they are now. (And why is it still more usable than its competitors today.)
If you are doing this often enough where such computation affects the throughput of your application, then you are using the wrong approach - computation is not meant to be done via the shell or shell scripts, these are meant to be used to tie together applications. That you can use bc for computations is just a convenience the overall design enables you, but that doesn't mean it is how you should use it.
You are using the passive voice, which is useful when you want to obscure the subject of the sentence. So WHO does not mean for you to perform floating point calculations and string manipulation with the shell?
The shell is a human designed artifact. God did not create the category of shell scripting languages and declare that nobody should ever use them perform floating point or string manipulation.
Windows Powershell isn't ridiculously crippled like bash is. It's still a shell. That disproves your point that there is some universal definition of a shell that precludes it being useful for general purpose programming tasks.
If the Unix Philosophy is a good thing or not is another matter, but to judge that you first have to understand it.
Just because Eric Raymond writes something in a book doesn't mean it's true.
I've been using Unix for at least 37 years, and other operating systems before that, so I think I have enough experience and understanding to judge the "Unix Philosophy" myself, instead of simply believing without question and regurgitating everything Eric Raymond writes. (And unlike him, I also don't believe black people are violent and stupid, or that white people's long term objective must be to break, crush and eventually destroy Islamic culture, either!)
One doesn't follow the other, the "computation is not meant to be done via the shell or shell scripts" is a statement i made and that was under the context of the Unix Philosophy.
Also you are focusing on the wrong thing here.
> Just because Eric Raymond writes something in a book doesn't mean it's true.
I haven't read any of his books nor i see what he has to do with it.
> I have enough experience to judge the "Unix Philosophy" myself
Then why are you using floating point computation with a bash script as an example for where the Unix Philosophy is bad? Bash doesn't follow the Unix Philosophy, shell scripts aren't even meant to be used for floating point computation when you consider it, instead you should either use a tool dedicated to such computations or to the specific computation you want to perform.
There are issues with the Unix Philosophy, like the simplicity it boasts only exists at a micro/local scale but it disappears at a macro/global scale - combining a few simple tools ends up with the combined complexity of all those tools plus the complexity inherent in the communication of them. To use these simple tools effectively you need to know all of them, knowledge of a single tool - despite how simple it might be by itself - is not very useful if it can only do one thing because an application almost never needs to do one thing.
This isn't a matter of performance, since nobody ever claimed that following the Unix Philosophy would be fast - but many do claim that it is simple.
There you go with the passive voice again. I ask you yet again: WHO didn't mean for shell scripts to be used for floating point computation? Citations, please?
>I haven't read any of his books nor i see what he has to do with it.
He wrote "The [Brainf]Art of Unix Programming". Since you claimed to understand the "Unix Philosophy", I assume you would have at least heard of the book written by one of the self-proclaimed experts on the topic, which has a whole section including 17 rules in the Wikipedia page on "Unix Philosophy". How long have you been philosophizing away about Unix anyway? Have you seriously never heard of that book?
https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond's...
>Bash doesn't follow the Unix Philosophy.
Bash is no true Scotsman, huh? Bash doesn't follow the Unix Philosophy. Csh doesn't follow the Unix Philosophy. Sh doesn't follow the Unix Philosophy. Yet they are all historically the predominant shell scripting languages of the Unix versions of their time. Can you name ONE popular Unix shell that DOES actually follow the Unix Philosophy? Or does the Unix Philosophy not apply to shells? And who said so?
The "Unix Philosophy" is after-the fact rationalization and bullshit. If the main way to program it is shell scripting, but none of the official shells actually follow the Unix Philosophy, then where does that leave you?
Ok, so you want a more powerful shell, see my other replies for examples.