CCleaner Enhancement: get file location from an *.ini file

[4uTVyZIXNN]

Dear all,

 

Summary:

------------

I suggest an enhancement for generalizing the usage and adaptability from CCcleaner,

reading locations from an *.ini file.

 

Detail:

-------

I'm using a utility called Syncovery (given here as an example).

This utility has a fix configuration file location:

%ALLUSERSPROFILE%\Syncovery\Syncovery.ini

 

In this ini file we find the effective location from log files I would like to purge:

 

[Main]

...

LogFolder=C:\ProgramData\Syncovery\Logs

 

Enhancement suggestion:

--------------------------------

It would be smart to have such an indirection:

IndirectFileKey1=%ALLUSERSPROFILE%\Syncovery\Syncovery.ini;Section=Main;Key=LogFolder|*.log

being "expanded" internally in CCleaner into

FileKey1=C:\ProgramData\Syncovery\Logs|*.log

 

This would translate into a full cleanup configuration:

[syncovery]

LangSecRef=3024

Detect=HKCU\Software\Syncovery

Default=FalseIndirectFileKey1=%ALLUSERSPROFILE%\Syncovery\Syncovery.ini;Section=Main;Key=LogFolder|*.log

 

My 2c worth :-)

Cheers Phil.

 

P.S. I haven't found any discussion in this forum related to *.ini files parsing.

[Winapp2.ini]

That's a pretty interesting idea.

 

Piriform mentioned they were working on ini parsing some time ago, but AFAIK, nothing has come from it (at least, they haven't mentioned it)

 

ini parsing that they were referring to, I believe, was more about removing contents from inis without deleting the entire ini file.

[Alan_B]

Parsing of an INI created by some other application may be hazardous to the application if all its Wild and Wacky syntax is not fully understood.

 

For Wild and Wacky syntax I look no further than Winapp2.ini

[TheWebAtom]

Alan has a good point. *.ini file syntax isn't standardized or formally defined, so adding support for a wide range of syntax dialects and weird edge cases (see also: winapp2.ini) would be essentially impossible.

[4uTVyZIXNN]

Dear all,

Thanks for your answers. I miss Windows variants experience to appraise the difficulty

of existing .ini files syntax dialects and variants. If I believe the following Wikipedia article

updated on 14-May-2013, there are not that much notions included in *.ini files.

http://en.wikipedia.org/wiki/INI_file

- An implicit global section (may be wihtout [title] tag)

- A possible doted notation for suggesting nested values

[titel.subtitel]

- A key=value scheme

Note: the Windows Technet entry in references has a validity / guarantee disclaimer

 

Based on your remarks, it seems you have met many *.ini dialects. It would be smart

to document the ones you have met. Piriform may then chose to implement few dialects

based on dialect appearance frequency. I don't pretend CCleaner has to cover all

existing dialects, the main point here seems to cover the possibility of having indirections.

 

The indirection makes CCleaner more general purpose and flexible, not the *.ini file on

its own. I was told by .Net programmers that the current practices in .Net environments

consists to use XML files (like we do in Java). A next step after *.ini files may be to

specify indirect registry entries or XML file entries. Let's start "small and easy" :-)

 

My 2c worth :-)

Cheers Phil.

[Winapp2.ini]

I think in the end it is just simpler to have a human read the ini file for the logs location, assuming it wont change (ccleaner typically only supports default paths)

 

Pruning history/mru from ini files would be extremely useful yet though, still keeping my fingers crossed for that updated (though I can only imagine the syntax... Filekey1=INI|%ProgramData%\Program1\Data\program.ini[History|1;2;3;4;5] ...? What have I just created..)

[Alan_B]

Apologies for any confusion I may have caused.

 

When I refer to the Wild and Wacky nature of WinApp2.ini,

I refer to the configuration file that may be downloaded from

http://winapp2.com/Winapp2.ini

and which has a whole topic at

http://forum.pirifor...howtopic=32310.

 

The nature of Winapp2.ini the forum member is something that is best assessed by his girlfriend

 

I was told by .Net programmers that the current practices in .Net environments

consists to use XML files (like we do in Java).

I am sorry, but .NET on Windows XP was an unrepairable broken mishmash of vulnerabilities and updates and patches which could NOT be mended.

 

Since it failed catastrophically on my old Laptop I have never trusted .NET.

Java also is a seething mess of vulnerabilities.

 

Conclusion :- XML files are more likely to confuse the programmers than INI files - and I have no hope of mastering them

[4uTVyZIXNN]

Hello Alan,

 

I don't want to start a fire of controversy, but if I may agree that

WinApp2.ini is not crystal clear, I've found some minimal description

On Piriform web site that has helped me to code some minimalistic rule

for enhancing CCEnhancer.

http://www.piriform.com/docs/ccleaner/advanced-usage/ccleaner-ini-files/how-to-add-your-own-program-for-ccleaner-to-clean

 

Back to XML, I'm not sure to understand your remarks (or the meaning

of your remarks). I'm suggesting here to introduce a new feature

to CCleaner: the indirection to find the location of some files to

be purged by looking at *.ini (or XML or Registry) entries.

 

The fact that some .Net or Java environments are no secure enough

for you has nothing to do with my enhancement request. If you have

a hammer, you can use it properly to mount nails or you can hit your

fingers. The latter case will not forbid the usage of hammers :-)

 

If I can agree that the previous X11 resource file and the

*.ini file syntaxes are somehow "weak", I can tell quite

imperatively that the XML approach is the answer for all

such cases.

 

Normally, we start to define a grammar (DTD) for a specific

purpose. This grammar can be used to automatically check the

syntax validity of a given XML file. If the DTD is completely done,

it will be robust, if it's done approximately, it will be weak.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

...

Notice also that we can use many DTD for fully validating one XML file.

 

There are tons of XML parsers and the usage of such parsers is

most of the time not immediate from a programming point of view.

Such parsers are also based on the DTD for generating the data

structures.

 

If you tell "usage of robust XML config file" is not obvious.

I tell you: yes you are right.

I would add, if you are a developer, not mastering XML techniques

(in a wide sense) is these days definitely a weakness (whatever

your programming language, Perl, Python, Java, C#, ...)

Tools like Notepad++, Oxygen, Eclipse help to develop XML stuff.

XML is today almost omnipresent on all systems.

 

I hope these remarks contribute to discuss about the right

points. No personal critics are intended in any way.

 

Cheers Phil.

[Alan_B]

Due to age I am now retired,

but previously I was a software developer,

but almost exclusively using Assembler and more recently Ansi C for programming of embedded computer systems.

I coded both the real-time operating systems and application code that provide intruder and fire detection systems for Nuclear installations and Shopping Centres,

and unlike Windows they just kept on running day and night, and are not allowed to tell weapon carrying security guards

"You failed to shut-down properly"

 

I was programming when Intel made calculator chips - long before there was DOS

 

I never needed or used XML whilst working,

and now that I am retired I find that keeping Windows under control does not give me time to investigate XML.

 

Your remarks are quite acceptable and cause me no distress.

 

Caution - CCEnhancer is not supported by Piriform and we prefer not to talk about it

 

Alan