Maybe I’m doing something wrong, but Haiku nightly bash does not appear to be automatically loading /boot/home/.bashrc for non-interactive shells, even though the bash documentation says that it should be doing this.
$ head /boot/home/.bashrc
echo 'Hello from .bashrc!'
$ bash -c 'sleep 1'
$
Fortunately, Haiku bash does appear to recognize $BASH_ENV and apply that to non-interactive shells, so when I manually configure this variable, then bash will load the referenced configuration file path:
$ BASH_ENV=/boot/home/.bashrc bash -c 'sleep 1'
Hello from .bashrc!
$
This bugs me too. It seems to be a divergence from posix that was done to make our package system happy. Your dotfiles go in some directory in one of the config paths. I forget which one. And they drop the “.” at the beginning so .bashrc becomes bashrc. It’s been awhile and Im recalling from volitile memory, so I could be a bit off. Someone please correct me. I don’t like it. It is counterintuitive. And it’d be nice to see this fixed after R1.
Nothing wrong with diverging from a standard, though such distinctions should be abundantly documented. In the --help output. In man pages. On the wiki.
I don’t see how you interpret that document. The way I read it, a non-interactive bash process should work exactly like you see it working. It has been that way for decades, and i see it as a feature, so maybe my expectation colors my reading of the document.
It’s not because of package management this time. We just think putting all config files at the root of the user directory is a stupid thing. We put them in home/config/settings instead. And we remove the . prefix because it is a hack to simulate hidden files, and your settings are not something that should be hidden.
So I’m going to call the “it’s not a bug, it’s a feature” for once.
I have to admit, that threw me for a while. I didn’t expect to have a config file prior to creating one, so it didn’t make any sense to search for it. I think when I eventually discovered the trick that had been played on me, it was by examining text strings in the executable.