Re: [screen-devel] [bug #57628] Can't access $HOSTNAME in screenrc file

[Neal Fultz]

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 <address@hidden> 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/