So this was observed only under 68K Wanderer? This will make it harder. Do you have a tool that has these problems by runs under x86 AROS?

At the moment, I don't recall an AROS Application that from Shell does not detect the config file in its path.

But regarding the Shell, there is a more important Bug, which I had reported in the past and concerned "UHCTools"

http://archives.a...6-aros.lha

To install UHCTools (Cross-platform Installer Script) you need LHA in 'C' and an Internet connection

The installation will add commands in the user-startup, create the folder SYS:UHC where it will unpack the downloaded data, it will also create in the Env-Archive a UHC folder where some scripts will be copied, also in the Env-Archive it will create and a preferences file (UHCBIN)

UHCTools problems (see screenshot):
- User-Startup commands are not supported (even if you use a manual command, nothing changes)
- If you run one of the scripts found in "UHC:S" from a Shell, the System hangs, and then crashes VmWare

Did the same operation on a full OS 3.1 and everything worked fine, see screenshot

For the UHCTools, I created an bug report here: https://github.co...issues/112

Getting back to TKUnpacker, can you prepare me a zip of AROS with it installed, some example archive configured to use it and it failing like you described in initial report. I want to avoid situation where I do something different than you did and arrive at different behavior.

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

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.

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!

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

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

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! !

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.

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

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.

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

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?

@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.

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

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

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

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

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