Hyperion Entertainment Message Boards

I noticed something lately that has me puzzled.
_maybe_ it has always been this way, but I don't think so.

I am in a shell, 4.1FE, and inside a directory is a shell command. the directory name and the command name are the same.

Example

>cd
FE:Utilities
>Filer

Now, does the shell CD to the Filer directory, or does it run Filer/Filer?

My first try, it CD'ed to Sys:Utilities/Filer
typing "Filer" again ran the program

Then I cd'ed back to Sys:Utilities,
types "Filer", and Filer ran!

So, typing the name of a directory might CD to that directory, and might run the (same named) executable within that directory, without ever CDing there.

Since I usually keep my projects in drawers of the same name, I probably would have noticed this long ago if it was classic behaviour.

Any thoughts?

Have you thought about the "path" feature?

type "which Filer" in your shell and if a full path to the executable comes up it's known in path and will start filer from whereever you are in a shell

e.g. i'm in "SYS:" in a shell
my "Filer" sits on another partition (Tools:Utilities/Filer/Filer) and the "which" command shows just that
Typing "Filer" now starts the program

Does the path change without any command or request to change?

Just type the command "path" and you will get a list of the directories that are searched for commands. Most likely APPDIR: is one of them and if so that is what is causing the behaviour.

APPDIR: is part of my path.
I suppose I just don't understand how it works.

Sometimes I am just too old to figure out how this works.

Ah well. thanks all for the help anyway.

LyleHaze wrote:APPDIR: is part of my path.
I suppose I just don't understand how it works.

In short, APPDIR: contains a lot of links, each pointing to the path from which each command was last executed.

So as soon as you have executed Filer once, there will be a link saved in APPDIR: with the name "Filer" and pointing to the path you used Filer from last. The next invocation of Filer will find a match in APPDIR:, and running it will actually run the program from the path saved before (the target of the link).

For most people, it's a help to never have to use an explicit path (other than the first time) to run a command.

For some of us, it can be a mixed blessing, e.g. if you have to test different versions of the same program, then you have to make sure always to start them with explicit paths, even if you have one of them in your path (e.g. in your current dir).

Best regards,

Niels

Thank You Sir.
That makes sense.

nbache wrote:For some of us, it can be a mixed blessing, e.g. if you have to test different versions of the same program, then you have to make sure always to start them with explicit paths, even if you have one of them in your path (e.g. in your current dir).

It's actually a pain in the a** if you're using the SDK and AmiCygnix. There are same named commands in AmiCygnix:bin, SDK:local/C and system C: directories. I had to rename the AppDir directory in ENVARC: and create a file named AppDir in ENVARC: to disable AppDir: altogether.

AppDir may have seemed to be a good idea (and may be for some users) but it's pain for others. It would be nice to have some prefs where you could disable some commands or programs from being added to Appdir and the addition of a "noappdir" command to the system C directory.

I can understand how it could be very helpful to those users that spend most of their time playing with their mouse.
The CLI/Shell/Command Line can be very intimidating, requiring you to type in specific words in a very specific format to achieve success, and complaining in terms that are not understood if you fail to do so.

Making the "Path" almost automatic is a neat trick. I say almost because you have to get it right once.

But for luddites like myself who live in a shell, it presented a very confusing riddle. And that was aggrivated by my lack of understanding.
Because I was just OUTSIDE the named directory, I expect typing the name of the directory to "cd" me in. Sometimes it did, some times it did not.

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.

xenic wrote:

nbache wrote:For some of us, it can be a mixed blessing, e.g. if you have to test different versions of the same program, then you have to make sure always to start them with explicit paths, even if you have one of them in your path (e.g. in your current dir).

It's actually a pain in the a** if you're using the SDK and AmiCygnix. There are same named commands in AmiCygnix:bin, SDK:local/C and system C: directories. I had to rename the AppDir directory in ENVARC: and create a file named AppDir in ENVARC: to disable AppDir: altogether.

AppDir may have seemed to be a good idea (and may be for some users) but it's pain for others. It would be nice to have some prefs where you could disable some commands or programs from being added to Appdir and the addition of a "noappdir" command to the system C directory.

Remove appdir: from the path in user startup and then you only have to worry about explicit references to appdir:someprog, these are usually deliberate and so not an issue. Dismemebering appdir completely is cutting off your nose because you want to get rid of a spot....