TSE: Linux: GetProfileStr() does not work as expected

[knud van eeden]

Hello,

While converting working Microsoft Windows TSE programs to the equivalent Linux TSE WSL programs

I saw that GetProfileStr() worked sometimes in Linux WSL, but not always.

It maybe has something to do with the length of the string (e.g. if short length it works and if longer length it does not work)

and or maybe with the case (upper case, lower case). That I have not tested further at this moment.

===

Reproduction:

a. -Using TSE for Microsoft Windows it works OK:

1. -Create a file

     c:\temp\ddd.txt

2. -Put in this file and save

--- cut here: begin --------------------------------------------------

[default]

windowLineRelativeCurrentGI = 0

--- cut here: end ----------------------------------------------------

3. -Then run this TSE for Microsoft Windows program

--- cut here: begin --------------------------------------------------

PROC Main()

 STRING sectionS[255] = "default"

 STRING searchS[255] = "windowLineRelativeCurrentGI"

 STRING fileNameS[255] = "c:\temp\ddd.txt"

 STRING s[255] = ""

 s = GetProfileStr( sectionS, searchS, "", fileNameS )

 Warn( s ) // gives 0

END

--- cut here: end ----------------------------------------------------

4. -That will return as expected

--- cut here: begin --------------------------------------------------

0

--- cut here: end ----------------------------------------------------

===

Reproduction:

b. -Using basically the SAME program in TSE for Linux it does not work OK, as it returns the empty string:

Clean TSE version 4.50.13:

1. -Create a file

     /mnt/c/temp/ddd.txt

2. -Put in this file and save

--- cut here: begin --------------------------------------------------

[default]

windowLineRelativeCurrentGI = 0

--- cut here: end ----------------------------------------------------

3. -Then run this TSE for Microsoft Windows program

--- cut here: begin --------------------------------------------------

PROC Main()

 STRING sectionS[255] = "default"

 STRING searchS[255] = "windowLineRelativeCurrentGI"

 STRING fileNameS[255] = "/mnt/c/temp/ddd.txt"

 STRING s[255] = ""

 s = GetProfileStr( sectionS, searchS, "", fileNameS )

 Warn( s ) // gives empty string 

END

--- cut here: end ----------------------------------------------------

4. -That will return the empty string. So it did not find this  value.

c. Note, but if I in Linux tested with and save in /mnt/c/temp/ddd.txt

[default] 

test = hello

and the TSE program

PROC Main()

 STRING sectionS[255] = "default"

 STRING searchS[255] = "test"

 STRING fileNameS[255] = "/mnt/c/temp/ddd.txt"

 STRING s[255] = ""

 s = GetProfileStr( sectionS, searchS, "", fileNameS )

 Warn( s ) // that works now suddenly in Linux and gives 'hello' (well have you ever...)

END

with friendly greetings

Knud van Eeden

[knud van eeden]

Updated:

The second occurrence should of course instead of 

> 3. -Then run this TSE for Microsoft Windows program

be

> 3. -Then run this TSE for Linux program

[knud van eeden]

[knud van eeden]

It looks at the moment like it has something to do with (very persistent) retaining the (GetProfileStr()) information

(e.g. in memory).

If one does a restart of TSE for Linux then it works.

So I guess it only works for finding the first of the GetProfileStr() variables,

it then fails for 2nd, 3rd, 4th, ... I will check that further.

But in Microsoft Window one can change the GetProfileStr() variables on the fly it seems,

without not needing to restart TSE for Microsoft Windows.

[knud van eeden]

Yes, that seems to be the issue.

1. In Microsoft Windows if you change the values of 

windowLineRelativeCurrentGI = 0

to e.g.

windowLineRelativeCurrentGI = 15

and run ddd.s again, it shows immediately 15.

Same for other values you set, e.g. 20, 30...

So no restart of TSE for Microsoft Windows is necessary

at all.

===

2. But in TSE for Linux when you change the value

in the .txt file

E.g.

windowLineRelativeCurrentGI = 15

and run ddd.s again it still shows the old value (or maybe even the empty string).

Only a RESTART of TSE for Linux again forces

it to show the newer value (=15).

[knud van eeden]

And of course the behavior in TSE for Linux is not desirable.

For example when the user then changes something in his variables

(e.g. adding some new variable (that was actually what I did,

and then mysteriously got the answer that it was not found when

running the search again) in his INI file

and then search for that value, in TSE for Linux you will very likely

get the result that it is not found or similar.

Which leaves the user puzzling about what is going on, because it 

is there in that file thus.

Only a restart (maybe, as not sure at this moment that that will

always resolved the issue) will then maybe resolve it.

[S.E. Mitchell]

I'm sorry, but I'm having a hard time following you.
Are you saying you are running TSE, loading an .ini file, and then
changing the .ini file via a different process, and expecting TSE to
notice the changes?
The Linux .ini support does not work that way. When reference an .ini
file, then the entire file is loaded into memory. If you change the
.ini file via the current program, using the profile functions, then
of course TSE will notice. But it won't notice any changes made to
the .ini file via a different process, since it loads the .ini file
into memory.
I guess I could change it so that on each .ini file function, TSE
checks to see if the file has been changed since it was loaded, and
then reload it.
But that seems like a strange use case to me. Is this something that
is common and that users would expect?

[knud van eeden]

1. The Linux version of GetProfileStr() seems thus to behave differently compared to the Microsoft Windows version of GetProfileStr()

I assume that that can be reproduced elsewhere also.

2. So replicating the behavior of the  Microsoft Windows version of TSE also in Linux would be if agreed be the way to go. So yes, a reload after change in the .ini file also in Linux.

3. Currently it is thus so that if changing an existing value of a section variable is not detected and e.g. an old value is shown instead and also if adding a completely new section variable then showing a not found.

Which is all very counter intuitive for the user.

Sent from Yahoo Mail on Samsung Galaxy S24 Ultra / 1 terabyte / artificial intelligence

[knud van eeden]

And no, those changes to the .ini file are certainly not done via a different process.

Of course these changes are all done while only inside one and the same TSE e executable.

So change a .ini section variable while in e, then save that .ini file while in e, then run the .s program again while in same e. Result : old value for example. Expected of course the new value.

Sent from Yahoo Mail on Samsung Galaxy S24 Ultra / 1 terabyte / artificial intelligence

[knud van eeden]

To summarize: 

Only in TSE for Linux:

1. If changing an EXISTING value in the .ini file, GetProfileStr() shows the old value. Only a complete restart of TSE for Linux (here via restarting WSL and  e) will force it to read the correct new value.

2. If creating a NEW value in the .ini file, GetProfileStr() will state that that new value is not found in the .ini file. Only a complete restart of TSE for Linux (here via WSL and e) will force it to find that  new created value in the .ini value.

Thanks 

[S.E. Mitchell]

I can't reproduce this. This is my best guess as to what you are describing:

string proc test_profile1()
string fn[_MAX_PATH_]
string section[32] = "section"
string item[32] = "item"
string default[32] = "default"
string first_value[32] = "first-value"
string second_value[32] = "second-value"
string s[32]

fn = MakeTempName(GetTempPath())

if not WriteProfileStr(section, item, first_value, fn)
return ("Error on 1st WriteProfileStr()")
endif

s = GetProfileStr(section, item, default, fn)
if s <> first_value
return (Format("Expected: ", first_value, " but got: ", default))
endif

if not WriteProfileStr(section, item, second_value, fn)
return ("Error on 2nd WriteProfileStr()")
endif

s = GetProfileStr(section, item, default, fn)
if s <> second_value
return (Format("Expected: ", second_value, " but got: ", default))
endif
return ("")
end

proc main()
string s[255]
s = test_profile1() if s <> "" Warn(s) return () endif KeyPressed()
MsgBox("Passed")
end

[knud van eeden]

Hello,

It is very easy to reproduce.

Linux for TSE version 4.50.13 (clean, freshly unzipped)

1. Run TSE for Linux in WSL (Ubuntu)

2. Save the 2 attached files foobar.s and foobar.txt in the same directory

(adapt the path in foobar.s to your system)

3. Compile and run foobar.s

4. It will show 'hello' the first time.

5. Now goto foobar.txt and change 

    hello

   to e.g.

    hello123

   and save the foobar.txt file. 

6. Then run foobar.s again.

7. It shows STILL hello, not hello123 (despite e.g. rerunning foobar.s again and again).

8. It will ONLY show hello123 when you restart your TSE e, then run foobar.s again.

9. Conclusion: GetProfile() looks STILL at the old, retained, information.

9. Note: Doing the same on Microsoft Windows definitely shows the latest information (=hello123).

[knud van eeden]

Updated:

Use these 2 files attached instead.

[S.E. Mitchell]

I cannot reproduce this. It works fine for me.
Note that I did have to change the fileName to match my setup:
"/mnt/c/Users/sam/temp/foobar.txt"

Can you add this to the macro?
if not FileExists(fileNameS)
warn("Not found: ", fileNameS)
endif

[knud van eeden]

Create a directory

 c:\Users\sam\temp\

and copied foobar.s and foobar.txt into it.

Note: the sam directory is a bit of a special case, because for changes

one needs run as administrator rights there. But anyhow I can

reproduce it in about any directory. I will remove it now after this test.

Now changing in foobar.txt 'hello' to 'hello1' and running foobar.s again.

Still the old 'hello' is shown here at least.

[knud van eeden]

And you are of course using TSE 4.50.13 for Linux clean on Linux WSL Ubuntu, right?

If not please let me know, otherwise that should of course be the case. 

Thanks.

[knud van eeden]

And to test the other issue, that is adding a fully NEW entry in the foobar.txt file

E.g.

add to foobar.txt this line

test1 = hello1

and save the file

Then query in foobar.s this new entry 'test1'

by changing searchS to 'test1'

then compile and run foobar.s again.

The result here is an empty string.

===

Note: if you still can not reproduce all this, 

then I do not know anymore what is going on here.

Maybe it is then even something within WSL (version, ...) that is interfering here.

g:\utils\jpsoft\tcmd Mon 20-10-25 13:17:54>wsl --version

WSL version: 2.6.1.0

Kernel version: 6.6.87.2-1

WSLg version: 1.0.66

MSRDC version: 1.2.6353

Direct3D version: 1.611.1-81528511

DXCore version: 10.0.26100.1-240331-1435.ge-release

Windows version: 10.0.19045.6456

g:\utils\jpsoft\tcmd Mon 20-10-25 13:18:05>

If you still can not reproduce it (=change old value shows still old value + create new value shows empty string) then

it can not reproduced there and we probably will have to leave 'as is'.

Then knowing: always restart TSE e if any changes in the .ini file.

[knud van eeden]

I have now even reproduced it on Microsoft Windows 11, with 'wsl --install' fresh installed there,

downloaded the TSE 4.50.13 tar file and unzipped it and tested with or JPSoft tcc.exe and also Microsoft

tcmd.exe.

Both reproduced the issue using the foobar.s and foobar.txt file.

So I do not know what is going on that it can not be reproduced at your end.

If it still can not be reproduced at your end then proposing to close

this issue thus.

Thanks.

===

running TSE Linux WSL in jpsoft tcc.exe

running TSE Linux WSL in Microsoft cmd.exe

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/semware/2139551327.4729388.1760959237777%40mail.yahoo.com.

[Carlo Hogeveen]

Hi Knud,

For time management I redirect your messages to a monthly folder.
A 107 messages in October, mostly you reacting to yourself as usual, a post for each belated thought as it passes through.
For all that quantity this month none of them seem to have resulted in anything.
Well, there is always next month.

About GetProfileStr(), adding a FlushProfile() statement to your macro might fix your problem.

Carlo

[knud van eeden]

> About GetProfileStr(), adding a FlushProfile() statement to your macro might fix your problem.

1. Original file foobar.txt

default]

test = hello

2. Then change and save it it to

[default]

test = hello1

3. Tried FlushProfile() but it still shows only 'hello' and not the changed to 'hello1' in the file foobar.txt

PROC Main()

 STRING sectionS[255] = "default"

 STRING searchS[255] = "test"

 STRING fileNameS[255] = "/mnt/c/temp/foobar.txt"

 STRING s[255] = ""

 FlushProfile( "default" )

 s = GetProfileStr( sectionS, searchS, "", fileNameS )

 Warn( s )

END

4. Tried to remove foobar.txt completely from TSE for Linux. Still 'hello' when now running foobar.s.

5. Tried to convert foobar.txt to Linux line endings using 'dos2unix foobar.txt'. Still 'hello' when now running foobar.s.

6. Tried in TSE for Linux > 'Full configuration' > 'System' to set it to 'CR' line endings. Still 'hello' when now running foobar.s.

7. Tried in TSE for Linux > 'Full configuration' > 'System' to set it to 'LF' line endings. Still 'hello' when now running foobar.s.

8. Tried in TSE > 'Full configuration' > 'Systsem' to set it to 'CR/LF' line endings. Still 'hello' when now running foobar.s.

9. Tried purging and recompiling the foobar.s macro. Still 'hello' when now running foobar.s.

10. The only way to see 'hello1' is thus still (reproduced it again) to restart TSE for Linux completely.

Note: That this different behavior (TSE for Microsoft Windows versus TSE

      for Linux (WSL)) can not be reproduced by Semware is really

      completely baffling.

Probably a fresh downloaded and installed from the Semware email link

for 4.50.13 Linux installation should have to be used to see it happening.

Because when trying it here on 2 independent different systems

(Microsoft Windows 10 and Microsoft Windows 11 and freshly installed

4.50.13 for Linux) and always reproducing it still here whatever is

tried makes it very unlikely in my opinion that this is a local issue

only.

[knud van eeden]

And using the profile filename in FlushProfile()

does also still show the old value 'hello':

PROC Main()

 STRING sectionS[255] = "default"

 STRING searchS[255] = "test"

 STRING fileNameS[255] = "/mnt/c/temp/foobar.txt"

 STRING s[255] = ""

 FlushProfile( fileNameS )

 s = GetProfileStr( sectionS, searchS, "", fileNameS )

 Warn( s )

END

with friendly greetings

Knud van Eeden