Yet macOS is still on 3.2.
Bash 5.0 released
171–180 of 306 posts
Re: Bash 5.0 released
#172Yet macOS is still on 3.2.
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Re: Bash 5.0 released
#173With this release, bash now has three built-in variables (um, I mean "parameters") whose values are updated every time they're read: $RANDOM yields a random integer in the range 0..32767. (This feature was already there.) $EPOCHSECONDS yields the whole number of seconds since the epoch. $EPOCHREALTIME yields the number of seconds since the epoch with microsecond precision. I'm thinking of a new shell feature that wou…
Anyone knows why a `microsecond since epoch` is named "realtime"? What is so "guaranteed" about it?
And does it even count leap seconds? Regular Unix timestamps do not (time stands still during leap seconds)
Re: Bash 5.0 released
#174Yet macOS is still on 3.2.
MacOS doesn't appear to ship GPLv3 licensed code. 3.2 is the last update on GPLv2.
Alternatively - newer versions of ZSH are frequently provided by Apple.
Re: Bash 5.0 released
#175Earlier quoted context omitted.
> The only reason I think they didn't design unix this way was because C was too low level, but we could write the OS in a "higher level" functional language. You've already lost my interest. Bash/Shell is incredibly powerful and doesn't need a higher-level abstraction. That is what programming languages and CLI tools are for.
That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?
I have a different theory; perhaps line printers (which terminals try to emulate) are to blame.
Space on a line is limited and one directional, so thr tools naturally evolved towards strange single line incantations instead of full fledged programs.
Commodore Pet did it right by introducing a navigable terminal where you could move between lines and don't need to open an editor to write multiline programs.
Re: Bash 5.0 released
#176Earlier quoted context omitted.
It also ships a recent version if zsh. But I agree, you're better off with Linux if you want a developer box and deploy on Linux.
How's that? The quality and amount of GUI tools are far more complete in macOS than Linux desktop and you can just run a Linux VM to mimic the deployment server.
I don't care about the GUI tools, I just need an editor, a terminal and a web browser. And maybe Sequel Pro once in a blue moon. The MacOS GUI is quite annoying when you want to do stuff fast like for instance move windows between virtual desktops or switch the desktop with the mouse wheel.
The tooling is just not there (old Python, old Perl, old Ruby and of course different versions from your deployment environment), you have to resort to third party tools such as homebrew or macports, you have to install Xcode to get gcc, you need an Apple ID to do that, the system level API is incompatibile with Linux, the filesystem is or at least was case insensitive. New MacOS versions after El Capitan are also getting worse at compatiiblity with other Unix-like platfroms. It's a pain to set up a development environment really, especially if you use any dynlibs. Instead of a VM we have a staging server where we deploy and there are almost always surprises.
In Linux the tooling is just there, a few seconds and one package manager command away. If your package is not there then there are PPAs or OBS repos. You can reproduce the platform you're deploying as closely as possible and there are less surprises.
Re: Bash 5.0 released
#177Why did we keep the language of the shell and the OS separate? It seems like a needless abstraction which creates more harm than good (read a shell script vs any other language). While I'm at it, why is the filesystem and syscall api not just part of a standard userland language? For example, the filesystem could be exposed like an object tree rather than some syscall ritual. The syscalls could just be invisible, whe…
> stuck in a usless POSIX compatibility trap Exactly. Unfortunately. Unless we have a solution that is significantly better than POSIX/UNIX, switching to anything else incurs a significant cost that no one is willing to pay. Short of that, we probably need a technology breakthrough that brings in a complete architectural change.
> Unless we have a solution that is significantly better than POSIX/UNIX, switching to anything else incurs a significant cost that no one is willing to pay.
The problem is that it doesn't even suffice for the new thing to be "significantly better". Because of the huge sunk cost, the new thing needs to be able to do desirable things that a POSIX-compatible OS strictly cannot do. Otherwise, it will always be easier and faster to just glue another subsystem onto the Linux kernel and continue using that.
Re: Bash 5.0 released
#178Any recommended reading for Bash? I'm somewhat new to it and it's interesting ways of getting things done. I've used it minimally in the past, but have found myself writing a 100> LOC script, which I can't help but feel I'm likely over-complicating certain bits and pieces.
There used to be this great resource called Linux Documentation Project. It's not as active as it used to be but it produced some really book-quality documents, including the Advanced Bash Scripting Guide at https://www.tldp.org/LDP/abs/html/ . Read it! It's great. But know that a lot of bash scripting isn't really in bash, it's really required to be proficient with grep, sed, cut, dc and a few other text processing…
Advanced Bash Scripting Guide on TLDP is a verbose and cumbersome-to-read writeup. Better read the bash man page and then http://mywiki.wooledge.org/BashGuide and http://wiki.bash-hackers.org/start
Re: Bash 5.0 released
#179With this release, bash now has three built-in variables (um, I mean "parameters") whose values are updated every time they're read: $RANDOM yields a random integer in the range 0..32767. (This feature was already there.) $EPOCHSECONDS yields the whole number of seconds since the epoch. $EPOCHREALTIME yields the number of seconds since the epoch with microsecond precision. I'm thinking of a new shell feature that wou…
Here is my favourite bash script: https://blog.ashfame.com/2018/02/deploying-lambdas-multiple-... Deploy a lambda function in multiple regions (15 regions!) with just one bash script using Apex up. Add route53 on top with Latency Based Routing enabled and you've a latency in 10s of millsecond from anywhere on the globe without paying a hefty fee for this kind of latency.
How is that in any way related to the parent comment?
Re: Bash 5.0 released
#180Earlier quoted context omitted.
> The only reason I think they didn't design unix this way was because C was too low level, but we could write the OS in a "higher level" functional language. You've already lost my interest. Bash/Shell is incredibly powerful and doesn't need a higher-level abstraction. That is what programming languages and CLI tools are for.
That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?
> Do you use a separate, awkward tool to call functions you wrote in python?
I use a separate tool to call a lot of functions written in C. That tool is called “Python”. Or “Ruby”.
Sometimes I use a separate tool to call functions written in Python (or JavaScript, or...) and that tool is called PostgreSQL.
Sometimes I use Ruby to call C to call Postgres to call JS.
> Now that we have better languages, why not use them to write the OS bottom-up?
What better languages for implementing an OS? Lisp? We had that before C. Rust? Either way—and I like both languages—I don't want to use either for a shell. Red? Maybe, but I don't think we're to the point of a Red OS yet, and while it's probably eventually usable for that purpose, I don't see it as necessarily ideal for OS implementation though it might be tolerable as a shell language.