This prevents LANG= in an included file from affecting the interpretation
of month and day names in the including file.
Make the internal pre-processor accept white space between the "#" at
the start of the line and the keyword for better compatibility with cpp.
Add support for the cpp keywords #warning and #error.
MFC after: 3 days
Fix one case where #else was not corerctly processed and simplify the
conditions logic.
Fix parsing of day and month names in the locale specified in the calendar
file. The previous version would expect those names to match the locale of
the user.
Mention that comments are now correctly processed and that // is supported
in addition to /* ... */.
MFC after: 3 days
Calendar files that specify LANG=... to specify their character encoding did
also set the date format defined for that locale, resulting in output like:
Nov 4 Gabriel Faure dies from pneumonia in Paris, France, 1924
4 nov. N'oubliez pas les Charles !
After this commit the output is always printed in a consistent format
according to the user's current locale, e.g.:
Nov 4 Gabriel Faure dies from pneumonia in Paris, France, 1924
Nov 4 N'oubliez pas les Charles !
I'll open a review asking for opinions whether this format change should
be merged to -STABLE.
Relnotes: yes
Add line number information to more warning and error messages.
Detect #else and #endif without corresponing #ifdef/#ifndef as error.
Detect missing #endif at end of file and print warning but continue.
Support for #undef has been added to reverse the effect of a prior #define.
It is no error if the argument value has not been defined before.
These changes may cause error aborts on malformed input files (e.g. with
spurious #else or #endif), but no such errors exist in the calendar files
in the FreeBSD base system and the calendar-data port and all tests pass.
More tests will be added in a follow-up commit to detect regressions that
might affect the newly added features.
This commit ends a series of updates that enhance the pre-processor and
make it behave much more like prior versions of the calendar progarm that
called cpp to pre-process the data files.
MFC after: 3 days
Relnotes: yes
The calendar program used to output entries in reverse order, due to the
way an internal linked list was built up.
A regression test with 2 entries for the same day has been adapted to the
now non-reversed order.
MFC after: 3 days
The internal pre-processor ignored lines that did not parse a calendar
entries, but did not support multi-line comments in the way the external
cpp did.
The calendar files distributed with the base system (now in a port) do
use comments, though.
Implement comment processing for single-line (//) and multi-line comments
(/* */) with same semantics as in a standard C pre-processor.
All tests pass with this version, but there are no tests that specifically
verify comment processing.
Reported by: jhs@berklix.com (Julian H. Stacey)
MFC after: 3 days
While here, move the date to keep 2 weeks ahead notificaion
and fix the part of speech.
Reviewed by: debdrup
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26998
The existing code performed a chdir() into the home directory, but the
parser fell back to using the invoking user's home directory as the base
directory for the search for an include file.
Since use of the -a option is limited to UID==0, the directory searched
was typically ~root/.calendar, not the .calendar directory of the user
whose file is being processed.
PR: 205580
Reported by: greg.bal4@gmail.com (Greg Balfour)
MFC after: 3 days
The previous behavior was to support nested #ifdef and #ifndef, but to
return to unconditional parsing after the next #endif, independently of
the number of previously parsed conditions.
E.g. after "#ifdef A / #ifdef B / #endif" the following lines were
unconditially parsed again, independently of A and/or B being defined.
The new behavior is to count the level of false conditions and to only
restart parsing of calendar entries when the corresponding number of
#endif tokens have been seen.
In addition to the above, an #else directive has been added, to toggle
between parsing and ignoring of the following lines.
No validation of the correct use of the condition directives is made.
#endif without prior #define or #ifndef is ignored and #else toggles
between parsing and skipping of entries.
The MFC period has been set to 1 month to allow for a review of the
changes and for a discussion, whether these modifications should not
be merged at all.
No correct input file is parsed differently than before, but if calendar
data files are published that use these new features, those data files
will not parse correctly on prior versions of this program.
MFC after: 1 month
The convention in this program is to parse the line immediately starting
after the token (e.g. #defineA and #ifdefA define respectively look-up "A"),
and this commit restores this behavior instead of skipping an assumed
white-space character following #ifdef.
Reported by: kevans
MFC after: 3 days
There was code to process an #ifndef tokens, but none for #ifdef.
The #ifdef token was mentioned as unsupported in the BUGS section,
but no reason was given and I do not see why it should stay omitted.
Misleading information in The BUGS section of the man-page regarding
the maximum number of #define and #include statements supported has
been removed. These limits might have applied to a prior version of
this program, but do not seem to apply to the current implementation.
I have not tried to test for the existence of the limits, but the
include file processing just recursively calls the parser (without
counting the recursion depth) and the stringlist functions do not
impose a limit on the number of entries.
Reported by: jhs@berklix.com
MFC after: 3 days
Move all the data files for the calendar(1) program, except
calendar.freebsd to the calendar-data package. When a file
can't be found, and /usr/local/share/calendar doesn't exist
provide a helpful hint to install this package.
Reviewed by: se@
Differential Revision: https://reviews.freebsd.org/D26926
Calendar files in /usr/lcoal/share/calendar take precedence over files in
the base system. They can be provided by a port or package, but since such
a port has not been committed, yet, no specific port name is suggested.
In fact, multiple ports could exist (e.g. per locale) without conflicting
with each other.
Calendar files in LOCALBASE override similarily named ones in the base
system. This could easily be changed if the base system calendars should
have precedence, but it could lead to a violation of POLA since then the
port's files were ignored unless those in base have been deleted.
There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses
of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease
a consistent modification of this prefix.
Reviewed by: imp, pfg
Differential Revision: https://reviews.freebsd.org/D26882
root's calendar files three times, once each for root, toor and
daemon.
This relates to bug 246943, but does not solve it. See discussion in
bug report for more details.
PR: 246943
Reported by: wcarson.bugzilla@disillusion.net
As part of onboarding, ensure that I'm listed in the FreeBSD calendar file,
while listening to Don't Take Away The Music by Tavares.
Reviewed by: 0mp, bcr
Approved by: 0mp (mentor), allanjude (mentor)
Differential Revision: D25856
calendar(1) syntax is not capable of representing the rules for the
US Election Day. The hardcoded date was set in r15066 in 1996 and
hasn't changed since then.
PR: 173389
Reported by: Steve Ames <steve@energistic.com>
MFC after: 1 week
Both the result of the first_dayofweek_of_year and the target
weekday are zero-based (0 fo sunday) while the target month-day
or year-day is 1-based. Adjust logic accordingly.
Also add testcase for this PR to the kyua test suite
PR: 201062
Submitted by: Richard Narron <comet.berkeley@gmail.com>
MFC after: 1 week
These have an educational value and are, no doubt, an integral part of the fun
behind running the BSDs.
PR: 242909, 242918
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23581
It does extremely useful things like execute sendmail and spew dubiously
accurate factoids.
From the feedback, it seems like it is an essential utility in a modern unix
and not at all a useless bikeshed. How do those Linux people live without it?
Reverts r358561.
