Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Wanderer: properly run tools with CLI tooltype #64

Closed
deadwood2 opened this issue Mar 16, 2022 · 5 comments
Closed

Wanderer: properly run tools with CLI tooltype #64

deadwood2 opened this issue Mar 16, 2022 · 5 comments
Assignees
@deadwood2
Labels
IBOTM priority:default type:bug Something isn't working
Projects
Core

Comments

@deadwood2
Copy link
Owner

deadwood2 commented Mar 16, 2022 •
edited

"As mentioned on another post, on Wanderer there are problems to run an application when using the CLI parameter in the Tooltype, in my opinion it is a very important problem.

In practice if you want to run an executable from icon with CLI parameter, the executable doesn't execute any parameters included in the config file.

To check the problem just run the application TKUnpacker.

TKUnpacker allows with a Click to automatically unzip an Archive, on OS3 when you click on an Archive file a request asks where to unzip the archive, on Wanderer instead the request asks the path of the Archive file, if executed you get the error Unknow format or file not found - Ram", practically the archive is not found!

I attach screenshots exhaustive, the problem should also be present on AROS x86"

"TKUnpacker as soon as it runs looks for and executes its configuration file located in the ENV "TKUnpacker.config".

Wanderer doesn't seem to know how to interpret the script, on OS 3 everything works normally

This problem happened to me also with other applications that work from Workbench through the "CLI" parameter."

https://ae.arosworld.org/index.php?topic=798.msg10150#msg10150
@deadwood2 deadwood2 added type:bug Something isn't working priority:default labels Mar 16, 2022
@deadwood2 deadwood2 self-assigned this Nov 2, 2023
@deadwood2
Copy link
Owner Author

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

https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1137&rowstart=20&pid=2898#post_2896

@deadwood2
Copy link
Owner Author

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

https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1137&rowstart=20&pid=2908#post_2905

@deadwood2
Copy link
Owner Author

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.
a4000arosdd-crop-2311221639-01
a4000mui3-crop-2311221641-01

@deadwood2
Copy link
Owner Author

It looks like this feature was added after OS3.1. Also reviewed source codes of Scalos and it also in case of PROJECT and CLI sends the project file path to the command.

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

https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1137&rowstart=20&pid=2914#post_2911

@deadwood2
Copy link
Owner Author

Checking history, the project name and lock was being passed to command line of CLI started program until rev 31196 (2009-05). Reading from commit it looks like it was not the intention to remove the arguments from CLI start, so it's a regression

deadwood2 pushed a commit that referenced this issue Dec 5, 2023
Backport: Pass the tags containing project name and lock to CLI launch
6237f56 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes #64
deadwood2 pushed a commit to deadwood2/fork-ADT-AROS that referenced this issue Dec 6, 2023
Pass the tags containing project name and lock to CLI launch
dd82a86 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes deadwood2/AROS#64
deadwood2 pushed a commit that referenced this issue Dec 19, 2023
Backport: Pass the tags containing project name and lock to CLI launch
fb1f911 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes #64
deadwood2 pushed a commit that referenced this issue Jan 12, 2024
Backport: Pass the tags containing project name and lock to CLI launch
8a480ad 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes #64
deadwood2 pushed a commit that referenced this issue Jan 15, 2024
Backport: Pass the tags containing project name and lock to CLI launch
c66675e 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes #64
reinauer pushed a commit to reinauer/AROS that referenced this issue Feb 10, 2024
@reinauer
Pass the tags containing project name and lock to CLI launch
5adad54 
This allows executing tool from "Shell" with an argument via clicking. The
code was like this until rev. 31196. It looks like it's a side-effect of
that commit, not intention.

Note: OS3.9 as well as Scalos both allow this mode

This fixes deadwood2/AROS#64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@deadwood2 deadwood2

Labels
IBOTM priority:default type:bug Something isn't working
Projects
Core
Awaiting triage
Milestone
No milestone
Development

No branches or pull requests
1 participant
@deadwood2