the OS thinks its a doc?

Post #195,560

2/19/05 6:40:03 PM

get in a terminal window
cd to the directory you have it in
type ./boinc_4.19_powerpc-apple-darwin <return> and you get an error that its a document?
regards,'
daemon

"I am not scared of al Qaeda, I am scared of fucking al Cracker sayeth Chris Rock

Post #195,566

by Another Scott

2/19/05 6:45:57 PM

That worked?!?

Now somebody explain to me what the leading ./ means and why it is necessary.

Thanks a bunch!

Cheers,
Scott.

Post #195,569

by CRConrad

2/19/05 6:50:51 PM

It means ".\\" ; HTH! (What, you don't remember MS/PC-DOS?)

Post #195,570

by Another Scott

2/19/05 6:59:47 PM

It still seems strange to me.

Let's see:

.. means the parent directory
. means the current directory
./ seems to mean the current directory as well (at least on Win2k).

What am I missing? How is "./filename.exe" different from "filename.exe"?

My thinking has been that an OS wouldn't care what the route to an executable was as long as it was started from the current directory (an all of the .dlls, etc., were available there or on the path). In this case, I seem to have a 6+ MB executable with everything it needs. I thought I had set the current directory to the executable's location (ls -last gave the expected output). It still hasn't clicked why just entering the filename didn't work.

And it's still a mystery why Finder still thinks the program is just a document...

A little more explanation would be greatly appreciated.

Thanks.

Cheers,
Scott.

Post #195,571

by Yendor

2/19/05 7:06:54 PM

Re: It still seems strange to me.

Let's see:
.. means the parent directory
. means the current directory
./ seems to mean the current directory as well (at least on Win2k).

That's all correct.

What am I missing? How is "./filename.exe" different from "filename.exe"?

See the title for [link|/forums/render/content/show?contentid=195567|this post] for the explanation. Peter's already said what's wrong with it.

-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania

Post #195,572

by Another Scott

2/19/05 7:22:25 PM

Yeah, but why does it matter?

Sorry if I'm seeming dense.

On Winders, I can put an executable anywhere. I can open a folder view on the desktop of that directory, double-click on the icon for the executable, and it'll run. Similarly, I can open a command prompt window and run it there if I'm in the directory where the executable is. It doesn't matter if the directory is on the path or not. It worked the same way on OS/2 and DOS as far as I recall. The command interpreter seems to always start in the current directory even if it's not specified in the path. Thus, the path was only necessary if you didn't start the executable from the current directory.

Why is it different on BSD/Unix/OSX? Does the command interpreter not automatically look for executables in the current directory first? Does the ./ tell the command interpreter to look in the current directory because it won't otherwise? <lightbulb>

Thanks.

Cheers,
Scott.

Post #195,573

by ben_tilly

2/19/05 7:27:03 PM

AFAIK the path always matters

But everyone always stuck . in the path, so you could always run programs in the current directory.

However on Unix they got tired of people finding exploits based on putting an executable under a likely name in a directory where it would be called. So many of them took . out of the path.

Cheers,
Ben

I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)

Post #195,674

by static

2/20/05 8:26:51 PM

DOS/Windows always looked in the current directory.

Regardless of the PATH setting.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Post #195,747

by ben_tilly

2/21/05 10:36:29 AM

Ick. I always had it in the path so never realized.

I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)

Post #195,577

by daemon

2/19/05 8:01:37 PM

common sense for non nix users

say you write a nifty program for remote access in your home directory and name it rm for short then exec it with the flag r for ron and * to remote access for all. Problem is that /usr/bin is in the front of your path so the shell will pick up the remove every file you see command instead. By explicitly requiring you to invoke the current directory for a file it indicates that you are aware of where you are in the heirarchy.
regards,
daemon

"I am not scared of al Qaeda, I am scared of fucking al Cracker sayeth Chris Rock

Post #195,578

by Another Scott

2/19/05 8:13:03 PM

Danke. Thanks to you too Ben. I appreciate it.

Post #195,632

by CRConrad

2/20/05 3:35:07 PM

Consistency, the hobgoblin of little minds - and Unix... :-)

The Other Scott excuses hisself:

Sorry if I'm seeming dense.

Hey, better you than me! ;-) (For once.)

Why is it different on BSD/Unix/OSX? Does the command interpreter not automatically look for executables in the current directory first? Does the ./ tell the command interpreter to look in the current directory because it won't otherwise? <lightbulb>

Ed Zachary.

Iff'n yer gonna HAVE a concept of "search path" that's supposed to tell ya where to run apps from (unless you explicitly SAY where they're at), then the consistent and logical thing to do would be to ONLY run apps from directories in the search path (unless, etc).

So, no surprise, that's what *nix does.

The way DOS/Winders (and, if you say so, OS/2) do it -- i.e, searching the current directory, whether it's in the path or not -- can be seen in two slightly different ways, albeit with the same end result: Either it *also* always searches the current directory, in *addition* to the path; or, you could say, in these OSes the path *implicitly* always *includes* the current directory.

Looking at it the first way it's inconsistent, going against the most basic definition of "search path"; the second, it's typical MS-OS sleight-of-hand based on not-explicitly-stated behind-the-scenes machinations.

Either way, consistent and logical it actually ain't -- *easy*, perhaps, but when you think about it, neither as consistent nor as logical as the *nix way.

</lightbulb>

[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)

Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]

Welcome to IWETHEY!