Live data from Hacker News

Bash 5.0 released

lists.gnu.org

91–100 of 306 posts

Re: Bash 5.0 released

#91
post #74

Earlier quoted context omitted.

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.

I tried python, bash and even C, none of them update /proc/self/comm when argv[0] is updated:

  dualbus@system76-pc:~$ cat argv0.c
  #include 
  #include 
  int main(int argc, char **argv) {
      FILE *fp;
      char buf[256]; // XXX :-)
      strcpy(argv[0], "XYZ");
      //puts(argv[0]);
      fp = fopen("/proc/self/comm", "r");
      fread(&buf, 1, 256, fp);
      buf[255] = '\0';
      puts(buf);
  }
  dualbus@system76-pc:~$ gcc -o argv0 argv0.c  -Wall
  dualbus@system76-pc:~$ ./argv0
  argv0

  dualbus@system76-pc:~$ python -c 'import sys; sys.argv[0] = "XYZ"; print(open("/proc/self/comm").read())'
  python

  dualbus@system76-pc:~$ ~/src/gnu/bash/bash -c 'BASH_ARGV0="XYZ"; cat /proc/$BASHPID/comm'
  bash
Furthermore, https://github.com/torvalds/linux/blob/master/Documentation/... says:

  > 3.6   /proc//comm  & /proc//task//comm
  > --------------------------------------------------------
  > These files provide a method to access a tasks comm value. It also allows for
  > a task to set its own or one of its thread siblings comm value. The comm value
  > is limited in size compared to the cmdline value, so writing anything longer
  > then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
  > comm value.
Which works as advertised:

  dualbus@system76-pc:~$ ~/src/gnu/bash/bash -c 'echo -n XYZ > /proc/$BASHPID/comm; ps -p $BASHPID'
    PID TTY          TIME CMD
  28797 pts/6    00:00:00 XYZ
Can you show me an example, in any language, where updating argv[0] causes ps (or /proc/self/comm) to show the updated value?

EDIT: formatting.

EDIT2: I stand corrected, see willglynn's comment.

Re: Bash 5.0 released

#92
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.

On FreeBSD, as I recall, they don't want any GPL'd code in the base system, simply because the ideological goal is to have everything under BSDL. It's not that it affects other bits of the system though.

Re: Bash 5.0 released

#93
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.

Some application still requires bash, like wireguard

Re: Bash 5.0 released

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

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…

Awesome, thank you! This is super useful. I stand corrected.

Re: Bash 5.0 released

#95
post #90

Earlier quoted context omitted.

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?

A lot, because it's hard to derive meaningful conclusions from something that's used so relatively little precisely because of licensing concerns.

Anyway, with v2, the concerns were more vague - you'd have to accidentally link something GPLv2. With v3, even just shipping the binary signed with a private key on a platform that requires said key to load it, is enough to potentially force disclosure of that key (and that is by design of GPLv3 - it wants to kill the TiVo model).

Re: Bash 5.0 released

#96
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 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.

Re: Bash 5.0 released

#97
post #91

Earlier quoted context omitted.

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.

I tried python, bash and even C, none of them update /proc/self/comm when argv[0] is updated: dualbus@system76-pc:~$ cat argv0.c #include #include int main(int argc, char **argv) { FILE *fp; char buf[256]; // XXX :-) strcpy(argv[0], "XYZ"); //puts(argv[0]); fp = fopen("/proc/self/comm", "r"); fread(&buf, 1, 256, fp); buf[255] = '\0'; puts(buf); } dualbus@system76-pc:~$ gcc -o argv0 argv0.c -Wall dualbus@system76-pc:~…

You're looking at the wrong file. Setting argv[0] doesn't update /proc/self/comm, it updates /proc/self/cmdline.

demo.c:

    #include 
    #include 
    
    int main(int argc, char *argv[]) {
    	strcpy(argv[0], "frob");
    	sleep(100);
    }
Terminal 1:

    $ make demo
    cc     demo.c   -o demo
    $ ./demo --greppable
Terminal 2:

    $ ps aux|grep greppable
    luke     25858  0.0  0.0   2164   752 pts/0    S+   00:32   0:00 frob o --greppable
    luke     25931  0.0  0.0   8192  2356 pts/5    S+   00:32   0:00 grep --color=auto greppable
    $ cat -v /proc/25858/cmdline
    frob^@o^@--greppable^@$

Re: Bash 5.0 released

#98
post #53

Earlier quoted context omitted.

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

That command makes my eyes twitch. This sort of "download random stuff from internet, then pipe them to ruby/perl/python" madness should end, like right now. I'm assuming you're a reasonable person who knows what that commands does. Can you really not see how people can misuse commands like this to execute arbitrary code on people's computers, even experienced engineers if they carelessly copy-paste code like this. As a rule of thumb, to whoever reading this, please don't trust random strangers online and run their code. You never know. Always download code from trusted sources and check sha hashes. Piping anything else to ruby/perl/python is playing with fire.

Re: Bash 5.0 released

#99
post #66
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…

argv[0] is defined to be the "program name" by ISO C. What exactly this means is obviously platform dependent, and of course the caller can ignore it altogether and put something random there, but at that point they're the ones misusing the API in a way that breaks the spec.

Note that this is ISO C, not even POSIX. So ELF, Bourne shell etc are implementation details that are out of scope on this level.

Re: Bash 5.0 released

#100
post #91

Earlier quoted context omitted.

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.

I tried python, bash and even C, none of them update /proc/self/comm when argv[0] is updated: dualbus@system76-pc:~$ cat argv0.c #include #include int main(int argc, char **argv) { FILE *fp; char buf[256]; // XXX :-) strcpy(argv[0], "XYZ"); //puts(argv[0]); fp = fopen("/proc/self/comm", "r"); fread(&buf, 1, 256, fp); buf[255] = '\0'; puts(buf); } dualbus@system76-pc:~$ gcc -o argv0 argv0.c -Wall dualbus@system76-pc:~…

[deleted]
Post reply on HN