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

[DariusB]

Not sure, but what´s about PathPart(), or FilePart();

PathPart() will return a pointer to the end of the given path excluding the commandname.

FilePart() will return a pointer to the beginning of the command.

You can copy all caracters between the beginning of the path/commandname upto PathPart(path), adding a ZERO using Lock() and CurentDir() on it and call RunCommand(FilePart(path))

[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:

[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

[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:

[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

[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:

[Doobrey]

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

Have you ever tried coding for Winblows?
You'll be pulling your hair out and begging to go back to reading the Amiga DevCD in no time. :-x

[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-)

[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

[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:

[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

[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... :-)