Is .Xdefaults-hostname wrong? In 2 ways? - Xwindows

This is a discussion on Is .Xdefaults-hostname wrong? In 2 ways? - Xwindows ; What is the function of the .Xdefaults-hostname file? By way of background, the X man page says: XENVIRONMENT ... If this variable is not defined, a file named $HOME/.Xdefaults-hostname is looked for instead, where hostname is the name of the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Is .Xdefaults-hostname wrong? In 2 ways?

  1. Is .Xdefaults-hostname wrong? In 2 ways?

    What is the function of the .Xdefaults-hostname file?

    By way of background, the X man page says:

    XENVIRONMENT
    ... If this variable is not defined, a
    file named $HOME/.Xdefaults-hostname is looked for instead,
    where hostname is the name of the host where
    the application is executing.

    What this doesn't say is *where* the file is. Does it reside on the
    client or the server?

    If it resides on the server-host, it could inform the server about
    client-host specific things - I can't think of any off-hand, but I'm sure
    it could be useful.

    If it resides on the client-host ... (where the application is running)
    .... why is it different than .Xdefaults?

    Are all members of the set .Xdefaults-hostname actually synonyms for
    ".Xdefault-remote"? Because truss(1) tells me xterm(1) reads exactly
    that file, .Xdefaults-hostname, no matter what remote it paints its window
    on.

    And, how do I tell my clients when I'm on my cygwin/laptop that they need
    to paint different windows than when I'm on my linux/desktop?


    Also, is it true that .Xdefaults-hostname is not processed by cpp?
    (maybe there's related logic there)?


    Are these two files documented in any other man pages?

    Thank you, folks.

  2. Re: Is .Xdefaults-hostname wrong? In 2 ways?

    "Charles T. Smith" writes:

    > If it resides on the client-host ... (where the application is running)
    > ... why is it different than .Xdefaults?


    Presumably to let you have different defaults on different
    X client hosts that mount the same home directory via NFS.

    The XENVIRONMENT variable is read by InitDefaults() in
    libX11/src/GetDflt.c, viewable at:
    http://gitweb.freedesktop.org/?p=xor...GetDflt.c#l176

  3. Re: Is .Xdefaults-hostname wrong? In 2 ways?

    In comp.windows.x, Charles T. Smith

    wrote
    on Sun, 01 Apr 2007 16:01:56 +0200
    :
    > What is the function of the .Xdefaults-hostname file?
    >
    > By way of background, the X man page says:
    >
    > XENVIRONMENT
    > ... If this variable is not defined, a
    > file named $HOME/.Xdefaults-hostname is looked for instead,
    > where hostname is the name of the host where
    > the application is executing.
    >
    > What this doesn't say is *where* the file is. Does it reside on the
    > client or the server?


    The client.

    >
    > If it resides on the server-host, it could inform the server about
    > client-host specific things - I can't think of any off-hand, but I'm sure
    > it could be useful.
    >
    > If it resides on the client-host ... (where the application is running)
    > ... why is it different than .Xdefaults?


    There is the possibility that the home directory could be mounted by
    several hosts (e.g., NFS server). That's at least useful.

    >
    > Are all members of the set .Xdefaults-hostname actually synonyms for
    > ".Xdefault-remote"? Because truss(1) tells me xterm(1) reads exactly
    > that file, .Xdefaults-hostname, no matter what remote it paints its window
    > on.
    >
    > And, how do I tell my clients when I'm on my cygwin/laptop that they need
    > to paint different windows than when I'm on my linux/desktop?
    >
    >
    > Also, is it true that .Xdefaults-hostname is not processed by cpp?
    > (maybe there's related logic there)?
    >
    >
    > Are these two files documented in any other man pages?
    >
    > Thank you, folks.


    I'll admit this is new to me, and I've been using X for awhile.
    However, .Xdefaults has been around for awhile as well; that's why I
    know it's on the client, and in any event truss proves it.

    --
    #191, ewill3@earthlink.net
    Useless C++ Programming Idea #7878218:
    class C { private: virtual void stupid() = 0; };

    --
    Posted via a free Usenet account from http://www.teranews.com


  4. Re: Is .Xdefaults-hostname wrong? In 2 ways?

    On Sun, 01 Apr 2007 10:31:08 -0700, The Ghost In The Machine wrote:

    > In comp.windows.x, Charles T. Smith
    >
    > wrote
    > on Sun, 01 Apr 2007 16:01:56 +0200
    > :
    >> What is the function of the .Xdefaults-hostname file?
    >>
    >> By way of background, the X man page says:
    >>
    >> XENVIRONMENT
    >> ... If this variable is not defined, a
    >> file named $HOME/.Xdefaults-hostname is looked for instead,
    >> where hostname is the name of the host where
    >> the application is executing.
    >>
    >> What this doesn't say is *where* the file is. Does it reside on the
    >> client or the server?

    >
    > The client.
    >
    >>
    >> If it resides on the server-host, it could inform the server about
    >> client-host specific things - I can't think of any off-hand, but I'm sure
    >> it could be useful.
    >>
    >> If it resides on the client-host ... (where the application is running)
    >> ... why is it different than .Xdefaults?

    >
    > There is the possibility that the home directory could be mounted by
    > several hosts (e.g., NFS server). That's at least useful.
    >
    >>
    >> Are all members of the set .Xdefaults-hostname actually synonyms for
    >> ".Xdefault-remote"? Because truss(1) tells me xterm(1) reads exactly
    >> that file, .Xdefaults-hostname, no matter what remote it paints its window
    >> on.
    >>
    >> And, how do I tell my clients when I'm on my cygwin/laptop that they need
    >> to paint different windows than when I'm on my linux/desktop?
    >>
    >>
    >> Also, is it true that .Xdefaults-hostname is not processed by cpp?
    >> (maybe there's related logic there)?
    >>
    >>
    >> Are these two files documented in any other man pages?
    >>
    >> Thank you, folks.

    >
    > I'll admit this is new to me, and I've been using X for awhile.
    > However, .Xdefaults has been around for awhile as well; that's why I
    > know it's on the client, and in any event truss proves it.



    Okay, I guess that's just the way it is.

    This all started when somebody on the fvwm mailing list suggested to me
    that a way to have different colored frames, depending on the client-host,
    was to start them with the -class property and then set different styles
    in the fvwm config file for different classes. Great idea which caused
    havok with my .Xdefaults file.

    So I had this great idea to have a different .Xdefaults-hostname file for
    each server... or to use cpp mapping of the same base file. oops... both
    wrong.

    I guess I'll just have to have a lot of redundant definitions in my
    ..Xdefaults-hostname file.


    On the other hand, maybe it would be quick and easy to define and
    implement a new convention ... like .Xserver-hostname. Or, to add cpp
    processing to .Xdefaults-hostname.





  5. Re: Is .Xdefaults-hostname wrong? In 2 ways?

    "Charles T. Smith" writes:

    > On Sun, 01 Apr 2007 10:31:08 -0700, The Ghost In The Machine wrote:
    >
    >> In comp.windows.x, Charles T. Smith
    >>
    >> wrote
    >> on Sun, 01 Apr 2007 16:01:56 +0200
    >> :
    >>> What is the function of the .Xdefaults-hostname file?

    ....
    > This all started when somebody on the fvwm mailing list suggested to me
    > that a way to have different colored frames, depending on the client-host,
    > was to start them with the -class property and then set different styles
    > in the fvwm config file for different classes. Great idea which caused
    > havok with my .Xdefaults file.


    You should have been advised to use -name or -title (can't remember
    which). Fvwm matches on more than one property.


  6. Re: Is .Xdefaults-hostname wrong? In 2 ways?

    "Charles T. Smith" writes:

    > On the other hand, maybe it would be quick and easy to define and
    > implement a new convention ... like .Xserver-hostname. Or, to add cpp
    > processing to .Xdefaults-hostname.


    You can use #include. See XrmGetFileDatabase(3X11).

+ Reply to Thread