Inconsistent naming of config files #308

New Issue

adam · 2025-12-29T01:21:54+01:00

adam commented

2025-12-29 01:21:54 +01:00

Originally created by @txr13 on GitHub (Mar 15, 2018).

While looking over my config files and considering setting a CONFIG_D, I noticed an inconsistency, and I'm wondering if it's intentional or overlooked.

The main config file that dehydrated looks for is named config, with no extension. Per-certificate config files are also named either config or alias, with no extension. But it looks like the other config files in CONFIG_D must have a .sh extension in order to be processed. (It certainly says as much in the template config file.)

If CONFIG_D is set, both the general config files (with extension) and any certificate-specific config files (without extension) are going to be mixed into the same directory. This leads to a scenario where a user following the directive in the template config (that all config files in CONFIG_D must have a .sh extension) might end up having their certificate-specific config files ignored.

Originally created by @txr13 on GitHub (Mar 15, 2018). While looking over my config files and considering setting a CONFIG_D, I noticed an inconsistency, and I'm wondering if it's intentional or overlooked. The main config file that dehydrated looks for is named `config`, with no extension. Per-certificate config files are also named either `config` or `alias`, with no extension. But it looks like the other config files in CONFIG_D must have a `.sh` extension in order to be processed. (It certainly says as much in the template config file.) If CONFIG_D is set, both the general config files (with extension) and any certificate-specific config files (without extension) are going to be mixed into the same directory. This leads to a scenario where a user following the directive in the template config (that all config files in CONFIG_D must have a `.sh` extension) might end up having their certificate-specific config files ignored.

adam closed this issue

2025-12-29 01:21:54 +01:00

adam commented

2025-12-29 01:21:54 +01:00

@lukas2511 commented on GitHub (Mar 15, 2018):

Well, it probably was an accident, but I'll argue against removing the required suffix.

I know this behaviour from a lot of software, e.g. nginx includes *.conf files, uwsgi includes *.ini (or has a systemd service with wildcard for that), other software does similar things.

Requiring this file ending does a few things: Editor tmp/backup files like myconfig.sh~ will not be included, "archived" files like myconfig.sh.old will be ignored, etc. It also allows for files like put_config_here, or README.

The other config files have static names, there is just one file in that directory, so the name doesn't really matter that much. In my opinion removing the suffix from the wildcard would be a bad move, but so would be renaming those config files (it was config.sh before 0.3.0, and was renamed to just config to make it clear that it's not intended to be a executable script).

Maybe a good move would be to use *.conf instead, which makes this more like other software and a bit more clear that those are "just" config files. But people are using .sh files now, supporting both is a bit redundant, so I guess the best thing would be to just leave it like is.

Any other opinions on this? I'm always open for suggestions.

@lukas2511 commented on GitHub (Mar 15, 2018): Well, it probably was an accident, but I'll argue against removing the required suffix. I know this behaviour from a lot of software, e.g. nginx includes `*.conf` files, uwsgi includes `*.ini` (or has a systemd service with wildcard for that), other software does similar things. Requiring this file ending does a few things: Editor tmp/backup files like `myconfig.sh~` will not be included, "archived" files like `myconfig.sh.old` will be ignored, etc. It also allows for files like `put_config_here`, or `README`. The other config files have static names, there is just one file in that directory, so the name doesn't really matter that much. In my opinion removing the suffix from the wildcard would be a bad move, but so would be renaming those config files (it was `config.sh` before 0.3.0, and was renamed to just `config` to make it clear that it's not intended to be a executable script). Maybe a good move would be to use `*.conf` instead, which makes this more like other software and a bit more clear that those are "just" config files. But people are using `.sh` files now, supporting both is a bit redundant, so I guess the best thing would be to just leave it like is. Any other opinions on this? I'm always open for suggestions.

adam commented

2025-12-29 01:21:55 +01:00

@lukas2511 commented on GitHub (Mar 15, 2018):

And obviously a solution to this issue would be better documentation... which I'll be working on... soon...ish... I promise! ;)

@lukas2511 commented on GitHub (Mar 15, 2018): And obviously a solution to this issue would be better documentation... which I'll be working on... soon...ish... I promise! ;)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#308