Instead of special-casing HOSTNAME, I would prefer a more general solution. If I needed to be able to read and set HOSTNAME to something else inside a screenrc such that it applied to new windows, it's not very straightforward to me.
I can get 80% of the way there by something like eval "readreg h /etc/hostname" "register g ':setenv HOSTNAME '" "register i '\r'" "paste ghi j" command "process j" but this is ugly and wastes a few registers, and requires knowing 6 different commands. I couldn't find a nice way to just put a register into an environment variable. Env to register is easy: register s $SHELL It would be nice to have the reverse, maybe add a -r (for register) flag to setenv, giving this solution: readreg h /etc/hostname setenv -r HOSTNAME h On Sun, Jan 19, 2020 at 3:42 PM anonymous <invalid.nore...@gnu.org> wrote: > Follow-up Comment #5, bug #57628 (project screen): > > [comment #4 comment #4:] > > $HOSTNAME (as I see in bash) seem to be provided by > > shell expansion logic and are not true environment > > variables set in environment. > > [...] > > You can see this by running 'env' command and observing > > that both of them are missing there. > > I'm pretty sure this isn't true and that "env" just doesn't have $HOSTNAME > in > its environment because $HOSTNAME is not (or rather is no longer) exported > by > default. > > This is how I checked my assumption: > - "env | grep HOSTNAME" works after "export HOSTNAME" (so at least it > *behaves* like a normal environment variable) > - the man page doesn't say anything special about $HOSTNAME > - I can't find any special handling in the bash sources. > > The patch is very short, but I thought I should point this out because it > was > brought up as a rationale. I also wonder if the patch is the right thing to > do. Wouldn't it be surprising for users to special-case a normal > environment > variable? An entry in the CHANGES file of bash shows that bash consciously > decided not to export it. > > > _______________________________________________________ > > Reply to this item at: > > <https://savannah.gnu.org/bugs/?57628> > > _______________________________________________ > Message sent via Savannah > https://savannah.gnu.org/ > > >
