linuxcnc config folder is polluted with a 'ini expanded' file when a config is run

[c-morley]

using master RIP
When I run a sim config, there is a file auto generated and saved as the same name but with 'expanded' added to the end.
Why does this need to be there?
There is already too many files in the typical config folder. can at least it be deleted when the config closes?
I certainly could see a user being confused about there being two similarly named INI files.

[rmu75]

https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/linuxcnc.in#L359

Not sure how calibration interacts with this preprocessing.

[BsAtHome]

This is a similar preprocessing that was done previously on the INI-file before the new parser.

The problem is that the Tcl code has a very bad INI-file reader that has no idea about includes or other formatting. Therefore, the INI-file is read by inivalue and rewritten in an expanded format so that the Tcl code actually works.

The real solution is to get rid of the Tcl code that reads the INI-file and replace that with a call-down to the new parser. Another solution is to get rid of all Tcl code that needs the INI data. Either is a bit more work.

[rmu75]

@BsAtHome does this expanded ini file need to be persistet? Are other ini file readers using the expanded file if it exists?

If tcl programs modify / overwrite the expanded ini we are hosed, and if no tcl program does that IMO that file could be disappeared into some tmp-directory or even deleted after opening and regenerated on demand.

[BsAtHome]

Please note that the same expanded ini-file was previously generated by the handle_includes() function in the linuxcnc script. The only difference is that it now is always generated and not only when the #INCLUDE statement is seen in the original ini-file. The reason is that the new parser does more, like validation, nested includes and handling escapes, and the Tcl code does not handle any of that.

In Tcl, the parse_ini() procedure is part of tcl/linuxcnc.tcl and loads all ini section|variables into the global Tcl namespace in arrays named section and the variable names as key. The content is used several places, mostly as legacy, but it is hard simply to remove.

In principle, the expanded ini-file can be removed after the linuxcnc script finishes. However, any abnormal termination will still leave some stuff behind. Besides, the original code didn't remove it either.

I am working on replacing some of the Tcl code, but that takes time. Probably will make it call the new parser and export the data that way. But again, it takes some time. The current way should be considered a stop-gap solution that does not add to the problems we've had before. They are just explicitly visible now...

If tcl programs modify / overwrite the expanded ini we are hosed, and if no tcl program does that IMO that file could be disappeared into some tmp-directory or even deleted after opening and regenerated on demand.

Tcl does not write the ini-file. It is only reading.

The real problem is that the update_ini script is not aware of the #INCLUDE mechanism and will happily read and alter the expanded file. This is nothing new! This has always failed. Nobody ever discovered it or didn't care.

Putting the expanded ini-file in a temp dir was considered but rejected. The simple reason is that code assumes that the ini-file lives with and next to the rest of the configuration. It will happily do a change directory to that place and expect stuff to be there. Therefore, it needs to next to the original ini-file. This is also the reason why the config directory needs to be read/write accessible. Afaics, a lot more needs to change for this read/write accessibility no longer to be necessary.

[BsAtHome]

Are other ini file readers using the expanded file if it exists?

All other code uses the new ini-parser. C, C++ and python code are all linked to the new parser.

Only the (legacy) Tcl code presents a problem.

[BsAtHome]

And it is even worse... There are two ini-parser interfaces in Tcl.

One uses function call emc_ini, which calls down to the new parser, but only handles strings. It is part of the Tcl Linuxcnc package (defined in emc/usr_intf/emcsh.cc).

The second ini-parser resides in tcl/linuxcnc.tcl and does a bare-bone file read, tries to make sense of the content and exports all section/variables into arrays of the global Tcl namespace.

It is an utter mess.

[c-morley]

Thanks for pursuing this.
I think we should remove tcl code in the long run anyways.