Re: uid and gid problem [LANGUAGE CHANGES]

[Jan-Henrik Haukeland]

Sweet, I'll implement this in the lexer/parser later this
evening/night. I guess no one will have any exception to promote
IF/THEN/ELSE to real keywords and use them as outlined below? If so,
speak now or forever hold your peace :-)

Martin, I'll add IF/THEN for port, timestamp and resource. Could you
add for the other statements listed below, since I think you where in
a process to finalize them.


Martin Pala <address@hidden> writes:

> Jan-Henrik Haukeland wrote:
>
>>Martin Pala <address@hidden> writes:
>>
>>
>>>I tried to find some way to solve uid and gid problem to allow its
>>>usage as standalone statement in addition to its usage in exec
>>>statement. I think the change of the uid and gid ('useroption') will
>>>involve too much extra code (present version is very simple and
>>>effective, but restricted to predefined usage).
>>>
>>>We can keep present simplicity by renaming 'uid' and 'gid' options in
>>>exec statements to 'euid' and 'egid' (which is exactly what it in fact
>>>is) => 'uid' and 'gid' tokens will be freed for its own statement
>>>usage (which again is in fact what it is - real owner and group).
>>>
>>
>>A much better solution is to do a small grammer change. This will
>>further break backward compability, but it will make life MUCH MUCH
>>easier for us now and in the future. The solution is to promote IF and
>>THEN to real keywords (maybe also ELSE for future use).
>>
>>By using IF and THEN the parser can use its one lookahead to deduce if
>>it should reduce or shift. Thus we can avoid all the shift/reduce
>>problems we experience today when we reuse keywords in different
>>statements. A great benefit by using IF/THEN is also that some
>>statements can be written with a default action and with an action
>>option. For instance with the current grammar the following example
>>using the port statement will not work as I explained before because
>>of the reduce and shift problem. In the current grammar we must choose
>>either to use (1) or (2) because both cannot be used in the same grammar.
>>
>>(1) | host port type protocol connecttimeout { default action }
>>(2) | host port type protocol connecttimeout action { user select action }
>>
>>But here comes the clever part, by using IF and THEN as keywords both
>>statements may be used in the same grammar without generating a
>>shift/reduce error:
>>
>> | IF host port type protocol connecttimeout | IF host port type
>> protocol connecttimeout THEN action
>>
>>And your UID/GID statement will work perfectly without any
>>shift/reduce errors also, for instance this will work:
>>
>> | IF UID NOTEQUAL STRING
>> | IF GID NOTEQUAL STRING
>> | IF UID NOTEQUAL STRING THEN action
>> | IF GID NOTEQUAL STRING THEN action
>>
>>I have tested this in my local p.y grammar file and it works just
>>fine. So I suggest or actually insist :) that we promote IF/THEN/ELSE
>>to real keywords and rewrite our grammar to use those as outlined
>>above. The statements affected and in need for rewrite will be:
>>
>> - port - timestamp
>> - resource
>> - permission
>> - size (?)
>> - and your UID/GID test for files.
>>
>>
> Good suggestion - i agree :)
>
> Martin
>
>
>
> _______________________________________________
> monit-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/monit-dev
>

-- 
Jan-Henrik Haukeland