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

71–80 of 306 posts

Re: Bash 5.0 released

#71

Post by PopeDotNinja »

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…

When I first learned one could write programs in Bash, I got very excited. It didn't take long for that to where off :) My Bash got a lot better though!

Re: Bash 5.0 released

#72

Post by chrisseaton »

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

Any process can write into the argv they get from the kernel.

The kernel doesn’t need to monitor for reads - when proc reads it it’s read from the process.

It doesn’t need to be specially ‘shared’ with the kernel. The kernel can of course ready any memory it wants to from the process at any time.

I’ve implemented setting argv[0] in another language myself.

Re: Bash 5.0 released

#73

Post by JeremyBanks »

cheez wrote: post #42
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 just use set -e at the top of the script

That's a good idea, but it's not a complete solution. See http://mywiki.wooledge.org/BashFAQ/105

Re: Bash 5.0 released

#74

Post by dualbus »

chrisseaton wrote: post #72
dualbus wrote: post #58

Earlier quoted context omitted.

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

Any process can write into the argv they get from the kernel. The kernel doesn’t need to monitor for reads - when proc reads it it’s read from the process. It doesn’t need to be specially ‘shared’ with the kernel. The kernel can of course ready any memory it wants to from the process at any time. I’ve implemented setting argv[0] in another language myself.

Can you show an example of how this would work with BASH_ARGV0?

Re: Bash 5.0 released

#75

Post by Matt3o12_ »

ajross wrote: post #60
Carpetsmoker wrote: post #43

Earlier quoted context omitted.

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.

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 to just execute code on iOS. Even with a developer license, you couldn’t just recompile the kernel (or even Library) and replace it with the default one.

Edit:

Here is more information about that:

> Protecting Your Right to Tinker

> Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.

Source: https://www.gnu.org/licenses/quick-guide-gplv3.en.html

That means if there was GPLv3 code in iOS, Apple would have to send you their private keys to sign any source code so you can run it on iOS.

Re: Bash 5.0 released

#76

Post by LukeShu »

ajross wrote: post #66
LukeShu wrote: post #38

Earlier quoted context omitted.

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; } Running it as `./dir/demo --help` gives: Usage: ./dir/demo [OPTIONS] Put it somewhere in $PATH, and run it as `demo --help`, and it will give: Usage: demo [OPTIO…

> If you want to tell the user how to invoke the program again, argv[0] is the right thing Some pedantry: it's actually not. The argv array is a completely arbitrary thing, passed by the caller as an array of strings and packed by the kernel into some memory at the top of the stack on entry to main(). It doesn't need to correspond to anything in particular, the use of argv[0] as the file name of the program is a side…

Sure, argv[0] is a just string, that the caller can set when they call execve(). That doesn't have mean that it doesn't have meaning. You are correct, there is no way to know how your executable was passed as the first argument to execve(). But, argv[0] is specified to mean roughly "welcome to the world, you are argv[0]", and to tell the program what it is. Sure, you could lie to the program, and tell it that it's something it's not by passing a different string to execve(), you can even do this from a Bash script with `exec -a`.

I stand by my original statement: If you want to tell the user how to invoke the program again, argv[0] is the right thing. I didn't say that running argv[0] will necessarily actually invoke the program again, I said that it's the right thing to tell the user. If the caller set argv[0] to something else, it's because they wanted your program to believe that is its identity, so that's what it should represent its identity as to the user.

Re: Bash 5.0 released

#77

Post by wlib »

LukeShu wrote: post #70
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…

That was kind of the idea of Unix. C was just a nicer from Assembly. You might write a performance-sensitive or low-level routine in C, much like you might drop to C when writing a Python library. But the high-level language of the system was the shell. The `dc` executable wasn't just meant to be a user-facing calculator program, it was also meant to be the system's "bignum" library. That was big-picture Unix. The sy…

Good insight, thank you

Re: Bash 5.0 released

#78

Post by chrisseaton »

dualbus wrote: post #74
chrisseaton wrote: post #72

Earlier quoted context omitted.

Any process can write into the argv they get from the kernel. The kernel doesn’t need to monitor for reads - when proc reads it it’s read from the process. It doesn’t need to be specially ‘shared’ with the kernel. The kernel can of course ready any memory it wants to from the process at any time. I’ve implemented setting argv[0] in another language myself.

Can you show an example of how this would work with BASH_ARGV0?

Sorry I don’t know anything about how Bash is implemented, but when someone assigns to that variable Bash just needs to write that string to argv.

Re: Bash 5.0 released

#79

Post by ajross »

Matt3o12_ wrote: post #75
ajross wrote: post #60

Earlier quoted context omitted.

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.

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…

The product in question is bash, though, which doesn't ship on iOS at all and which obviously could be (and should be) modifiable on OS X.

Re: Bash 5.0 released

#80

Post by LukeShu »

Matt3o12_ wrote: post #75
ajross wrote: post #60

Earlier quoted context omitted.

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.

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 accidentally include Bash on iOS."?

(and /bin/sh on macOS is already sufficiently user-modifiable to satisfy GPLv3)

Post reply on HN