Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more portable way of getting hostname in Layout.OnHost #899

Closed
cacharle opened this issue Aug 6, 2024 · 3 comments · Fixed by #901
Closed

Add more portable way of getting hostname in Layout.OnHost #899

cacharle opened this issue Aug 6, 2024 · 3 comments · Fixed by #901

Comments

@cacharle
Copy link

cacharle commented Aug 6, 2024

It seems like it currently only checks for the HOST environment variable. It would be nice if it could check /etc/hostname or other environment variables.

Maybe use Network.HostName? https://hackage.haskell.org/package/hostname-1.0/docs/src/Network-HostName.html#getHostName

h <- io $ getEnv "HOST"

@geekosaur
Copy link
Contributor

The commit log may be of interest (it looks like I added this before we moved to GitHub, so there's no PR and the commit description is a little wonky):

commit c691988bbfe4c267a2e562689cc9640e53a1ec88
Author: Brandon S Allbery KF8NH <allbery.b@gmail.com>
Date:   Tue Mar 20 03:09:12 2012 +0000

    XMonad.Layout.OnHost allows host-specific modifications to a layout, which
    
    is otherwise very difficult to do.  Similarly to X.L.PerWorkspace, it provides
    onHost, onHosts, modHost, and modHosts layout modifiers.  It attempts to do
    smart hostname comparison, such that short names will be matched with short
    names and FQDNs with FQDNs.
    
    This module currently requires that $HOST be set in the environment.
    You can use System.Posix.Env.setEnv to do so in xmonad.hs if need be.
    (Properly, this should be done via the network library, but I'm trying to
    avoid adding that dependency.)  An alternative would be to shell out to
    get the name, but that has considerable portability hurdles.

The hostname package doesn't look terrible, but any additional dependency requires some discussion. (Probably not much in this case.)

@slotThe
Copy link
Member

slotThe commented Aug 7, 2024

Would shelling out really be that much of a pain in terms of portability? I'd guess (well, hope :)) that all systems we still support have a hostname in path.

In either case, the relevant code in that package seems to small (most of it is MS Windows stuff) that vendoring sounds like a better option to me, should we choose to go down that route:

type HostName = String

foreign import ccall unsafe "gethostname" gethostname :: CString -> CSize -> IO CInt

getHostName :: IO HostName
getHostName = allocaArray0 size $ \cstr -> do
        throwErrnoIfMinus1_ "getHostName" $ gethostname cstr (fromIntegral size)
        peekCString cstr
    where size = 256

@geekosaur
Copy link
Contributor

Probably re vendoring. Back then there were issues both with getting a hostname (on some systems you had to parse uname -a output) and with gethostname only working if the network was up, but in 2024 I'm not sure either problem exists any more. Suppose we'll find out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants