Consider supporting XDG Base Directory Specification?

[ChristianTacke]

The XDG Base Directory Specification has some rules for specifying where to search for a config file.

It basically means to search for config files in ${XDG_CONFIG_HOME} (or $HOME/.config it it's not set), and $XDG_CONFIG_DIRS (defaulting to /etc/xdg).

Usually, programs define a subdirectory for their config in those directories. For example ~/.config/git/.

I think, it would be nice, if ugrep would support this as well.

• Declutter my $HOME by moving .ugrep to .config/ugrep/config
• Allow a system wide (admin configurable) default config file: /etc/xdg/ugrep/config

If ugrep never ever will have more config files, one could also use ~/.config/ugrep.conf, and /etc/xdg/ugrep.conf.

[genivia-inc]

That could work, but I do not agree that when XDG_CONFIG_HOME is unset it should default to $HOME/.config/. That should be $HOME, because using $HOME/.ugrep doesn't break current use scenarios. This is also the default for many other utilities such as vim i.e. $HOME/.vimrc.

[ChristianTacke]

The idea is to search in order, and use the first one found and ignore the others:

1. ~/.config/ugrep/config (really ${XDG_CONFIG_HOME}/ugrep/config)
2. ~/.ugrep (for backward compatibility)
3. /etc/xdg/ugrep/config as a system fallback (really ${XDG_CONFIG_DIRS}/ugrep/config–note: I think, XDG_CONFIG_DIRS is a list of directories)

If you need inspiration on handlinging things backward compatible / etc: Check the git-config manpage (section "FILES").

Please

• Obey the XDG specs and default ${XDG_CONFIG_HOME} to ~/.config. If you want some backward compatibility, make it explicit (see above)
• Do not put files with a . prefix in the XDG dirs. No need to hide files there.

[genivia-inc]

Thanks for the reply with details. I have a few questions:

• when does this ${XDG_CONFIG_HOME}/ugrep/config file typically gets created? By the user? Or when ugrep is installed?
• is step 3 necessary? The ug config is entirely optional. I can't think of a reasonable config file to store in /etc/xdg/ugrep/config, i.e. that config file would be empty to use the ug defaults.

Furthermore, the --config=FILE option should not get affected by XDG_CONFIG_HOME, which means that FILE should always be loaded from the working directory or from the home directory. This means making an exception for FILE when it is equal to .ugrep (e.g. option --config=.ugrep or just --config) to load ${XDG_CONFIG_HOME}/ugrep/config. However, this not logical when ${XDG_CONFIG_HOME}/ugrep/config is checked before the home dir. I think we should make it the last to check.

I'm still worried about making this all more confusing for users. The use of config files differs from other tools in making searches context-sensitive using one or more configs in a working directory, e.g. --config=source-only uses a source-only config file. If not in the working dir, then we check the home dir. This should never visit ${XDG_CONFIG_HOME}/ugrep/config.

[ChristianTacke]

Let me start with --config. I guess, FILE is just a path that is directly usable. Like ls -l FILE would work as well, right?
Then change the order from above.

STOP at the first one that is found / given.

1. --config: If the commandline option is given, use it and do whatever you have done until now. No change. STOP here.
2. ${XDG_CONFIG_HOME}/ugrep/config. If it's there, use it, STOP here.
3. ~/.ugrep. If it's there, use it, STOP here.
4. ${XDG_CONFIG_DIRS}/ugrep/config. If it's there, use it, STOP here.

About ${XDG_CONFIG_HOME}/ugrep/config: It is created by the user, just like ~/.ugrep. It's just an alternative path. People can choose whatever they like better. XDG people use the XDG path. "old school" people use the .ugrep path.

About /etc/xdg/ugrep/config. Usually there is none. No need to install one or etc. The idea is: If as an admin, I would like to change the ug settings for all my users, I can do so by creating that file. This is a purely local customization by the admin. And (see order above) any local user can easily override it. If that user doesn't like the sysadmin settings and wants the builtin defaults, they can even create an empty ~/.config/ugrep/config (or ~/.ugrep).
(My use case: I have a personal VM with a few service users. Instead of copying my preferred config to each user's ~/.config/ugrep/config. I'd just install one global with my preferences.)

[ChristianTacke]

Having read your last paragraph again, I have one alternative idea for point (1) (handling --config).

• If FILE exists directly, use it. For example to handle local config files. STOP here.
• if FILE has no / in it, let's consider it something like a "profile" name. And then $XDG_CONFIG_HOME/ugrep/ could be your profile storage space? So if $XDG_CONFIG_HOME/ugrep/FILE exists, use it, stop.
• Look at FILE relative to $HOME (if it exists, use it, STOP here). I actually don't like this one (it promotes cluttering $HOME). If this was the previous behaviour, then we need it for backward compatibility.

[ChristianTacke]

Having written all of this, I can see, that this can become confusing. And it might feel "over engineered". I can fully understand that.

That said: I fully understand, if you don't want to accept the whole XDG thing. Or maybe you find some small parts that you like and use those wihtout making things too complicated?

[genivia-inc]

The ugrep v7.3 version source code has a compile-time flag WITH_XDG_CONFIG_HOME to enable this feature, when built from source. In src/ugrep.hpp:

// #define WITH_XDG_CONFIG_HOME

When enabled, it checks for ~/.ugrep then uses the $XDG_CONFIG_HOME/ugrep/config file when present. This only happens when the default config is used, i.e. with ug or ugrep --config.

I left it out for now, because once enabled I can't go back, which worries me, because it is not entirely clear if this should work with any --config=FILE or just the default .ugrep config. In that case, $XDG_CONFIG_HOME/ugrep could be a directory with multiple config files for ugrep --config=FILE to use FILE there (if not in the working directory). However, that needs to include $XDG_CONFIG_HOME/ugrep/.ugrep (not config) that is not confusing and not clashing when a user specifies ugrep --config=config where he/she would mean to use specifically config (not .ugrep). But if the convention is to never use dot files in $XDG_CONFIG_HOME/ugrep/ then we're not compliant (not surprising, because config files are used not only for preferences, but to specialize searching with config specs).

[chrisaq]

Thank you!

I think most of us would be happy to be able to get ~/.ugrep into $XDG_CONFIG_HOME/ugrep/, but I understand how --config=FILE can be a bit of an issue.

Since backwards compatibility and avoiding unexpected behavior is most important, you can get around it by requiring an env var to be set. This isn't great, but it's an ok compromise.

So:

if UGREP_CONFIG_DIR is set:
  DEFAULT_CONFIG = $UGREP_CONFIG_DIR/config
else:
  UGREP_CONFIG_DIR = $HOME
  DEFAULT_CONFIG = $UGREP_CONFIG_DIR/.ugrep

if '--config':
  read $PWD/.ugrep
  read $DEFAULT_CONFIG

if '--config=FILE':
  read $PWD/FILE
  read $UGREP_CONFIG_DIR/FILE

If you want to avoid the env var, but still want xdg and no changes to current behavior, you can keep the default to reading ~/.ugrep and only look at $XDG_CONFIG_DIR/ugrep/config if it doesn't exist. Preferably with a warning message if $XDG_CONFIG_DIR is set, but you still read ~/.ugrep.

People setting either the env var or keep their only config in $XDG_CONFIG_DIR/ugrep/config would be actively opting into a new config setup, and by that also opting out of the previous expected behavior.