Page 2 of 2

Re: Unexpected shell behavior?

Posted: Sun Dec 18, 2016 9:39 pm
by broadblues
Overlapping shortcuts:

Typing CD is optional when typing in a new path.
Typing the full path is optional IF you've been there before.

When typing in something that could be either one, APPDIR wins.

I guess putting my projects into identically named directories will have to change.
There is sequence of events here that is worth understanding and whioch your statements above obscure.

If you type a command at the shell the following occur in order:

1. Resident list is checked if the commend is present it is executed.
2. Then if the command name is a valid path to an file (absolute or relative) the shell attempts to execute it.
3. If that fails and the command is just a simple filename (ie no directories) then the command path is searched in order till the file is found, if it is found then the shell attempts to exeute it.
4. If is not found the command is tested against directories and if matched an implicit 'cd' is done.

If an error occurs at any point in the above it's reported an the process stops.

There maybe more steps in the above but the import aspect for your unexpected behaviour is that the CD test is done last.

The relatively recent (FE onwards) addition of appdir: to the path as setup in S:Startup-Sequence means that once executed any prgram executed gets added inot the path, and so appears to alter the flow of events in the case you describe where directories match possible executable names.

I would recommend removing it or at the very least making sure it's the last element added in user-startup to avoid confusion when using more sophisticated paths with the SDK etc.

I think it was a bad idea to add it to the path, buidding shell users will find it that much harder to unsterstand how the serach path works, because it seems to change as you go, and it can screw things up for advanced user (though advanced user can simply removed it ofcourse...). But that's just me, your mileage may vary.