Request: EchoFile

Hi ied206,

Sometimes it is useful to see some txt info via log file.

End users provide Log file to get support in which we have to get all possible info.

So on projects we sometimes create .txt file with Echo,"" or Echo,"",Warn

Call,EchoFile,Path\File.txt
or
Call,EchoFile,Path\File.txt,Warn

With PEBakery it can be faster and easier and more powerfull.
PEBakery naturally can support Echo txt files not with only ASCII but also UTF Unicode, Unicode BOM (for .reg), etc.......
Also PEBakery can support none txt files and encode them directly. (see example) (in case we need file for support by provided log file)



I suggest:

Code: [Select]

EchoFile,File,[Warn],[Encode]

To demonstrate what we use on projects, and new parameter "Encode" here is a test plugin :
 EchoFile and More for EchoFile.7z (340.62 kB - downloaded 96 times.)

ps:
EchoFile.exe we use available at
%ProjectDir%\Utils\"Utils Tools 001" plugin
EchoFile.7z -> EchoFile.exe
With SourceCode available , see: echofile.exe Properties -> Version -> Other version information -> SourceCode

Implemented on commit 8d4b611.
Will be included in next release.

Thanks a lot ied206,
 

IF it is easy :
Is it possible to add more ini support

ex:
EchoFile,%ProjectDir%\script.project,,,IniVariables

I suggest IniReadSection,<Filename>,<Section>,<%variable%>
as a more robust solution. This would allow lancelot to echo sections of a file as he requested,

Code: [Select]

IniReadSection,%ProjectDir%\script.project,IniVariables,%varIniVar%
Echo,%varIniVar%

but would also allow opportunities for future development if the need to read an entire section was required.

I suggest IniReadSection,<Filename>,<Section>,<%variable%>

I agree, this is better way. 

*
If IniReadSection is the way:
Keep in mind:
For now not required support for .ini files that have same named sections (I remember ms and some 3rd party have such .ini files in the past ....)

So for now,
when adding to help document,
write info about .ini files having same named sections, and which one IniReadSection will read (first from top, first from bottom)

ex:

IniReadSection does not fully support .ini files that have same sections.
Only First from top read by PEBakery.

Support can be added much later when we have real life example. 

IniReadSection implemented in Build 20171225.
Please note IniReadSection is designed solely for debugging, so it will return values in a human-readable form, not in a code-friendly form.

IniReadSection implemented in Build 20171225.
Please note IniReadSection is designed solely for debugging, so it will return values in a human-readable form, not in a code-friendly form.

Sounds good. If there ever is a use case for a code friendly form (probably not unless you decide to implement arrays[]) a parameter can modify that behavior.

Hi ied206,

[*
If IniReadSection is the way:
Keep in mind:
For now not required support for .ini files that have same named sections (I remember ms and some 3rd party have such .ini files in the past ....)

So for now,
when adding to help document,
write info about .ini files having same named sections, and which one IniReadSection will read (first from top, first from bottom)

ex:

IniReadSection does not fully support .ini files that have same sections.
Only First from top read by PEBakery.

Support can be added much later when we have real life example. 

5. [New] INIReadSection
See the manual in GitHub.

can you write help document:
-->
1)
IniReadSection reads first (or last ? ) section from top

ex:
IniReadSection,%SrcFile%,Test,%Dest%

%SrcFile%
[Test]
1=One
2=Two
3=Three

[Test]
1=Un
2=Dos
3=Tres


// IniReadSection will return these lines into %Dest%.
[Test]
1=One
2=Two
3=Three

*
2)
Also when there is no such section behaviour of PEBakery
ex:
IniReadSection,%SrcFile%,TestNo,%Dest%
If,%Dest%,Equal,#$pDest#$p,Echo,"No Section found"



*
3)
also IniDeleteSection delete first (or last) section inside ini file.
https://github.com/ied206/PEBakery/blob/master/Manual/Commands/04_Ini/IniDeleteSection.md


IniDeleteSection,%SrcFile%,Test,%Dest%

%SrcFile%

Code: [Select]

[Test]
1=One
2=Two
3=Three

[Test]
1=Un
2=Dos
3=Tres

// IniDeleteSection will delete first section
%SrcFile%

Code: [Select]

[Test]
1=Un
2=Dos
3=Tres

