Hacker News Reader

Comment by matheusmoreira | Hacker News Reader

Well, what exactly is their role? Is there a limit to what we can do with these things?

To test a little programming language I made, I created a testing framework with bash and coreutils. I felt guilty about not using a "proper" language at first but it works so well. In parallel too.

I found that the the only thing I couldn't test was the argv[0] of the program. No matter how much I twisted the programs, I couldn't get them to do exactly what I wanted. So I sent a feature request and a patch to coreutils to give env this feature:

https://lists.gnu.org/archive/html/coreutils/2023-08/msg0006...

Looks like it's gonna make it in. A new feature for this old program.

View on HN

https://cr.yp.to/ucspi-tcp/argv0.html

Not part of coreutils though. I want to keep my dependencies to a minimum. The GNU coreutils are ubiquitous.

Hey if this makes it congratulations! I've never contributed to something so ubiquitous before but often thought how satisfying it'd be.

Like in years down the line, maybe as you retire and hang up your keyboard, you could sit back and smile as you realise your code is still deployed on millions, possibly billions of devices? That the code could far outlast 99.9% of code code anyone has ever written?

Well, I don't know if they're gonna use my patch. I reported a bug to gpg once and sent a patch in but in the end the maintainer rearchitected the code and gave me attribution. Perhaps they require copyright reassignment?

I can't deny I'm gonna be really happy if they do use it.

We generally give credit if at all possible. Even if a patch is extensively adjusted, we'll commit under the original author's name

You could’ve used bash’s exec which allows specifying argv0

I did try it. Didn't work in combination with env.

  # Sets PWD and SHLVL and the latter apparently can't be unset
  env -i VARIABLE=value bash -c 'exec -a program ./program'

  # Sets env's argv0, not my program's
  bash -c 'exec -a program env -i VARIABLE=value ./program'

  # SHLVL still set
  env -i bash -c 'unset SHLVL; unset PWD; exec -a program ./program'

  # SHLVL and _ still set
  env -i zsh -c 'unset _ HOME PWD LOGNAME SHLVL OLDPWD; ARGV0=program

The original discussions, linked from my post:

https://lists.gnu.org/archive/html/coreutils/2023-03/msg0000...

https://lists.gnu.org/archive/html/coreutils/2023-03/msg0001...

Why do you need to remove all of these from the environment?

To test my programming language. It's a freestanding lisp interpreter that doesn't link to libc. I wrote the code that handles the environment variables and in order to test it I needed full control over the program's inputs including its environment. The env utility provides this control by emptying the environment and setting only the variables I specify, solving 90% of the problem. Only thing I still can't control is argv[0]. With this new feature upstreamed, my test suite will be complete.

Here's the code if you wish to take a look:

https://github.com/lone-lang/lone#testing

https://github.com/lone-lang/lone/blob/master/scripts/test.b...

Without env -i, the folllowing tests would not be possible:

https://github.com/lone-lang/lone/blob/master/test/linux/env...

Glibc provides ld.so which can:

    --argv0 STRING        set argv[0] to STRING before running

Maybe that could be useful?

I did not know about that possibility! It requires glibc and its dynamic linker though, doesn't seem to be as widely available as the GNU coreutils. I developed lone inside Termux: it does not have ld.so but does have env. There's a GNU binutils ld but it did not recognize the --argv0 option when I tried it.

ld.so is the dynamic linker. It is always used when invoking a dynamically linked program but you can invoke it manually which allows you to specify optionsfor the linker. But the name and path you need to invoke depends on the architecture and possibly distro, e.g. for amd64 these days its

/lib64/ld-linux-x86-64.so.2 --argv0 argv0isalie yourprogramm

ld is the (not dynamic) linker. It doesn't invoke your program at all.

Reply on news.ycombinator.com