Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash 5.0 released

lists.gnu.org

Post reply on HN
Print view View original

51–60 of 306 posts

Re: Bash 5.0 released

#51

Post by PopsiclePete »

pornel wrote: post #32

Reminder 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…

Thank the GPL v3 for that one. Same reason GCC is frozen at 4.2.1 on mac.

I switched to zsh, personally - the one Apple ship is pretty current.

macOS is still a pretty solid developer machine.

Re: Bash 5.0 released

#52

Post by dorfsmay »

nwatson wrote: post #13
JeremyBanks wrote: post #5

Earlier quoted context omitted.

It can't be done. If you want to write reliable code, and actually notice all of the possible error conditions instead of silently ignoring them, your code needs to get more verbose and complicated than it would be to just use a more capable tool like Python or Node, and it still won't be as reliable. If you have more logic than a couple of string comparisons, Bash is not the right tool for the job.

I recommend Greg's Bash Wiki ... https://mywiki.wooledge.org/BashGuide . See general notes, then at the bottom of the page are many links to additional considerations. Like others say, "bash" is a hard tool to get right (and I'm not saying I do it right either, necessarily, but Greg's Wiki was real helpful!). I'm building a hybrid bash/python3 environment now (something I'll hopefully open-source at some point), and…

It is availbale, almost, everywhere but be careful with the version, different Linux diatros are at different versions, the last time I used OSX it was stuck on a very old version, and I expect the different BSD OSes to run fairly new versions.

Re: Bash 5.0 released

#53

Post by shpx »

_emacsomancer_ wrote: post #40
pornel wrote: post #32

Reminder 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.)

On macOS almost everyone uses the homebrew package manager https://brew.sh. Installing bash is harder because you have to add the filepath of the new bash binary to /etc/shells and then set that filepath as your default shell, but

    brew install bash
    echo /usr/local/bin/bash | sudo tee -a /etc/shells
    chsh -s /usr/local/bin/bash
and if you're on macOS and still haven't heard of homebrew, you first need to install it with

    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Re: Bash 5.0 released

#54

Post by flatline »

fxfan wrote: post #31

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.

Powershell has been around for quite a while now, but only recently could you rely on it being installed on Windows systems, let alone be available on Linux. Maybe in another decade, but if you are targeting Unix-like systems bash is probably still your safest bet for portable, interpreted code. Python2 is a close second.

Re: Bash 5.0 released

#55

Post by chrisseaton »

dualbus wrote: post #33
mturmon wrote: post #27

Earlier quoted context omitted.

“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 -f

> I don't think changing argv[0] in the current process will have any effect in the /proc file system.

Yes it does - that’s the whole point of changing it.

Re: Bash 5.0 released

#56

Post by jxy »

wlib wrote: post #11

Why 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.

Re: Bash 5.0 released

#57

Post by jxy »

charlesdaniels wrote: post #29
wlib wrote: post #11

Why 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…

If you're doing it right, you are solving very different problems with shell vs any other language. Shell is best used as a tool for orchestrating other programs, you should not be implementing your programs in shell. Syscalls, in general, are used in lieu of objects or other abstractions because they more accurate mirror what the underlying hardware is doing. This isn't always the case, some syscalls are maintained…

It's odd not including Plan 9 here. But I guess that is the fate of Plan 9.

Re: Bash 5.0 released

#58

Post by dualbus »

chrisseaton wrote: post #55
dualbus wrote: post #33

Earlier quoted context omitted.

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 -f

> I don't think changing argv[0] in the current process will have any effect in the /proc file system. Yes it does - that’s the whole point of changing it.

I would like to understand how this would work.

argv is a buffer in Bash's process memory space. This is AFAIK, not shared in any way with the kernel.

How would the kernel know that a process wrote to the memory location of argv[0] and then reflect that in /proc?

This is what I tried:

  dualbus@system76-pc:~/src/gnu/bash$ ./bash -c 'echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)'
  5.0.0(1)-rc1
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27918 20628  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)
  NOT-BASH 
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27918 20628  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27921 27918  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)

Re: Bash 5.0 released

#59

Post by chrisshroba »

nerdponx wrote: post #48

What is the value in creating built-in replacements for binaries like rm and stat?

It seems like this would eliminate the need to read a file from disk and fork a new process, both of which take time. If you're just removing a single file, this is probably negligible, but if you have a script iterating over 10k files, i.e., this speed-up may be more welcome.

Re: Bash 5.0 released

#60

Post by ajross »

Carpetsmoker wrote: post #43
pstuart wrote: post #37

Earlier quoted context omitted.

I still don't understand how a gnu binary could taint their OS. They can provide the source on opensource.apple.com. Case closed.

The problem is that GPL3 has more restrictions than just "publish the code". That's why projects such as FreeBSD, OpenBSD, etc. also won't include GPL3 code, as including GPL3 code would restrict what you can and can't do with the entire system. I assume that Apple's reasoning is similar.

Can you name them? It's not exactly snark. My experience is that almost everyone with strong GPLv3 opinions turns out not to actually object to the terms themselves when discussed in isolation.

To head off: it's not the patent grant. Apache 2 has a very similar patent grant and everyone is fine with it.

Post reply on HN