Wireshark-bugs: [Wireshark-bugs] [Bug 6353] Wireshark should respect freedesktop.org XDG Base Di

Date: Sat, 17 Sep 2011 14:54:26 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6353

--- Comment #2 from Igor Poboiko <igor.poboiko@xxxxxxxxx> 2011-09-17 14:54:25 PDT ---
(In reply to comment #1)
Thanks for your reply. Please note that I'm just an ordinary user who wants his
config files to be stored in one place and who don't want to have messed $HOME
(even with hidden files); so the things I write is my opinion and nothing more.

> I sincerely hope no part of any GUI desktop environment is solely responsible
> for setting any of those environment variables, so that they're not set unless
> you're running from a GUI session, as not all components of Wireshark
> necessarily run in a GUI session, and it would be Truly Horrible if, for
> example, Wireshark and TShark were to find the Wireshark preferences file in
> separate directories.  (TShark, for example, should not only be runnable from a
> terminal emulator fired up from a GUI session, it should be runnable from an
> ssh session and, heck, it should be runnable if you hook a VT100 up to a serial
> adapter and log in through getty.  Yes, I'm serious.)

You're right. But there's nothing about GUI in this specification. Moreover,
talking about XDG_RUNTIME_DIR, it is said that "The lifetime of the directory
MUST be bound to the user being logged in" (so it doesn't bind to GUI session).

AFAIR in most cases these variables aren't set (because no one cares about
setting them). It means that all applications which supports spec should use
"$HOME/.config". And in that case (obviously) configs for TShark and Wireshark
won't be separated.
The users who want to change it should also keep in mind that these variables
aren't gui-specific and change it somewhere around their "$HOME/.bashrc" for
these variables to be already set after logging in (there's actually not so
many places where they can set it); in that case configs won't be separated
too.


> Is there a rationale document for this specification, to clarify what some of
> the terms in the document mean (for example, what distinguishes "configuration
> files" from other "data files"), and to indicate into which category files such
> as user-provided plugins fall (are they "data files"?).

I don't think there is such a document. I think it's up for you to decide which
files do you concider to be "configs" and which - "data". And I don't have
problems with distinguishing them. I mean, in most cases it's easy and I can't
imagine such a situation where these things can't be distinguished. Of course I
may be wrong.
(and talking about user-provided plugins: yes, I think it's "data". It
definitely doesn't look like "runtime", "configs" or "cache").

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.