Assign question

I have an assign CED: to CygnusEd in my user startup
I observe the following




This is observed with CygnusEd 4.20 68k

I am using OS4.1.4 on SAM440ep

Is there an explanation??

You made an assign CED: which points to Datas:Teksten/CygnusEd. Now you run CED:Ed which is equivalent to Datas:Teksten/CygnusEd/Ed. This Ed program tries to run a program called ced. The ced program is stored in Datas:Teksten/CygnusEd, too, but because Datas:Teksten/CygnusEd is neither the current directory nor belongs to the DOS path, it cannot be found.

After you change the current directory to Datas:Teksten/CygnusEd, Ed can find ced successfully.

The "ced: unknown command" message does not refer to your CED: assign. The ':' is part of the message. It says "command: unkown command" where command is ced.

You need to add Datas:Teksten/CygnusEd to the DOS path if you want Ed to always find ced.

I did put these in user startup


I still have this behaviour



In fact i did have such a "Path add" in my user startup , but no assign to CED:
But in sequence i changed the EDITOR internal variable in Gui4Cli.prefs from something as
"Datas:Teksten/CygnusEd5.6/Ed" to "CED:Ed"

I then observed that i had a CED assign in a script loaded only after Gui4Cli.prefs.

I then added the assign in user startup te be sure Gui4Cli could find the editor.

Now the observations above are independent of this history.
I still don't see the light

Is there any reason why you always do this in the S directory?

Do you have a file called CED somewhere else in your DOS path, perhaps a script file?

Enter which CED to find out.

Hi Thomas,

there is no reason for starting the shell (NEWCON) on the s drawer, but the problem is not connected to that. Same results from shell (CON) started Amiga OS4>
I do observe the following though

8.Amiga OS 4> which g15gg
WHICH: Kan "g15gg" niet vinden
8.Amiga OS 4:> guis:c
8.Datas:Gui4Cli/C> which g15gg
Datas:Gui4Cli/C/g15GG


"g15gg" is an executable to which a path was also defined in user-startup
with
path guis:c add

Something else got mixed up

@thomas

In regards to your first post (post #2), why would it work when he goes back to S: and tries again a 2nd time?

Something to do with appdir? Why would it screw up after each reboot?

@MickJT

We only see that he runs Ed several times, we don't know what he does with the editor window once it is open. If the editor remains open, Ed will use the copy in memory and send a new file to it. And even if the editor window is closed, ced remains in memory if you don't end it with "Quit & die" from the menu. Appdir is another possibility.


@JosDuchIt

Seems like something has screwed up your path. Without being able to examine your system it's difficult to tell how. One possbile reason I could imagine is that the path change is not done in the startup CLI.

You need to know that the path is a local thing. Each CLI process has its own path. Using the Path command only changes the path of the CLI process it was executed in.

A child process inherits the path from its parent. So if you change the path in one Shell window and then enter NewShell into this window, the new window will have the same path as its parent.

Knowing this, the only way to have a "global" path is to set it in the initial CLI process because all other processes are created from this one.

Now, for example if for some reason you changed the section in startup-sequence from execute s:user-startup to run execute s:user-startup, all path settings done in s:user-startup only affect the child process created by run and are thrown away when user-startup ends.

Similarly if you run scripts from WBStartup which try to change the path, then these changes only affect the commands which follow in the script and are thrown away when the script ends.

@Thomas

You did put me on the right track.

I did change startup-sequence a while ago inspired by example of oldfart ( & probably copied wrongly)

I did not change to "run execute s:user-startup", but did put c:LoadWB before "execute s:user-startup"

I have reverted this and problem seems to have disappeared.

Lesson to be learned: If you have changed anything from the way the system came, and something starts acting up, your first attempt should be to try reverting the changes you made.

There are good reasons for the Startup-Sequence and related scripts to look exactly like they do - as you found out the hard way .

Best regards,

Niels