Matthieu Moy <matthieu....@grenoble-inp.fr> writes:

>>> +           if (user_config && access(user_config, R_OK) &&
>>> +               xdg_config && !access(xdg_config, R_OK))
>>>                     given_config_file = xdg_config;
>>
>> Shouldn't we be using xdg_config, if user_config is NULL and
>> xdg_config is defined and accessible?
>
> I don't think so. If user_config is NULL, it means something went wrong,
> because $HOME is unset. In this case, I'd rather die than using some
> other configuration file silently (which would be possible if
> $XDG_CONFIG_HOME is set), and this is what the code does:
>
>               if (user_config && access(user_config, R_OK) &&
>                   xdg_config && !access(xdg_config, R_OK))
>                       given_config_file = xdg_config;
>               else if (user_config)
>                       given_config_file = user_config;
>               else
>                       die("$HOME not set");
>
> Perhaps it could actually be made even clearer with
>
>               if (!user_config)
>                       die("$HOME not set");
>               else if (access(user_config, R_OK) &&
>                        xdg_config && !access(xdg_config, R_OK))
>                       given_config_file = xdg_config;
>               else
>                       given_config_file = user_config;

At least the code needs to break lines at different point and a comment.

        if (user_config &&
                access(user_config, R_OK) &&
                (xdg_config && !access(xdg_config, R_OK)))
                /*
                 * Even if we have usable XDG stuff, we want to
                 * error out on missing HOME!!!
                 */
                use xdg config;
        else if (user_config)
                use user config;
        else
                unusable situation;

But is it really true that we want to error out on missing HOME if
we have usable XDG stuff?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to