ps:
It will be good to have examples on help documents
ex:
https://www.autoitscript.com/autoit3/docs/functions/IniRead.htm
even much better when one can copy paste examples easily
ex:
Reply 184 http://theoven.org/index.php?topic=2271.msg25271#msg25271

Tip: Copy you can hit [Select] link on current post "Code: [Select]" and CTRL+C

Edit:
As long as
IniReadSection
IniDeleteSection
behaviour is same for same sectioned .ini files (preferred first) all fine. 

first priority is to get all commands documented, with my current free time I'm averaging 2-3 commands a day. All commands have working examples.
Once all commands are documented I will work on proper "ready to run" plugin examples for each command, much like the way autoit has. To do so right away would slow me down too much right now, and I believe its more important to have fully documented syntax with a working example be a priority over a full blown drop in example plugin.


As for IniRead and IniDelete, I would expect that PEBakery should consider duplicate sections a syntax/validation error, as that could cause multiple problems (ie. if I can Run,%ScriptFile%,mySection which section should be  called?) I see allowing duplicate sections as a good way to cause headaches and unintended behavior.

This currently isn't the case and IniReadSection/IniDeleteSection grab the first section they see. So if I call IniDeleteSection in one plugin, then test for that section in another plugin and there was a duplicate that got read, I would get the wrong data instead of no data. Granted this is an extreme case, and duplicate sections should be very rare if they do exist. Do you have any examples of non-standard .ini files using duplicate sections, where this is an issue?

As for IniRead and IniDelete, I would expect that PEBakery should consider duplicate sections a syntax/validation error, as that could cause multiple problems (ie. if I can Run,%ScriptFile%,mySection which section should be  called?) I see allowing duplicate sections as a good way to cause headaches and unintended behavior.

for plugins etc. there have to be 1 section as a rule. 

This currently isn't the case and IniReadSection/IniDeleteSection grab the first section they see.

From top, bottom, random (my preference top) ?

So if I call IniDeleteSection in one plugin, then test for that section in another plugin and there was a duplicate that got read, I would get the wrong data instead of no data. Granted this is an extreme case, and duplicate sections should be very rare if they do exist. Do you have any examples of non-standard .ini files using duplicate sections, where this is an issue?

I can not remember now, I remember I saw them on windows ini or inf files..
The day anyone see, Better we know we have IniReadSection IniDeleteSection having same behavior which is enough to handle such cases, well written on help document.
(Be sure I will post around when I have time to work on such things)



As I wrote to the end of previous post.

Edit:
As long as
IniReadSection
IniDeleteSection
behaviour is same for same sectioned .ini files (preferred first) all fine. 

Having such rules for PEBakery on help documents under the supervision of ied206 will get things stable in passing time.



+
Example codes should be there to test and verify.
Even early, I wrote many test plugins around, some good for help documents (ex: like on my previous post)
or they will get forgotten on forum posts.
And one day reappear
ex:
http://theoven.org/index.php?topic=2336.0
topic created where request already made but forgotten.

We develop projects to get stable in passing time by not following development circle principles.
 (very rarely 1 circle but If you do not go development steps carefully you will have many circles we do not have.)
   Fix once and forever (spend required time), naturally result with work on next features. very rare bugs. -> Result efficiency with limited free time.

well, I defiantly agree the behavior needs to be clarified and documented.


What do you see as the most desirable behavior considering that there is no formal standard for the .ini specification?

Do we want PEBakery to:

• Continue with current behavior and only process/delete the first occurrence of a section, ignoring other sections with the same name.
• Continue with the current behavior and only process/delete the first occurrence of a section, and add a warning in the log that other sections exist.
• Modify the behavior of PEBakery and only process/delete the last occurrence of a section.
• Modify the behavior of PEBakery and only process/delete the last occurrence of a section , and add a warning in the log that other sections exist.
• Modify the behavior of PEBakery and read (merge) duplicate sections as one section, with duplicate keys from the last occurrence of a section overwriting earlier occurrences. If IniDeleteX is used delete all occurrences of the section or key.
• Something else.

Continue with current behavior and only process/delete the first occurrence of a section, ignoring other sections with the same name.

That is what I wrote If current behaviour is first section.
I want it to be documented properly with test plugins, I point current help documnet weblinks showing info missing.
why it is not clear to you ?

Continue with the current behavior and only process/delete the first occurrence of a section, and add a warning in the log that other sections exist.

I did not write warning and no need for them on IniReadSection IniDeleteSection
IniReadSection will show values on log
and
IniDeleteSection will give info if a section deleted.

I feel you are again thinking logs in compiler log way.......

Modify the behavior of PEBakery and only process/delete the last occurrence of a section.

now I start to believe your english is worst than mine.
How many times should I wrote preferred worst. -> first 

(preferred first)

Modify the behavior of PEBakery and only process/delete the last occurrence of a section , and add a warning in the log that other sections exist.

no no

Modify the behavior of PEBakery and read (merge) duplicate sections as one section, with duplicate keys from the last occurrence of a section overwriting earlier occurrences. If IniDeleteX is used delete all occurrences of the section or key.

I never wrote something like that. no

Something else.

My post should be clear.

===>
so not only me English is bad, yours is bad too. 

well, I defiantly agree the behavior needs to be clarified and documented.

That is the only point we agree.

See You on next post Homes32.

Hi Homes32,

no need to get things complicated,
list is unnecessary but nice , things like that only cause continous posts that leads to nowhere.
It is a kind of intentional or unintentional post game I faced since 10 years now on forums.
(Real life too, but it is easy to handle such things at real life, forums are different.... )

Unintentional ones are fine to me.

My initial post and intention is clear:
 I like ied206 point the behaviour of these syntax with examples on help documents.
  After ied206 decides following any discussion, anyone (and you) can further write help document.

  This way :

* we can avoid undocumented behaviour usage.
ex: one can use (for whatever reason) multisectioned ini files, and do things with that with current behaviour
----> which we lived before

* we can follow example or give info to end user to test example.
----> which we missed so far

And I like to believe help documents do not change one night and saying "it is written on document".
----> which we lived before (edit: thanks to Peter Schang & Nuno Brito stupid games following deaf and blind , silent supporters)

And I like help documents written following developer (on PEBakery ied206)
----> which we lived before not following is not good like on current wb document (to me failure, of course to you not on another topic... )



Add: Edit

no post games from me and I understood your request for updated documentation, however your thinking is often times focused at a single [valid] case point/issue. (don't take that as an insult, its not.) my point is, you did bring up the potential for other issue to occur. what if someone else/needs expects multiple sections to be handled in a different way? Since there IS NO FORMAL .INI STANDARD we should make sure the current PEBakery behavior is the way we want things to actually be handled for the good of everyone for years to come. (not changing things and breaking compatibility every other build like the old days) Then the code and/or documentation can be updated accordingly. I'm fine with the current behavior, but not foolish enough to think that my or your opinion is the only one that matters.

if someone else/needs expects multiple sections to be handled in a different way?

That is the point I leave expansion slots on development.

ex:
I do not like to see ied206 spend big time to work on all possibilities of current IniReadSection IniDeleteSection for same multisectioned ini files.
I only ask default behaviour of PEBakery with these syntax for such cases, that is all.
So in future IF required,
ied206 can add 4th 5th etc. parameter or new syntax for multisectioned ini files without breaking any similar usage on plugins.

A balance between "time" "development" "requirement" and "expansion availability"

None of projects are perfect here, development so far go with a balance (with more bases than above 4) and wheels turn.
ex: reverse example: see where wheels do not turn anymore and guess why.....
ex: I can count many missings out of wb and things we delayed even for 8 years now since not required ....

I always surprise with most engineers (and doctors) can not understand such things in real life too which I see failure coming after 6 8 months as expected ....

we should make sure the current PEBakery behavior is the way we want things to actually be handled for the good of everyone for years to come. (not changing things and breaking compatibility every other build like the old days) Then the code and/or documentation can be updated accordingly.

Breaking compatibility in the past was targeting other projects than Peter Schang & Nuno Brito own projects fail on the old organization intentionally.
With their silent loyal supporters.
Stupidly they would fail with their own projects too , as expected they failed .... and supporters can never get what is advertised, as expected they couldn't.


You do not have to believe me, ask JFX.
You can also ask ChrisR, Galapo.

Here we break compatibility time to time for benefit of all projects for a long while now to get things better.
Without breaking projects.
It only breaks some personal plugins.
I am very sure these updates made ied206 life easier during PEBakery development.
That is the reason I can make some hundreds of updates quickly to support PEBakery with ALL Projects and Plugins.
giving example:
at a point we do not have .script extension and get rid of all wb
+ we can have default auto utf support
+ NoRec all can be changed to NoRecursive or NoSubfolder (whatever) on a weekend.
+ Other things I can not remember now (We need to get closer to lines again.....)
etc.
(and personal plugins should be updated too by themselves.  )
....
After some long time....

After cleaning mess wb development with their supporters cause than we have batch syntax getting better and better for future.
 like projects we develop.

And after Batch syntax with builder get very mature with better organized projects and easier to handle -> I hope we see ChrisR around
and next: new syntax -> at this point I hope we see JFX more around.

All up to ied206 ...


*
These are nice discussions, But such posts sadly change focus elsewhere going away from main post. (it is also a post game on forums)
As I wrote before, we can chat on other sections of forum and continue development on development topics.

What do you see as the most desirable behavior considering that there is no formal standard for the .ini specification?

Do we want PEBakery to:

• Continue with current behavior and only process/delete the first occurrence of a section, ignoring other sections with the same name.
• Continue with the current behavior and only process/delete the first occurrence of a section, and add a warning in the log that other sections exist.
• Modify the behavior of PEBakery and only process/delete the last occurrence of a section.
• Modify the behavior of PEBakery and only process/delete the last occurrence of a section , and add a warning in the log that other sections exist.
• Modify the behavior of PEBakery and read (merge) duplicate sections as one section, with duplicate keys from the last occurrence of a section overwriting earlier occurrences. If IniDeleteX is used delete all occurrences of the section or key.
• Something else.

I vote for option 1.
PEBakery's ini file manipulation is a bottleneck of File IO and already is slow. Adding more checks will result much slower IO.

My opinion is to follow WinAPI (WriteProfileString, GetProfileString) behavior.
Many programs are still dependent on those APIs, so syncing behavior with other programs is better.

I vote for option 1.
...

My opinion is to follow WinAPI (WriteProfileString, GetProfileString) behavior.

Agreed. WinAPI and Autoit all follow this behavior and that's what most of us here are used to expecting.

PEBakery's ini file manipulation is a bottleneck of File IO and already is slow. Adding more checks will result much slower IO.

My opinion is to follow WinAPI (WriteProfileString, GetProfileString) behavior.
Many programs are still dependent on those APIs, so syncing behavior with other programs is better.

As expected. 

So we finish circle we start 3 days ago after Reply#7,
 Back to my initial request at Reply#7 .

http://theoven.org/index.php?topic=2323.msg25320#msg25320

Hi ied206,

*
If IniReadSection is the way:
Keep in mind:
For now not required support for .ini files that have same named sections (I remember ms and some 3rd party have such .ini files in the past ....)

So for now,
when adding to help document,
write info about .ini files having same named sections, and which one IniReadSection will read (first from top, first from bottom)

ex:

IniReadSection does not fully support .ini files that have same sections.
Only First from top read by PEBakery.

Support can be added much later when we have real life example. 

5. [New] INIReadSection
See the manual in GitHub.

can you write help document:
-->
1)
IniReadSection reads first (or last ? ) section from top

ex:
IniReadSection,%SrcFile%,Test,%Dest%

%SrcFile%
[Test]
1=One
2=Two
3=Three

[Test]
1=Un
2=Dos
3=Tres


// IniReadSection will return these lines into %Dest%.
[Test]
1=One
2=Two
3=Three

*
2)
Also when there is no such section behaviour of PEBakery
ex:
IniReadSection,%SrcFile%,TestNo,%Dest%
If,%Dest%,Equal,#$pDest#$p,Echo,"No Section found"



*
3)
also IniDeleteSection delete first (or last) section inside ini file.
https://github.com/ied206/PEBakery/blob/master/Manual/Commands/04_Ini/IniDeleteSection.md


IniDeleteSection,%SrcFile%,Test,%Dest%

%SrcFile%

Code: [Select]

[Test]
1=One
2=Two
3=Three

[Test]
1=Un
2=Dos
3=Tres

// IniDeleteSection will delete first section
%SrcFile%

Code: [Select]

[Test]
1=Un
2=Dos
3=Tres

ps:
It will be good to have examples on help documents
ex:
https://www.autoitscript.com/autoit3/docs/functions/IniRead.htm
even much better when one can copy paste examples easily
ex:
Reply 184 http://theoven.org/index.php?topic=2271.msg25271#msg25271

Tip: Copy you can hit [Select] link on current post "Code: [Select]" and CTRL+C

Edit:
As long as
IniReadSection
IniDeleteSection
behaviour is same for same sectioned .ini files (preferred first) all fine.