assign remove a path

[LyleHaze]

@josDuchit

If I understand that correctly..
You are distributing a "project" that calls is opened by GUI4CLI, and may access some other things that are in a subdirectory of GUI4CLI.

If I understood that correctly, this may be of interest:

The "project" that calls GUI4CLI, I believe you said it would be distributed in the same drawer as GUI4CLI, so there's no path problem there. Set the default tool to "GUI4CLI", and it will always check the current directory first.

From there, the program can access it's own directory as PROGDIR:, and those additional tools as PROGDIR:C/ this will work as long as the executable (GUI4CLI) has been run at least once.

Doing it this way removed the need for assign and path commands completely.

Good Luck,
LyleHaze

[nbache]

this will work as long as the executable (GUI4CLI) has been run at least once.

Why would it need to have been run once? Aren't you mixing up this situation with the AppDir: functionality?

Doing it this way removed the need for assign and path commands completely.

Definitely good advice, either way.

Best regards,

Niels

[LyleHaze]

Why would it need to have been run once? Aren't you mixing up this situation with the AppDir: functionality?

Apparently.
Too much coding, not enough socializing.

Thank You.
Lyle

[JosDuchIt]

@LyleHaze
Sorry to have been rather confusing in my explanations
To make things more clear (i hope)

the archive contains
-Gui4Cli interpreter executable
-gui4 the Gui4Cli launcher
-MYapp.gc written in Gui4Cli
-MYapp.gc.info having the gui4 launcher as tool
-some more files & readme

Please note that as well gui4 in the archive as Gui4Cli may be different from what i do run normally (say the latest experimental Gui4 or Gui4Cli)

This archive is supposed to be dearchived in some drawer and to run out of the box from there. Intended users: users having never installed Gui4Cli 'properly- with all docs & tutorials & more stuff, that can't be bothered asking to install Gui4Cli first . I hope at least some of the apps i'll release that way will attract some interest.

The user is supposed to double click on the icon. Gui4 then looks if there is not alllready a Gui4Cli running
- if yes tells it to load MYapp.gc
- if not, gui4 searches in the path for Gui4Cli or for Guis:Gui4Cli ( i may have to verify where gui4 looks first) and if it finds the interpreter , it lanches Gui4Cli with MYApp.gc as argument.

My problem is not how to get things right for the user, but to make it easy for me to switch from my full install to what the user is supposed to get and which i have in a testdrawer.
A user that has the full Gui4Cli installl has to be treated differently. He is not interested in testing the 'out of the box 'solution. The readme will just point out what exactly he has to do., or i could detect the guis: assign signalling he has a full install allready in a install script.

I would like to make the described switch as easy & short as possible on my computer. Indeed i intend to upload other applications in the same way, for users not interested in programming Gui4Cli, or looking at the apps in the full archive.

@all
Thanks for all the info giving me a better understanding of the path & assign command

I guess at present i am interested
- in discussing if the LoadWB NEWPATH is a possible solution yet (or might be in the future)
... What is preventing the WB to quit or close even after unchecking all programs in WBStartup ?
... i remenber Dopus Magellan allowed you to close the WB : is there e difference between this closing and the WB Workbench/quit menu item ?
... Gui4Cli also has a WORKBENCH CLOSE|OPEN command i forgot about = it does not work

Code: Select all

case WORKBENCH :	// OPEN|CLOSE
	if (marg[0].num == K_CLOSE)	CloseWorkBench();
	else if (marg[0].num == K_OPEN)	OpenWorkBench();
	else myerror(gf->name, ERR_UNKEY, x->progline, NULL);
	  	break;case WORKBENCH :	// OPEN|CLOSE
	if (marg[0].num == K_CLOSE)	CloseWorkBench();
	else if (marg[0].num == K_OPEN)	OpenWorkBench();
	else myerror(gf->name, ERR_UNKEY, x->progline, NULL);
	  	break;

- in discussing if adding or removing a path from the WB/Workbench/execute menu coudl in the future take care of modifying the WB path inherited by all shells

@nbache

12.Amiga OS 4:> assign guis: remove
ASSIGN: Les options ADD, REMOVE, PATH et DEFER nécessitent l'utilisation de TARGET.
12.Amiga OS 4:> assign guis: guis: remove
12.Amiga OS 4:>

I recall (?) using the first line too
If that is correct , I don't know when it stopped working.

[salass00]

12.Amiga OS 4:> assign guis: remove
ASSIGN: Les options ADD, REMOVE, PATH et DEFER nécessitent l'utilisation de TARGET.
12.Amiga OS 4:> assign guis: guis: remove
12.Amiga OS 4:>

REMOVE keyword is only needed if you want to remove only a single path from a multiassign ("assign assign-name: path:to/remove/from/assign remove"). If you want to remove the entire guis: assign you should use just "assign guis:". Using "assign guis: remove" to remove an entire assign only works with the latest beta version of the assign command which AFAIK has not been released publically yet.

[chris]

It seems you need to quit WB first ,

No, you don't.

loadWB NEWPATH from a CLI has no effect

Yes it does. I just tested and it works "as advertised".

Path T: add
LoadWB NewPath
Open a new shell
Path
Verify T: (expanded to RAM Disk:T) is present.

[JosDuchIt]

@chris
You are right i retested it as follows


12.Amiga OS 4:> which gui4
Stock:Backup_Datas/Gui4Cli/C/gui4
12.Amiga OS 4:> path Stock:Backup_Datas/Gui4Cli/C/ remove
12.Amiga OS 4:>
12.Amiga OS 4:> which gui4
WHICH: Impossible de trouver « gui4 ».
12.Amiga OS 4:> LOADWB NEWPATH
12.Amiga OS 4:>

Opened a new shell

Nouvelle tâche Shell 10
10.Amiga OS 4:> which gui4
WHICH: Impossible de trouver « gui4 ».
10.Amiga OS 4:> which gui4
WHICH: Impossible de trouver « gui4 ».
10.Amiga OS 4:>

Very handy, thanks a lot


Joseph