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

81–90 of 306 posts

Re: Bash 5.0 released

#81

Post by viraptor »

chrisshroba wrote: post #59
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.

> if you have a script iterating over 10k files

That's probably a good sign you should advance from shell. If the script is trivial, it's going to be trivial in python / ruby / go / crystal / ... as well. If it's not trivial, that's another reason to move.

Re: Bash 5.0 released

#82

Post by hestefisk »

stock_toaster wrote: post #35
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…

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.

MacOS used to ship with tcsh as its default shell for years.

Re: Bash 5.0 released

#83

Post by [deleted] »

LukeShu wrote: post #80
Matt3o12_ wrote: post #75

Earlier quoted context omitted.

Apple doesn’t support it because GPLv3 requires that you are actually able to run the modified source code (not just see, change and distribute). While they probably could do that on macOS, macos and iOS share the same kernel and many common source trees. So by providing macOS software with GPLv3 code, some of that code could potentially be shipped with iOS which would land them in hot water because you are not able…

Sure. But iOS doesn't have Bash (I don't think, even if it does: Then just ship GPLv2 Bash on iOS, and modern Bash on macOS where users might actually care). The GPLv3 of Bash doesn't infect the shared kernel or libraries between iOS and macOS, it's just the `/bin/sh` program. It's easy enough to check if it's being included in iOS. "The reason we can't ship modern Bash on macOS is that we're concerned we might accid…

[deleted]

Re: Bash 5.0 released

#84

Post by _kst_ »

With 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 would allow the user to define similar variables. For example, I have $today set to the current date in YYYY-MM-DD format, and I have to jump through some minor hoops to keep it up to date.

Does anyone else think this would be useful enough to propose as a new bash feature? Would it create any potential security holes? Should variables like $PATH be exempted?

(Of course this doesn't add any new functionality, since I could use "$(date +%F)" in place of "$today". It's just a bit of syntactic sugar.)

Re: Bash 5.0 released

#85

Post by LukeShu »

dualbus wrote: post #58
chrisseaton wrote: post #55

Earlier quoted context omitted.

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

The argv array (and the envp array) are in a page the kernel set up when it created the process, and the kernel holds on a reference to it, and remembers the addres of those arrays in the page. The kernel doesn't need to "watch" that memory, when you read from `/proc/$pid/cmdline` or `/proc/$pid/environ`, procfs literally reads directly from $pid's memory space (remember that the kernel controls the page table, it can look in to the memory space of any process it wants to). The kernel doesn't "know" that the value changed, it just reads the current value from process' memory.

Re: Bash 5.0 released

#86

Post by Matt3o12_ »

LukeShu wrote: post #80
Matt3o12_ wrote: post #75

Earlier quoted context omitted.

Apple doesn’t support it because GPLv3 requires that you are actually able to run the modified source code (not just see, change and distribute). While they probably could do that on macOS, macos and iOS share the same kernel and many common source trees. So by providing macOS software with GPLv3 code, some of that code could potentially be shipped with iOS which would land them in hot water because you are not able…

Sure. But iOS doesn't have Bash (I don't think, even if it does: Then just ship GPLv2 Bash on iOS, and modern Bash on macOS where users might actually care). The GPLv3 of Bash doesn't infect the shared kernel or libraries between iOS and macOS, it's just the `/bin/sh` program. It's easy enough to check if it's being included in iOS. "The reason we can't ship modern Bash on macOS is that we're concerned we might accid…

Apple is pretty firm on no GPLv3 because accidentally shipping it on iOS can be pretty dangerous for them. Whether you agree with the decision to just not ship GPLv3 software (I don’t), I can understand apples concerns regarding GPLv3.

Furthermore, it wouldn’t surprise me if iOS had bash support even for just debug builds and Apple either had to worry about testing, building and maintaining two version of bash and still risk getting them mixed up and accidentally shipping some parts of the bash source code. This much easier to just never use GPLV3

Re: Bash 5.0 released

#87

Post by dralley »

jxy wrote: post #57
charlesdaniels wrote: post #29

Earlier quoted context omitted.

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.

Redox reuses a lot of concepts from Plan 9

Re: Bash 5.0 released

#88

Post by willglynn »

dualbus wrote: post #58
chrisseaton wrote: post #55

Earlier quoted context omitted.

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

On Linux, reading /proc//cmdline literally asks the kernel to reach into the target process's address space and fish out its argv[0]. This, erm... has some corner cases:

https://github.com/torvalds/linux/blob/v4.20/fs/proc/base.c#...

https://github.com/torvalds/linux/blob/v4.20/fs/proc/base.c#...

Changing the `ps` output in a cross platform way requires a number of platform-dependent strategies, e.g. how PostgreSQL does it:

https://github.com/postgres/postgres/blob/REL_11_1/src/backe...

Re: Bash 5.0 released

#89

Post by gigatexal »

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…

Yeah just use homebrew and forget about it

Re: Bash 5.0 released

#90

Post by ajross »

Matt3o12_ wrote: post #86
LukeShu wrote: post #80

Earlier quoted context omitted.

Sure. But iOS doesn't have Bash (I don't think, even if it does: Then just ship GPLv2 Bash on iOS, and modern Bash on macOS where users might actually care). The GPLv3 of Bash doesn't infect the shared kernel or libraries between iOS and macOS, it's just the `/bin/sh` program. It's easy enough to check if it's being included in iOS. "The reason we can't ship modern Bash on macOS is that we're concerned we might accid…

Apple is pretty firm on no GPLv3 because accidentally shipping it on iOS can be pretty dangerous for them. Whether you agree with the decision to just not ship GPLv3 software (I don’t), I can understand apples concerns regarding GPLv3. Furthermore, it wouldn’t surprise me if iOS had bash support even for just debug builds and Apple either had to worry about testing, building and maintaining two version of bash and st…

> accidentally shipping it on iOS can be pretty dangerous

I read the same argument about GPLv2 in like 1994. To date, there remains no case law I'm aware of where a copyright holder "lost" anything by "accidentally" shipping GPL software. How many decades does it take for us to put this myth to rest?

Post reply on HN