FQDN hostname doesn't work

[hatifnatt]

Shell: bash
Operating system: Debian 7
Liquid Prompt version (tag, commit): master, bea53c0

Some of this changes still not in master
695d629#diff-69154cbf3b77aef00ad6c1c3527a7225L563

I think ${LP_HOST_SYMBOL} must be used everywhere inside case "$(_lp_connection)" instead of ${_LP_HOST_SYMBOL} I mean in ssh too.

Currently I have

$ echo $LP_ENABLE_FQDN
1
$ echo $LP_HOST_SYMBOL
\H
# but still '\h' in $PS1
$ echo $PS1
\[\]\t\[\] \[\][\[\]\u\[\]\[\]@\[\]\[\]\h\[\]\[\]:\[\]\[\]~\[\]\[\]]\[\]\n\[\]\$\[\]

[hatifnatt]

Also \H in Bash doesn't always contain fqdn, please see this bugreport. It depends on /etc/hostname. It's not liquidprompt fault but for better portability may be change the way how liquidprompt get hostname?

[dolmen]

Thanks for noticing the regression (that was introduced by d9cb55d) and the fix. I applied your fix with d5af671.

Also \H in Bash doesn't always contain fqdn, please see this bugreport. It depends on /etc/hostname. It's not liquidprompt fault but for better portability may be change the way how liquidprompt get hostname?

The bug is not in bash or in Liquidprompt. It is in /etc/hostname on that particular machine.

The right fix is to fix the operating system. Because this issue doesn't affect only LiquidPrompt. And because portability doesn't imply to workaround all incorrect system configurations.

It is much easier to report the issue to the sysadmin to fix it (especially if you already have the credentials to apply the fix yourself) than for me to invent some code that will be very OS dependent and have portability issues.

Obviously the bash maintainer has the same position as no such hack exists to make \H work on broken systems.

[hatifnatt]

Thank for fix!
There is no bug in my /etc/hostname \H work as expected only if this file contain FQDN like host.domain.tld.
Bash manual:

\h     the hostname up to the first `.'
\H     the hostname

But using short name in /etc/hostname is a valid option.
For the reference Debian 7 man hostname:

/etc/hostname Historically this file was supposed to only contain the hostname and not the full canonical FQDN. Nowadays most software is able to cope with a full FQDN here. This file is read at boot time by the system initialization scripts to set the hostname.

And futuremore Ubuntu 12 man pages:

/etc/hostname This file should only contain the hostname and not the full FQDN.

Ubuntu 16 man pages same as Debian:

/etc/hostname Historically this file was supposed to only contain the hostname and not the full canonical FQDN. Nowadays most software is able to cope with a full FQDN here. This file is read at boot time by the system initialization scripts to set the hostname.

CentOS manual about how to set up FQDN hostname:

The FQDN (Fully Qualified Domain Name) of the system is the name that the resolver(3) returns for the host name, such as, ursula.example.com. It is usually the hostname followed by the DNS domain name (the part after the
first dot). You can check the FQDN using hostname --fqdn or the domain name using dnsdomainname.

You cannot change the FQDN with hostname or dnsdomainname.

The recommended method of setting the FQDN is to make the hostname be an alias for the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the hostname was "ursula", one might have a line in /etc/hosts
which reads

  127.0.1.1    ursula.example.com ursula

Long story short: I'm using short name in /etc/hostname and with short name \H doesn't work as expected.
My current workaround to define _LP_FQDN_SYMBOL=$(hostname -f) in ~/.config/liquidpromptrc

Here I have found information that \h and \H initializing at shell startup, so if _LP_FQDN_SYMBOL="\H" will be changed to _LP_FQDN_SYMBOL=$(hostname -f) it's will be same behavior as \H implies. Yes, I know it look ugly but I don't know better solution without changing Bash code.

Currently for everyone who use short hostname in /etc/hostname LP_ENABLE_FQDN=1 will have no effect.

[dolmen]

Thanks for this extensive research.
\H is in fact not documented as reporting the FQDN. So you have convinced me we have to do something. However hostname -f may not be an universal solution: there is portability issues with the hostname command.

[hatifnatt]

Sure use Bash internal variable is much better than external program like hostname but 100% universal solution is hard to achieve. IMHO there is 2 possibilities:

1. Use hostname -f which available on most modern *nix OS, it work, for example, on CentOS 7, Debian 7-8, FreeBSD 10, but -f key isn't available on older OS.
2. Write some code (script or function) which will use hostname or hostname -s which way more portable (it work on FreeBSD 6.1) and from there this code will try to get FQDN. For example here is Sendmail script which check hostname.

One more idea, add something like $LP_FQDN_CMD which by default will be hostname -f if it won't work users can fix it to something which will work on their machine.

[Rycieos]

I read all the links here, lots to think about. I also tested this on Zsh, it shows the exact same behavior as Bash. Here are my thoughts:

This is obviously a bug or, more likely, a limitation in both Bash and Zsh. The documentation isn't super clear, but it seems that there are two different things here:

• The hostname, provided by gethostname, which may or may not have multiple "parts" in it. Bash and Zsh use this, raw with \H/%M, or truncated at the first . with \h/%m. The long version seems to be provided by the hostname command, and the short version by the hostname -s command.
• The FQDN, provided by getaddrinfo, is not used by Bash or Zsh at all. This version takes into account things in /etc/hosts and DHCP allocations. This seems to be provided by the hostname -f command.

What I think this boils down to is a misunderstanding of what the "long hostname" was when the FQDN option was built into Liquidprompt. The feature works exactly as intended in Bash and Zsh, and therefore also in Liquidprompt, but for Bash the documentation is confusing, and in Liquidprompt it was named incorrectly. The "FQDN" feature in Liquidprompt does not supply the FQDN, as this issue shows. That isn't to say that having a FQDN feature is a bad idea, and I think Bash and Zsh should have such a feature, but they don't.

I also think Liquidprompt should have that as a feature as well, but there are two problems with this.

• Having 3 versions of hostname instead of 2 means an API/config change.
• hostname -f isn't supported on all our platforms, I know at least SunOS doesn't support it.

That being said, here is my plan:

• Add support for FQDN in Liquidprompt, probably using hostname -f. On systems that don't support it, fall back to \H/%M.
• Add a new option in Liquidprompt that generates the \H/%M version. Obviously this code already works, it just needs an option named correctly to go with it.
• Since the options are changing, this needs to happen in 2.0

[Rycieos]

I'm moving this to v2.1, since v2.0 is getting large and long already, and this mostly depends on #651, which really should wait until after v2.0.