Thanks for confirmation!

This closes irritating bug for this month! Thanks to all who participated and tune in soon for voting for December bug!

Ok, with 'workbench.library-45.4.zip' AROS 68k works fine with TKUnpacker, even if I use in Tooltypes CLI and DONOTPROMPT.

Attention LHA native AROS 68k does not work with TKUnpacker, from Shell it works fine, if on AROS 68k you use LHA native AMIGA no problem TKUnpacker works fine.

Also it happens that if you delete folders and files from RAM WinUAE closes, this happens with the AROS 68k Build of "aros.sourceforge.io" dated 16 October 2023

I have to try with your Build if the same thing happens !

Hmm, wait. These are 68k libraries, not x86. They are to test TKUnpacker with CLI tooltype.

Yes I also copied the stdlib.library, even on AROS One x86 I got the same GURU!

Did you also install stdlib.library that was in the zip file?

Yes most recent, I installed 'workbench.library-45.4.zip' and a conflict arose with other 'GURU' libraries. , see screenshot

Thanks - so they are all newer than v40 found in OS3.1

There are numerous versions of Workbench.library, some have bugs, however all Workbench.library OS 3.9 has those functions:

OS 3.9 = workbench.library v45.102
OS 3.9 BB1 = workbench.library v45.127
OS 3.9 BB2 = workbench.library v45.127
OS 3.9 BB3/4 = workbench.library v45.138
OS 3.9 BB4 AfA One = workbench.library v45.132 (sembra la migliore)

I enclose the saved icons on OS 3.9

@AMIGASYSTEM

Actually you found a 14 years old regression! I checked the codes and indeed before 2009 Wanderer could run CLI programs with an argument so it behave like OS3.9.

Here is fixed workbench.library:

https://axrt.org/development/workbench.library-45.4.zip

Please let me know if it works for you!

If you use IconX, please also check if it still works as expected after installing this workbench.library.

Can you share with me this Archive.lha icon with "Shell" set in OS3.9?

It looks like OS3.9 extended the logic on how this should be handled. Can you check the version of workbench.library that is present on OS3.9/AfaOS?

AfAOS is based on OS 3.9 BB4

On OS3.9 there is a gadget in the Tooltypes that allows you to start a program from Shell without the Command Prompt request

If you look at this Icon saved on OS 3.9, you will notice that in the tooltypes, in addition to CLI there is also DONOTPROMPT.

CLI and DONOTPROMPT on AROS x86/68k is recognised and works well, I use it often on AROS One x86, on OS3.1 however DONOTPROMPT is not recognised, so it is ignored.

On OS3.9, in the CLI tooltypes, DONOTPROMPT and DONOTWAIT "are hidden" (are the gadgets that store them in the tooltypes), if you add them manually, they will be seen, but will only be duplicated

Ok, I was able to unpack the first Archive under AROS and OS3.1 when not adding CLI tooltype. So in such case program and system behaves as intended.

Adding CLI tooltype has a different effect on AROS and OS3.1. On AROS it make the program run from shell without any arguments so it displays requester for selecting source archive. On OS 3.1 it actually makes the archive be considered a program and execute command window is opened. See screenshots. In both cases behavior is different than without CLI and different that what you shown on screenshot of AfAOS in the original thread (but that's not clean OS 3.1 right)?

The "Shell" option seems to be a different thing than CLI tooltype. I will do some further investigation on how CLI option behaves under Workbench 3.1.

Yes I had checked too, this morning I was probably still asleep and did not see the file

Ah ok, I didn't know. I will then use the ones from build.

In the meantime I checked TKUpacker under OS3.1 and it does not create TKUpacker.config. It shows the same error as on AROS 68k, see screen shot.

On AROS One 68k I only use native AROS 68k software, the LHA and ZIP commands are those present in the Contrib (aros.sourceforge.io),
enclose all the archives present in the contib,

Riguardo TKUnpacker.config hai ragione, non so perchè questa mattina su OS3 TKUnpacker funzionava senza TKUnpacker.config, probably forgot to delete it somewhere! !

Can you also provide me the lha and zip unpacker that are needed by TKUpacker?

That's strange BTH. I don't recall anything that would copy the files automatically from ENVARC: to ENV:

Even the installation instruction for TKUnpacker says explicitly:

1. move "TKUnpacker.config" to ENVARC:
2. move "TKUnpacker.config" to ENV: or reboot before using unpacker
3. move the executable "TKUnpacker" wherever you want, e.g. C: or SYS:Tools

It works if I copy TKUnpacker.config to RAM:ENV, which is what happens when you do a reboot !

As mentioned in previous versions of AROS 68k there was no need to reboot!

Ok, I check how this behaves on my build.

With regards to last point, I'd assume TKUnpacker reads config from ENV:. Try copying TKUnpacker.config to RAM:ENV and see if it works without reboot.

Ok, in the meantime I noticed that TKUnpacker now works on AROS 68k, however a small problem remains on AROS 68k.

In the attached archive there is TKUnpacker and two LHA and ZIP Archives with icons configured to be unpacked automatically by TKUnpacker, also there is the Env-Archive folder containing the config file (TKUnpacker.config)

- On OS3 if you run these icons associated with the archives, the file 'TKUnpacker.config' will immediately be created in the Env-Archive directory, and the archive will immediately be unpacked to the path set in the requestfile.

- On AROS One 68k (can't remember if AROS 68k is your old build) if you run the Icons associated with the archives you will get the error 'Unable to read file' "TKUnpacker.config"
This is solved by "manually" copying the file "TKUnpacker.config" to the Env-Archive, and everything will work

- On the Latest AROS 68k Build of "aros.sourceforge.io" dated 16 October 2023, after copying the config file, you have to reboot the system otherwise the file "TKUnpacker.config" will not be found