Make Lock() look for path..?

[Thomas]

To be able to look for a command in the current path in case the user only entered the commands name.

You probably have to search in the path yourself, part by part one at a time. IIRC there is an example in The Amiga Guru Book. I could search it for you if you like.

Bye,
Thomas

[Thomas]

Well, I couldn't hold back and created my own example just a few days after we discussed this. Have a look at it here: http://thomas-rapp.homepage.t-online.de/examples/which.c

Bye,
Thomas

[Thomas]

Well, I didn't say there is no room for improvement ;-)

GetDeviceProc is probably the better solution. The program also looks easier with it.

The last part of the search now looks like this:

Code: [Select]


/* C: is not contained in the path list. */
/* Because C: may be a multi-assign we cannot just Lock("C:") */
dp = NULL;
while (!cmdlock && (dp = GetDeviceProc ("C:",dp)))
cmdlock = check_dir (dp->dvp_Lock,command);
if (dp)
FreeDeviceProc (dp);


Bye,
Thomas

[Thomas]

Awesome, now to make it perfect,only one thing didn't work. The case where the path includes a multiassign.

This case does not exist. The path only contains locks and a lock can only point to a directory, not to an assign.

You can try it out:

if you have an assign hugo: which consists of work:a, work:b and work:c, if you enter "path hugo: add" only work:a is added to the path.

Bye,
Thomas

[Thomas]

When looking inside a given assign my code worked with assigns to a single file.

This cannot happen. Yes, locks could point to files. But the assign and path lists only contain directories. You cannot add a file to the path neither can you create an assign to a file.

You can safely assume that the locks in the path nodes point only to directories as well as the locks returned by GetDeviceProc only point to directories.

I don't see why you try to make it so complicated. The "which" procedure I gave you works exactly like the Which shell command.

Bye,
Thomas

[Thomas]

I am amazed, didn't know that. However it is of no use. In case of CED you always have to enter CED: instead of ED and CED always opens a new window rather than opening multiple files in one window.

And regarding our topic, it makes no difference either. If you give CED: as command name, you get the lock immediately without searching and you cannot add CED: to the path - "object not of required type". The path can only hold directories,

Doing something like "assign c: ced: add" does not have any sense either. You just get the "object is not of required type" message for every typo, and even CED itself is not found.

Bye,
Thomas