As someone who lives in zsh and bash for interactive usage- I want to say- please do not write scripts in bash or zsh.
Use powershell- its an amazingly well designed scripting language.
Also- there is ammonite. Written for scripting.
Bash 5.0 released
31–40 of 306 posts
Re: Bash 5.0 released
#32Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version.
/bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
Re: Bash 5.0 released
#33I can’t imagine what BASH_ARGV0 is for. Can someone more sage supply an example of what problem it solves?
“BASH_ARGV0: a new variable that expands to $0 and sets $0 on assignment.” Changing argv[0] would make utilities like ps show a more descriptive/shorter name, eg in the case of long command paths.
I don't think changing argv[0] in the current process will have any effect in the /proc file system.
And to do what you describe, there's `exec -a NAME' already:
$ (exec -a NOT-BASH bash -c 'echo $0; ps -p $BASHPID -f')
NOT-BASH
UID PID PPID C STIME TTY TIME CMD
dualbus 18210 2549 0 19:30 pts/1 00:00:00 NOT-BASH -c echo $0; ps -p $BASHPID -fRe: Bash 5.0 released
#34Why 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…
I think you might like TempleOS.
Re: Bash 5.0 released
#35Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Lik…
It's just GPLv3 software though. In contract, SSH is currently reporting OpenSSH_7.9p1, and that is fairly up to date.
I do think that if Apple can't ship a current version (for whatever reason), they probably shouldn't have it pre-installed at all, much like the BSD's don't come with bash by default either. Maybe they could ship with ksh/pdksh/mksh or something instead.
Re: Bash 5.0 released
#36Earlier 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?
It's strange to me to imagine that there would be one language that was the best choice for OS implementation and day to day user interaction/automation. I'm curious what language do you think would be good for both use cases?
Re: Bash 5.0 released
#37Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Lik…
I still don't understand how a gnu binary could taint their OS. They can provide the source on opensource.apple.com. Case closed.
Re: Bash 5.0 released
#38I can’t imagine what BASH_ARGV0 is for. Can someone more sage supply an example of what problem it solves?
A use-case I've long wanted it for is better "--help" messages. If you want to tell the user how to invoke the program again, argv[0] is the right thing:
Given:
#include
int main(int argc, char *argv[]) {
printf("Usage: %s [OPTIONS]\n", argv[0]);
return 0;
}
Usage: ./dir/demo [OPTIONS]
Usage: demo [OPTIONS]
But with a Bash script, argv[0] is erased, it sets $0 is set to script path passed to `bash` as an argument.
Given:
#!/bin/bash
echo "Usage: $0 [OPTIONS]"
Usage: ./dir/demo [OPTIONS]
Usage: /usr/bin/demo [OPTIONS]
In POSIX shell, $0 is a little useful for looking up the source file, but isn't so useful for knowing how the user invoked you. In Bash, if you need the source file, you're better served by ${BASH_SOURCE[0]}, rendering $0 relatively useless. And neither has a way to know how the user invoked you... until now.
It's a small problem, but one that there was no solution for.
Re: Bash 5.0 released
#39Earlier 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?
The choice of python as your shell would surely be as arbitrary as bash?
There is a long history of alternative shells csh, tcsh, zsh, fish, etc. All with various level of abstraction and various amounts of "programming language type constructs" (for lack of a better term).
At the end of the day, long arguments have been had over which is the better shell. It's all just personal preference. Hence it can be set in /etc/passwd per user.
You prefer python? chsh is there to change it.
Re: Bash 5.0 released
#40Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Lik…
I assume you can install newer versions of Bash on macOS though?
(But it certainly suggests to me that macOS isn't actually the easiest out-of-the-box solution if your workflow includes anything more than web browsing.)