Make Lock() look for path..?

[Jose]

Update
My 3rd post ( 2005/6/23 0:37) is much more clearer and has an update....:-)



..........

Hi. Is there a way to make RunCommand use the path to check for any command ? I allways have to use the complete path to run the command I want to...

Also, is there a function somewhere to parse a command (thaty would be entered by the user) and eliminate the path, leaving only the command´s name ? I don't mind making one but if it exists why lose time with it...

EDIT:
The reason I want all this is to allow the user to  enter a command's name or command name with path. The command will be copied to ram: and after that it will be issued by RunCommand using ram: (hence why I need to change the string the user entered...)

Cheress

[Jose]

@DariusB

Thx, will try that.

@Everyone
Still is there a way that RunCommand can use paths without having to use the path command and parsing the results  :-?
I tried running the main process (RunCommand is invocated in a child process) from Shell too just in case but it doesn't work either ..  :oops:

[Jose]

I done a bit of reading and discovered that the path is searched and used only for commands, not their arguments. At least that's what the user DOS manual (3.1) says and that must be the reason for the problem I was having. I had an idea for solving it which I describe below, wich didn't work either but I think it's still a good one, suggestions please...


Since what I want is to copy a command, whose name string is entered by the user in a requester for example, to ram: and then use it recursively I need (or want) two things:

- To be able to take off the commands path in the string   entered by the user and leave only it's name when saving it to ram:. Solved by using FilePart(). If the user didn't enter a path (just the commands name), FilePart() leaves it intact.
- To be able to look for a command in the current path in case the user only entered the commands name.
Here is where the problem lies. I tried to solve this by obtaining a Lock() on the command's name. Then I use NameFromLock() to obtain the path that Copy will use. But I can't Lock() it. It only works if the command is in the current directory.

So my current question is, is there a way to make Lock() look for the current path or do I have to make my own routine ?
Any suggestions appreciated... :pint:

[Jose]

@Thomas
"IIRC there is an example in The Amiga Guru Book. I could search it for you if you like."

Thanks, AmigaMail2 had some stuff on directories and paths. I guess it's time to learn more about that. But if I end up needing that example I'll post about it here next week.
Cheers :pint:

[Jose]

I'll have a look, thanks  :-)

[Jose]

Hey Thomas :-D  
Ok, after reading the whole stuff in the DevCD about directories scanning, multiple assigns and whatever mess...

I wouldn't have made it without your example as they don't have one there that searches for paths. It might seem easy after reading the includes and checking the structure elements etc. (a pain..), but how's one to know if some stuff is advisable. For example, I've read various times that one shouldn't take the  structure of a Lock for granted, to avoid incompatibilities with future versions of the OS. But I guess that's the only way to search for paths (relying on  internal structures, in this case pathnode) as there's no DOs function that does it.

Anyway, just one observation. I noticed that the AmigaMail2 examples and docs advise on using GetDevProc. Is traversing the DOS list as advisable ? Surely not so practical, specially since this allows for multidirectory assigns to be handled more easily (ADCD_2.1:REFERENCE/HTML/AmigaMail_Vol2_guide/node007E.html).
e.g. if the user had included a logical device name correspondign to a multiassign in the beggining of the path your example would just try to lock it.

Phew... I think I won't read DevCD stuff for a while, my eyes burn!

Cheers
:pint:

[Jose]

@Doobrey

No:-), but I remember some coders here saying coding for windblows was easier ? I was thinking about giving it a try some day.. 8-)

[Jose]

Hi. Last night I finished my own code that does this and after a few stupid bugs I had to correct, it worked  :-o  :-D I tried to cover all possibilities, inlcluding the case where no device is given, in wich case the application will just try to lock the given file path in the current directory or look in the path. Awesome, now to make it perfect,only one thing didn't work. The case where the path (as issued by the Path dos command) includes a multiassign. It did work but only when the file being searched was the only or the first one in the assign list. I'm thinking about transforming the part of my routine that looks for multiassigns into a subroutine and then call it from the part that looks in the path, for every path entry. But... the pathnode structure is internal and not documented. If a given lock in a pathnode structure corresponds to an assign, is that a lock to the structure at the head of the multiassign (the one that has the multiassign's name) or the first lock in the multiassign list..? I'm not at home otherwise I'd have already tried it, but still I'd like to hear you guys opinion on this. The OS should have a routine that does all this like mine , er ok, ours...:-) I'll post it here later.
...
:pint:

[Jose]

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

That's precisely what happened to me. I guess it's something that could be added in the OS then...


"and a lock can only point to a directory, "

or a file. When looking inside a given assign my code worked with assigns to a single file. I think it might be because I take off the device's name from the the rest of the given file path before calling GetDeviceProc(), and then try to lock that path in each directory (lock) GetDeviceProc successively gives, to check if the file is there. If there's just a device name the path given to GetDevProc will be NULL (since ":" ends the string to a device only name, followed by NULL). And null corresponds to the root directory, or in the case of a multiassign the directory (ies) corresponding to the assign.  

Was just an attempt to understand it, but forget it, the thing works... :-)

[Jose]

"...neither can you create an assign to a file"

I have one to CygnusEd and it works.  :-?  I use it to launch CED saved files cause I have CED a directory not in the path or C:.

[Jose]

Maybe it doens't matter, but I found that Which finds multiple assigns in the Path :lol: Maybe it just gets the names of the locks in the path and then tries to find them in multiassign lists.
I had never bothered with Which and didn't even knew very well what it does. It would have spared me a night and a half of coding... :-x  :-)