[donatj]

This has me lamenting just how fiddly it really is to implement a standalone "cd" that isn't a builtin.

I am certainly there are a whole host of security reasons not to, but it sure would be handy if a parent process could easily just read the final state of all environmental variables of a child process and possibly integrate them back into its own.

Shells could just have a syntax for accepting sub process environmental variables. I'd propose something easy like starting a line with = absorbing all set environmental variables.

We could build a custom cd tool, "custom-cd-bin" in this example and all that would need to do is change the PWD variable.

  $ =custom-cd-bin ./foo

Maybe this will be something for my dream shell I'm never going to actually get around to building. It would take something gross like wrapping setenv though

[ffsm8]

Mmh, that's kinda... Exactly what `source` is.

It's just rarely used beyond dotfiles because... Well.. it inherits all variables etc

https://docs.vultr.com/how-to-use-the-source-command-in-bash

If you want to make the transition explicit at the end of the script, you can do what the sister comment did, essentially

"source <(bash the-script|grep -Pom "xx inherited variables\n(.*?)\n yy inherited variables")"

[donatj]

Not at all. The source command is basically just an include, executing shell commands in the current scope.

I'm talking about inheriting the environmental state of any subprocess. You can't source a binary.

[ffsm8]

Can you tell me an example where this has a difference in behaviour?

Basically somewhere that source would not behave as you wanted?

I'm also uncertain what you mean wrt a binary. A binary will only have the environment variables available to the shell it's executed in - or do you mean that you'd also want it to inherit variables the binary itself might read from disk via .env files or similar?

[linsomniac]

So you're thinking something like before the wait(2) reading /proc/$PID/environ ?