Re: [RFC] X_dir directive naming

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 31 Jan 2014 11:47:57 +1300

On 2014-01-31 10:55, Alex Rousskov wrote:
> On 01/29/2014 09:01 PM, Amos Jeffries wrote:
>> On 30/01/2014 2:06 p.m., Alex Rousskov wrote:
>>> On 01/29/2014 03:44 PM, Amos Jeffries wrote:
>>>> On 2014-01-30 06:55, Alex Rousskov wrote:
<snip>
>>>>>
>>>>> Furthermore, I think it is a good idea to eventually add a
>>>>> squid.conf
>>>>> option to overwrite --prefix effects:
>>>>>
>>>>> root_dir
>>>>>
>>>>
>>>> +1.
>>>
>>> Great. Please consider adjusting your pending patches to implement
>>> shared_memory_dir and uds_dir (while adding "service name" to their
>>> default values)?
<snip>
>
>> Will do. Although "base_path" seems a little better for its name, to
>> avoid implications of a link with chroot or root user.
>
> Please use _dir or _directory suffix to remain consistent with the
> existing squid.conf directive names:
>
>> NAME: cache_dir
>> NAME: store_dir_select_algorithm
>> NAME: coredump_dir
>> NAME: icon_directory
>> NAME: error_directory
>
> There are currently no directives with _path AFAIK (unless you count
> capath= option to the *_port directives).
>
>
> I know other projects are using PROJECT_ROOT for this kind of thing.
> "Root" feels "standard" for this purpose to me, so I think it would be
> better to use "root" rather than HTML-ish "base" despite the chroot()
> similarity, but I do not have a strong preference or in-depth knowledge
> about this subject.
>

Does anyone else have opinions on naming before I go and set finger to
code?

>
> I am guessing chroot would apply first and root_dir second. In other
> words,
>
> chroot /foo
> root_dir /bar
>
> would mean that Squid will use /foo/bar/* paths by default, from the OS
> point of view.
>

Yes I believe that is the correct way.

>
> Please note that I am not asking you to add root_dir -- it is clearly
> outside your project scope and will probably open another can of worms
> such as its relationship with chroot() dir!

Not if I get it right :-)

Amos
Received on Thu Jan 30 2014 - 22:48:01 MST

This archive was generated by hypermail 2.2.0 : Fri Jan 31 2014 - 12:00:17 MST