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.

Also tried to fall-through to the user shell:

screen -t "Director Process" /bin/bash -c ./bin/director config-gpgpu.xml $HOSTNAME
screen -t "Director Process" /bin/bash -c ./bin/director config-gpgpu.xml \$HOSTNAME
screen -t "Director Process" /bin/bash -c ./bin/director config-gpgpu.xml '$'HOSTNAME

However, for my purposes 'localhost' seems to be working, so this is not a blocker to me. But if this is fixed (or will be) in a newer release, I'd like to know about it.

If this is already fixed in a new version, I'll try installing it.
I'm using this version

        Screen version 4.06.02 (GNU) 23-Oct-17

which wasn't on the list of options.