-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undocumented "compare" statement #35
Comments
I _think_ that is a list of patterns to be processed only in "compare"
mode, `-o`,
but not processed in normal check/update/whatever modes, unless also listed
as include/exclude statements.
Whether that is useful for anything, or even fully implemented... I don't
know.
…On Thu, 22 Jul 2021 at 08:14, ggs67 ***@***.***> wrote:
What is the undocumented (hoping I was not blind) "compare" statement in
the config file for ?
Some background info:
After I did run out of time in my attempt to submit some changes for
csync2 I decided to restart from scratch, resetting my fork and started
cleaning up the parser/scanner before implementing new features.
For this I did switch from yacc to requiring bison (i.e. also running
bison in native mode, not yacc compatible mode). This step is required by
some changes I introduce but seemed also trivial as the original file uses
the non-posix %expect statement. However my clean-up of the parser also
includes changing the one step recursions to two steps. This removes the
requirement for empty rules which has two positive effects : it disallows
useless (and probably bogus) empty statements and in the same way removes
the shift/reduce errors and thus does not require the %expect anymore
In my progress through the parser I am now on the "compare " and I think
there is a bug in the parser or I alternatively I do not understand the use
of the command. The comp_list rule parses to "incl_list TK_STRING" , while
I guess this should be comp_list ? This seems top be confirmed by the code
as there is no way for the code to distinguish between include patterns
from the compare statement or a previous include statement.
Orgiginal rule:
comp_list:
/* empty */
| incl_list TK_STRING
{ add_patt(2, on_cygwin_lowercase($2)); }
;
I guess it should be comp_list and I will change to:
comp_list: comp
| comp_list comp
;
comp : TK_STRING
{ add_patt(2, on_cygwin_lowercase($1)); }
;
Still would be interested to know the use case of this statement.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#35>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGANXW6MKEOKX3NFJGDUDLTY6ZL7ANCNFSM5AZKUSSA>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the undocumented (hoping I was not blind) "compare" statement in the config file for ?
Some background info:
After I did run out of time in my attempt to submit some changes for csync2 I decided to restart from scratch, resetting my fork and started cleaning up the parser/scanner before implementing new features.
For this I did switch from yacc to requiring bison (i.e. also running bison in native mode, not yacc compatible mode). This step is required by some changes I introduce but seemed also trivial as the original file uses the non-posix %expect statement. However my clean-up of the parser also includes changing the one step recursions to two steps. This removes the requirement for empty rules which has two positive effects : it disallows useless (and probably bogus) empty statements and in the same way removes the shift/reduce errors and thus does not require the %expect anymore
In my progress through the parser I am now on the "compare " and I think there is a bug in the parser or I alternatively I do not understand the use of the command. The comp_list rule parses to "incl_list TK_STRING" , while I guess this should be comp_list ? This seems top be confirmed by the code as there is no way for the code to distinguish between include patterns from the compare statement or a previous include statement.
Orgiginal rule:
I guess it should be comp_list and I will change to:
Still would be interested to know the use case of this statement.
The text was updated successfully, but these errors were encountered: