AmigaOS 3.2 released!

[AMIGASYSTEM]

I tested the comfortable and functional PatchASL of MUI 5 and I noticed some imperfections on the Icons "Dual-PNG" transparencies, this happens both with the Icon.library by PeterK and with the native OS 3.2 Icon.library, does anyone have any idea how to solve it.

[Yulquen74]

consider the following examplescript:

.Key ImageFile
.Bra {
.Ket }

Set testFile {ImageFile}
Echo "CLI Argument: $testFile"

Set testFile "`RequestFile Title "Select File" `"
Echo "Requestfile: $testFile"

If I run the script like this (literally): Execute testscript "tmp:some dir/some file"
and select the same file in the requester that pops,
it produces different results under 3.1 and 3.2.


In 3.1, both echo statements list the full path+filename without quotes.

In 3.2, the second echo statement produces the path+filename with quotes.

The requestfile command behave different under 3.1 and 3.2, in that the 3.1 version
returns path+filenama in quotes, whereas the 3.2 version does not.

This difference effectively breaks some scripts written under pre-3.2.

Is this behaviour intended?

[AMIGASYSTEM]

Ok Solved, I specify that the problem is only with the DualPNG Icons, the culprit was the PNG.datatypes, deleting the PNG.datatypese the DualPNG icons are seen well in transparency.

With the Glow Icons native 3.2 as shown in the screenshot no problem.

[Thomas Richter]

Originally Posted by Yulquen74

Is this behaviour intended?

Yes. Requestfile is required to put quotes around files that contain spaces or literal quotes. If you quote them again in a script, the quotes of the variable become escaped and as such part of the output in order to preserve the value of the variable.

[tomcat666]

Originally Posted by tomcat666

Anyone tried os3.2 with the AGS game selector? I get file lock problems on the temporary file that AGS uses to launch games. So after first game is launched the AGS is not able to write to the file anymore and an error that it cannot write the file is returned. This works fine on all previous versions of the OS.

So I found the bug myself. The problem is in the "EXECUTE" command of the OS3.2 , for some reason it keeps locking the files that are opened by the executing programs UNTIL the execute process is completed (the whole script). It unlocks them ONLY after the whole script is finished. If one uses the Execute command from WB 1.3 C: directory (name it execute2 and put it into c: and do alias execute execute2 ) then everything is working fine. The files are not being locked anymore.

[Thomas Richter]

Originally Posted by tomcat666

So I found the bug myself. The problem is in the "EXECUTE" command of the OS3.2 , for some reason it keeps locking the files that are opened by the executing programs UNTIL the execute process is completed (the whole script). It unlocks them ONLY after the whole script is finished. If one uses the Execute command from WB 1.3 C: directory (name it execute2 and put it into c: and do alias execute execute2 ) then everything is working fine. The files are not being locked anymore.

Execute isn't locking anything. The shell is, simply because it is reading from this file. Obviously, because it needs to read from the file you want to execute. Under 1.3 (and even 3.1), things *may* work differently because the shell there does not support recursive execution - if you execute within a script, the execute command copies the entire script over to a new location, and then closes the original file, releasing the lock.


IOWs, what you see is intended behaviour. You cannot modify or operate on a script that is being executed (somehow, this sounds self-evident).

[malko]

Originally Posted by Thomas Richter

[...] IOWs, what you see is intended behaviour. You cannot modify or operate on a script that is being executed (somehow, this sounds self-evident).

Agree but someone forgot to explain it to MS as you can edit a running batch/cmd script without warning.

[Yulquen74]

Originally Posted by Thomas Richter

Yes. Requestfile is required to put quotes around files that contain spaces or literal quotes. If you quote them again in a script, the quotes of the variable become escaped and as such part of the output in order to preserve the value of the variable.

Thats fine, but what is the reason the script gives a different result

on the 2 kickstart versions, even when run using the same command tools?

[Thomas Richter]

Originally Posted by Yulquen74

Thats fine, but what is the reason the script gives a different result

Not quite clear what you are asking. The problem with the Shell syntax is that it was hard to predict what the shell actually did with its arguments, and in which cases it quotes and in which cases it does not. So the whole thing was a an uncontrollable mess.


Just to give an example, if the file name contained a quote itself, like foo"bar (a possible, though unusual file name), and you would have put that into quotes on a kick 3.1 shell, the result would have been


"foo"bar"


and that would give an invalid parse because the last quote misses a second one.


Thus, the 3.1 and before "ad hoc" approach simply cannot work.





Things are rather clear now: RequestFile puts its return code into quotes if it has to, i.e. because there is a blank or a quote or escape character in the file name. This has the consequence that just putting the result of RequestFile as argument of a command, it "works". There is no additional pair of quotes needed.


Thus, if have a file name like foo"bar now, requestfile notices that it needs quotes, and gives a variable content of


"foo*"bar"


which parses correctly if provided as argument to a command.


If you put *another* round of quotes around an argument - well, the shell *needs* to preserve the quotes correctly, as they are part of the argument, and hence,



"$VAR"


becomes translated to


"*"foo***"bar*""


because each quote requires escaping, and each asterisk requires escaping. If parsed by a command, this relates to an argument



"foo*"bar"


which is not what you meant. You meant


foo"bar


Thus, remove one round of double quotes around the result code of requestfile.


It is really intentional, and it must work this way to enable file names with "wierd" characters in them.

[tomcat666]

Originally Posted by Thomas Richter

Execute isn't locking anything. The shell is, simply because it is reading from this file. Obviously, because it needs to read from the file you want to execute. Under 1.3 (and even 3.1), things *may* work differently because the shell there does not support recursive execution - if you execute within a script, the execute command copies the entire script over to a new location, and then closes the original file, releasing the lock.


IOWs, what you see is intended behaviour. You cannot modify or operate on a script that is being executed (somehow, this sounds self-evident).

Not sure if it should be expected behaviour since it does break anything that wants to change a file that was previously changed/created and it will break a lot of similar programs that execute something that was written by the same program.
But workaround to replace execute with the older version is ok for me

[Olaf Barthel]

Originally Posted by Yulquen74

consider the following examplescript:

.Key ImageFile
.Bra {
.Ket }

Set testFile {ImageFile}
Echo "CLI Argument: $testFile"

Set testFile "`RequestFile Title "Select File" `"
Echo "Requestfile: $testFile"

If I run the script like this (literally): Execute testscript "tmp:some dir/some file"
and select the same file in the requester that pops,
it produces different results under 3.1 and 3.2.


In 3.1, both echo statements list the full path+filename without quotes.

In 3.2, the second echo statement produces the path+filename with quotes.

The requestfile command behave different under 3.1 and 3.2, in that the 3.1 version
returns path+filenama in quotes, whereas the 3.2 version does not.

This difference effectively breaks some scripts written under pre-3.2.

Is this behaviour intended?

The intention certainly was to improve the consistency and the robustness of what the RequestFile command does. In practice it bumps against constraints within the shell itself and has to cover a lot of use cases which are hard to detect reliably.

For starters, try to avoid using the backticks if you have alternatives, such as redirecting the output of the RequestFile command to a temporary file. Unless you are absolutely certain that what's inside the backticks does not produce blank spaces, the asterisk character ("*"), backticks or very long lines (the shell will read and try to turn them into strings without giving you a chance to back out of that) you should use redirection, and even that only with great care.

The backtick mechanism can trip up the shell because it's not integrated consistently in how the script lines are processed. If used in quoted strings you may get unpredictable results, such as escaping with the asterisk character ("*") not having the effect you might expect. Nested backticks aren't supported either and may have unpredictable effects.

As for the updated RequestFile command itself, this is a hard problem to crack in the first place because either you add quoting and escape characters as necessary to deal with file names which contain such characters (unexpected behaviour, etc.) or you don't and then you bump into the same kind of problem which you tried to resolve with the quoting characters added which cannot be resolved consistently either.

This is the "curse" of the AmigaDOS shell commands, some of which are not designed to play well under the circumstances you want to put them to use for. The quoted string escaping is one such big obstacle and the backtick expansion is an even bigger problem because it's not working well within the shell itself (never has). Combine those two and you've got trouble with a big "T"

What can be done? Very little if you're restricting yourself to the means available within the shell "language". You might have to recruit ARexx to figure out what's in the string produced by RequestFile and whether it's safe to use.

My advice remains to use redirection and to accept for the moment that solving the problem currently involves replacing it with a different problem

[Yulquen74]

Olaf and Thomas: Thanks!

[Thomas Richter]

Originally Posted by Yulquen74

Thats fine, but what is the reason the script gives a different result on the 2 kickstart versions, even when run using the same command tools?

Yes, it has to give different results. The new shell (actually, not that new, since Os 3.9) does as it should - escaping escape characters within quotes.

[Thomas Richter]

Originally Posted by tomcat666

Not sure if it should be expected behaviour

But I am. Yes, it is expected that you cannot write into a file that is being read, namely the shell.


Look, once again: The shell is reading this script. You cannot modify a file that is being read. The only reason that "worked" before is because execute, in a (failed) attempt to provide recursive execution, created a temporary file in T:, including some overhead (of course).



Thus, if you want to be able to modify the script or the directory which is being executed, you can either copy it yourself to T: and execute from there, or give the script a parameter (.key, etc) such that execute has to make the copy.


Conditions under which execute copies scripts have changed, and even under 1.3 or before, there were conditions under which execute did not make such a copy. Thus, you aren't safe there either.



If there is something to fix then the scripts that expect that they can modify themselves or erase the directory they are located in - this cannot work.

[Lisko]

I don't know what's happened but for me textedit lost all highlights but C. Every others (shell, arex and asm) simply don't work. After installation I remember them working. I also tried to re copy the default file types with no luck. What else can I try? Thanks

[bubbob42]

Originally Posted by Lisko

I don't know what's happened but for me textedit lost all highlights but C. Every others (shell, arex and asm) simply don't work. After installation I remember them working. I also tried to re copy the default file types with no luck. What else can I try? Thanks

This seems to be a bug - I experienced the same a few days ago.

You could either configure the highlighting manually or restore the original highlight presets.

[Lisko]

Originally Posted by bubbob42

This seems to be a bug - I experienced the same a few days ago.

You could either configure the highlighting manually or restore the original highlight presets.

How can I do it? Especially the latter. Thanks

[boemann]

Before restoring could you please send me the prefs files they are stored in ENVARC:TextEdit/asm.prefs etc

These are also the files you need to delete afterwards to get back to default

Thanks

[Lisko]

Originally Posted by boemann

Before restoring could you please send me the prefs files they are stored in ENVARC:TextEdit/asm.prefs etc

These are also the files you need to delete afterwards to get back to default

Thanks

Sure here they are

[boemann]

Thanks - A quick view tells me it is only the color assignments of the various highlight elements that have become locked into having no color assigned. How this happens I'm yet to understand, but I fear it may mean that configuring the colors is a hit and miss task, until 3.2.1 is released.