Re: Who the heck uses HOSTNAME?
[ Busy summer, I'm behind on everything... ] On Tue, Jul 11, 2017 at 10:44:13PM -0700 I heard the voice of Greg A. Woods, and lo! it spake thus: > > I have been using HOSTNAME since day one, because I shared my > .ctwmrc across many hosts, and I never wanted to worry about names > which might be the same at different sites. (esp. for sites which > used generic hostnames, such as "mail", "www", etc., as the real > host's name) Interesting. I don't actually remember the last time I saw a system where the defined hostname wasn't qualified; must be at least a decade, and I wouldn't be surprised to find it was last millennium. I'd almost be even more surprised to find a setup like that, which also had DNS and resolver config setup so that the right FQDN came out the far end of a lookup. I wonder if that's mostly a function of the timeperiod, or if it still varies in different social environments. > These days though I don't wander far from home with my X11 setup > (unless it's the one on my laptop). I don't know what CLIENTHOST > would resolve to on that system though. Probably not what I use, > which is the system hostname with ".local" appended to it. Actually, from here, I'd guess it would be; your Message-Id and the headers from your local smtp instance all agree in calling your system 'more.local', and I'd generally assume those programs just took the hostname as given. Easy enough to check; can just use `-k` to leave the temp file of m4 defs around, so you can run an invocation like `ctwm --cfgchk -k` (cfgchk serving as a convenient way to run it without trying to take over anything and exit right away), and seeing what's in the filename it gives you. > One thing I have often wondered about (well, only so often as I've had > to edit my .ctwmrc to add something for a new system, etc.) is whether > or not it might make sense to somehow expose some or all of the > environment variables to the M4 processing We'd have to actually do all the proper value escaping we should already be doing (but aren't of course) if we tried that ;) You might be able to do something with esyscmd() and echo or env in m4 to pull in or conditionalize on env vars... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Who the heck uses HOSTNAME?
I do use (or rather did use) SERVERHOST: dnl WINDOWMETA is the window manager meta key: dnl windows if available, Alt otherwise. dnl HRDWNDWMETA is optional, and can only be the windows key. dnl Use this if it would interfere with application keys if it were Alt. ifelse( SERVERHOST, [moon], [define(WINDOWMETA, m1)], [define(WINDOWMETA, m4)])dnl define(HRDWNDWMETA, m4)dnl My one display, "sun" (it was a Sun 3/50) had more keys on its keyboard than the other, "moon" (it was a HP 700 dedicated X terminal with pc keyboard). And my key bindings are in terms of WINDOWMETA and HRDWNDWMETA. But that was a long time ago... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Who the heck uses HOSTNAME?
So, who's ever looked through all the weird and wacky vars we hand into the m4 processor, that you can use to do unnatural things to your config? There are 3 hostnames we pass in. One is CLIENTHOST, which is the machine where ctwm is running. That come out of gethostname(3), which is just getting the system's hostname. Straightforward. The second is SERVERHOST, which is the machine where the X server is running. We get that by poking through $DISPLAY and finding a hostname there (or using a copy of CLIENTHOST, if that's a local-ish thing like ":0" or the like, which probably covers 99.99% of actual running systems nowadays). OK; no problems here. But then there's HOSTNAME. What the heck. The manual says "The canonical hostname running the clients", which tells... absolutely thing. It winds up happening via calling gethostbyname(3) on CLIENTHOST, and then pulling the h_name out of the response. Well, what is that? That's probably going to vary depending on the system, and just where the response comes from. Maybe it comes from the hosts file? Then I think it's the first entry on the line, so maybe it can be considered the more 'real' name of the system, when its hostname is set to an alias of that (what? why? who cares?). Or then there's DNS, which from what I can tell means it may be transformed by 'domain' or 'search' directives in resolv.conf? After getting a response, anyway. Or happens if the lookup winds up going via NIS. Whatever other resolution methods it may use. And if it doesn't get a name from any of those, it just quietly falls back to using CLIENTHOST verbatim anyway. Ever had a system where [re]starting ctwm bizarrely pauses for a dozen seconds or so? Guess what; this is why. We block startup on [potentially] doing a DNS lookup of the client's configured hostname. So if you don't have working DNS, or have a hostname that's not in DNS (especially one that would be off in a DNS tree that purportedly exists with unreachable nameservers, so we have to wait on timeouts), twiddle your thumbs a while. Does that add enough value to be worth having that block-y a thing in the startup path? Or should I just dump it over the side into deep water, and just leave HOSTNAME as a copy of CLIENTHOST? (yeah, I'll bet you thought I was through with cackling over my keyboard looking for things to break... gotcha!) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
