Hi Bertho,
Thanks for the detailed answer on point 1, hard error early in startup
is exactly what I'd expect. Glad that's sorted.
On inline comments: I understand the conflict with continuation lines
and why escape characters are ugly. But I think there's a good middle
ground:
Treat # or ; as an inline comment delimiter by default, and only require
quoting when a value legitimately contains those characters:
SPEED = 1000 # max rapid speed
MY_VAR = "value with # in it"
Looking at existing LinuxCNC INI files, no values actually use # or ;
values are numbers, paths, axis letters, G-code commands, etc. So this
change wouldn't break any existing configs.
This is also what most users expect: Python's configparser, PHP's
parse_ini_file, and most Unix config formats all treat # as an inline
comment. Not supporting it has been a recurring source of confusion
since 2.7.x.
Continuation lines can coexist with this just fine: if a line ends with
\, continue to next line. Otherwise, # or ; starts a comment. No
conflict there. But is this even something that is supported? I have not
seen it in configurations or in the docs.
Luca
On 3/29/26 4:47 PM, Bertho Stultiens wrote:
On 3/29/26 3:27 AM, Luca Toniolo wrote:
Two questions about the new parser:
1. Invalid variable names, what's the failure mode?
If the parser encounters a variable name with spaces (or otherwise
not matching [a-zA-Z_][a-zA-Z0-9_]*), will it refuse to start? A
silently dropped axis limit would be dangerous, so I'd expect a hard
error, what's your take?
You now instantiate like:
IniFile myini(filename);
The parser class overloads the cast-to-bool operator. And you check
validity right after instantiation with:
if(!myini) {
// error condition, parse failed
// message already printed by parser
return ...error...
}
All sources have been updated to check like this and return an error
on failure.
Note: the new class uses an internal static system of caching based on
filename. Instantiating the IniFile class on the same file multiple
times, regardless where and when, only reads and parses the file once
upon creating the first instance.
Since the same ini-file is used for all processing, if it fails, then
most processes refuse to start and drop out very early in the startup
process. This prevents linuxcnc to start at all.
BTW, the actual startup script (scripts/linuxcnc) also uses the new
ini-file parser and will bail on errors from the new inivalue program
(to get ini values from command-line). The old inivar program is now a
compatibility script that invokes inivalue.
Therefore, you wouldn't even get as far as starting the actual
binaries because of error(s).
When the syntax if fine, then you can still have problems with missing
or wrong values, but those are not a concern of the ini-parser. Those
you need to program correctly (like defaults). The parser interface
does implement to get values with defaults if not found and is
extensively used. There also is an optional bounds-check
implementation in the interface when getting values.
2. Will we get Inline comments?
Since 2.7.x the parser doesn't support inline comments, VAR = value #
comment treats everything after = as the value. This is a common
source of confusion. Will the new parser support inline comments
(e.g. # or ; after the value)? If so, an escape character (e.g. \# or
\;) would be needed for values that legitimately contain those
characters.
Having inline comments is effectively no longer possible with the 2.7
update because everything after the '=' is treated as the value and
there are not defined any string delimiters for values.
It would only be possible if you change the string syntax into:
val="string"
But, that will interfere with the continuation syntax:
val=bla bla \
more bla \
and more bla
You can't easily have both or you need to do string concatenation. But
when you do string concatenation, then why would you need continuation
as you'd simply use "foo" "bar" on two lines to make "foobar".
Using escapes for '#' and ';' is (very) ugly. If you change the
syntax, then it should be changed more radically to conform to other
ini file forms and use proper string delimiters. However, changing
syntax this way would require to major change to the existing _values_
in ini-files in a conversion process. I don't know if I'd recommend
that, but is can be discussed.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
