<div dir="ltr"><div dir="ltr">On Thu, Mar 30, 2023 at 2:19 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 30, 2023 at 11:30 AM Vanessa Freudenberg <<a href="mailto:vanessa@codefrau.net" target="_blank">vanessa@codefrau.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.</div><div><br></div><div>Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer. </div></div></blockquote><div><br></div><div style="font-size:small">Then we should fix it, and document the intent of the primitive :-)  Your definition makes sense to me.</div></div></div></blockquote><div><br>I got confused, the primitive actually does what it's supposed to (on macOS at least). We're just not using it by default, that was Tim's observation.</div><div><br></div><div>Vanessa</div></div></div>