How to set HOSTNAME in zsh?

Question

In Bash, which sets $HOSTNAME for you, I was able to calculate the total length of prompt line simply by using something like: PS1_length=$((${#USER}+${#HOSTNAME}+${#PWDNAME}+12+${#PS1_GIT}))

It was useful e.g. when creating the fill-line like this:

However zsh fails to set $HOSTNAME correctly and I can't think of a way to emulate the similar behavior in it — any thoughts?

Solution 1

You should just set

HOSTNAME=$(hostname)

in your ~/.zshrc

Or as Caleb pointed out there is a variable HOST set, so to keep your prompt portable you could also do:

HOSTNAME=$HOST

Solution 2

zsh prompt expansion lets you do that prompt without having to do any calculation:

PS1='%$COLUMNS>╡>%F{cyan}╔╡%F{red}[%n]%F{cyan}:%F{yellow}[%m]%F{cyan}➾%F{green}[%~]%F{default}$PS1_GIT%F{cyan}${(l:COLUMNS::═:):-}%<<
╚═╡%F{default}'

Explained:

• %$COLUMNS>╡>: right-truncate to $COLUMNS (a variable set dynamically by zsh to the width of the terminal) the part up to the next %<<.
• %F{color}: set the foreground colour
• %n, %m, %~: user name, machine name (hostname up to the first dot), current directory with ~-named-dirs.
• ${(l:COLUMNS::═:):-}: left-pad the empty string (${:-}) to $COLUMNS length with ═ characters.

%m is like ${HOST%%.*}. If you want the full host name ($HOST), use %M instead.

Solution 3

You're using the wrong variable name. The $HOSTNAME environment variable is often set by the host system's init routines, but not always. In the context of a ZSH profile you should use the environment variable $HOST which is explicitly set by the shell. From man zshall:

PARAMETERS SET BY THE SHELL
    […]
    HOST The current hostname.

Note in that list that $HOSTNAME is not something that ZSH attempts to set, it is only set or not on the whim of your system's init system.

Also note that $HOST is not something you should use in cross platform shell scripting if you are hoping for portability to other shells—in that case the hostname binary is likely your best bet—but in the context of a ZSH profile the shell's own variable is the most appropriate thing to use.

Comments

[Anthon]

@Janis I have zsh 5.0.2 and HOSTNAME is not set, I had to do that myself. Did you start zsh from another shell that exported that variable?

[tcoolspy]

If you want HOSTNAME to be set you should get your system to do it properly. The shell's rc file is not the best place for that and if you don't want to depend on the system the shell has a proper environment variable for you to use ready to go without this hack.

[mikeserv]

@Caleb - How is setting an environment variable in the shell's environment file with the output of the eponymous basic system utility supposed to be a hack exactly? You might argue that it should be set in profile - zsh doesn't honor that anyway, and the various flavors of zshinit vary widely even on the names of sourced files used during the process. One thing they all seem pretty much to agree on, however, is .zshrc (in some form or another)

[tcoolspy]

@Anthon The features and syntax of the ZSH prompt are not particularly portable to other shells anyway. In this context why would you not just use the variable that ZSH expects and has setup for you? Why set another one at all? Incidentally using HOSTNAME in this context does cause a portability problem if you try to pass your prompt off on somebody else. They would need to setup their profile to match your variable renaming rather than just being able to drop in usage of HOME.

[Anthon]

@Caleb because then the OP would have prompt that would only work on zsh, and by the time he decides to move back or move onwards (for whatever reason) he has to adapt that again. I assume the OP is more concerned about being able to go back to bash than handing over things to someone else. At least I was when I tried zsh.

[Gilles 'SO- stop being evil']

@Anthon Prompt escapes in bash and zsh are completely different, so there's no point in looking for compatibility there.

[Stéphane Chazelas]

uname -n would be a better bet.

[Stéphane Chazelas]

@tymac, zsh wouldn't be doing that translation AFAIK. Possibly your terminal emulator or the gethostname()/uname() API does. Testing here with GNU terminal, those characters (even though they are double-width) don't seem to be causing a problem when used in the current working directory at least (%~ above).

[Stéphane Chazelas]

@tymac, what's the output of uname -n | od -tx1 -tc? You might want to ask a separate question BTW, as it has little to do with this one.

[Edison]

Here you go :) unix.stackexchange.com/questions/351097/…

[Abdel Karim Mateos Sanchez]

Quickly answer, bad answer. Not zsh guidelines