Let me dust off my old unix geek cap for a bit. The basic problem here
is that the 'shell' looks in certain places to find things to run and
usually your current directory (written as ./) is not in the list. Those
places are defined in a shell variable called PATH (all upper case). You
can see the current path setting by typing
echo $PATH
Each place to look is listed with a : in between, so you'll see places
like /usr/bin or /sbin as various folders the shell will look to find a
command to run. To add another item to the path list you export a new
PATH shell variable. You could do something like this:
export PATH=./
which would make your current path as the place to look for commands,
but that would clobber all the existing places. So the more correct way
would be to do
export PATH=./:$PATH
That adds the ./ location plus all the existing path settings. Now you
should be able to just run foo from wherever you are without putting the
./ in front. Of course once you close terminal that setting will be
lost. If you want it to persist you'll want to modify the .profile file
located in your home directory. To jump to your home directory just type
cd by itself. That should drop drop you in /Users/myUserName where
myUserName is whatever your login shortname is when you set up the
account. You can see where you are right now by typing pwd for present
working directory.
Files that start with a dot are generally hidden. You can see those by
using the ls -a command which tells the list command to show all files.
Amongst all those hidden files in .profile which you can edit with vi.
Somewhere in .profile is a line that starts with export followed by the
PATH=, a bunch of paths and then :$PATH. You can search and jump to some
text in vi by typing
/export
which should drop your cursor right at that text. There might more than
one export line in your .profile so make sure its exporting the PATH
variable. Now you can just stuff your ./: right after the =, :wq the
file and then exit and come back in. .profile is read when you first
fire up the command line shell. If you don't want to quit and start
terminal again you can just type
source .profile
which re-reads the .profile script.
Hope this helps.
CB
On 7/6/11 1:09 AM, Zachary Kline wrote:
Hi Jeff,
Unix is one of those things which takes a long time and a lot of practice to
use properly. Whole books have been written about the subject, and any general
Unix or Linux book should mostly be applicable to OS X. Do you have a
Bookshare account? O'Riley media publishes many texts ou might be interested
in, such as Learning Unix for Mac OS X. Beyond this, search the Internet for
Unix tutorials, they should apply quite well overall.
As for the specific case you're wondering about here, the reason your program
isn't running is that you're not quite using the correct command. YOu want a
period followed by a slash, not just a slash. ./foo
vi is a whole different kettle of fish, and again the Internet and literature is your best friend. I will
tell you that to quit, you want to first hit escape, and then type ":wq", without the quotes, to
save your work. ":q" on its own will quit unless you have unsaved changes, in which case you type
":q!" to abandon them.
Hope this helps,
Zack.
On Jul 5, 2011, at 9:35 PM, Geoff Waaler wrote:
Making a little progress. I since learned that I should be able to build my
foo executable in terminal by going to the directory and entering:
"g++ foo.cpp -o foo".
If I understand correctly assuming a clean compile, I should be able to run the
executable by entering "/foo"?
If I enter just the command without a slash, I receive the "command not found"
message, where as when I proceed the command with a slash, it indicates that the file or
directory does not exist.
When I enter "vi filename" I can see my file, but have not yet ascertained how
to exit the editor and get back to a command prompt?
Again, TIA for any info or documentation you can point me to describing how to
get going with terminal.
Best regards.
Geoff
On Jul 5, 2011, at 6:45 PM, Geoff Waaler wrote:
Hello Zack,
Thanks so much for looking into this. You indirectly answered one of my
questions -- it's unnecessary to create an xCode project just to build and run
a simple .cpp file (yay!!!).
Having not used Unix except for a very brief period in the early 80s when VI
was a line editor, perhaps you or someone else following this thread can
indulge a few novice questions. I gather VI is better for creating a .cpp file
than the textEdit app? If so, why? What is the process for building and
running from the command line?
Thanks again and best regards.
Geoff
On Jul 5, 2011, at 6:08 PM, Zachary Kline wrote:
Hi Jeff,
Interesting. I copied and pasted your program, exactly as given, from the
email to a vi editing session and compiled it from the terminal. The output
was what you would expect, i.e. it worked correctly.
I'm not sure why Xcode would give you a different result with such a simple
program, and am afraid I'm just learning to use it myself, so know very little
about it.
Very confused,
Zack.
On Jul 5, 2011, at 2:34 PM, Geoff Waaler wrote:
Greetings all,
I am getting started with C++ using XCode 4.0.2.
The following was created as a C++ command line tool. The objective of this
"main.cpp" code was to accept a n integer from the console and display it:
#include<iostream>
using namespace std;
int main() {
int num;
cout<< "Please enter an integer: ";
cin>> num;
cout<< "Thanks for typing. You entered: "<< num<< endl;
}
Upon running this code via command-r I receive the message that output was
generated. The log window appears to stop and prompt me as expected -- I see
the following:
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys000
[Switching to process 10756 thread 0x0]
Please enter an integer:
When I enter an integer (e.g. 9) the following text appears:
Please enter an integer: 9
Thanks for typing. You entered: 60106
Program ended with exit code: 0
Initializing num (ie int num = 0;) causes the garbage to disappear , except
that the initialized value is always displayed regardless what I enter in
response to the prompt.
I tried building a unix executable and running it from terminal, but the results did not
vary. An item in Google suggested running debug in "standard debug" mode, but
from what I can find this may no longer be applicable in xCode 4?
If anyone can offer a suggestion I would be most appreciative. Perhaps there
is another list that is mor appropriate for this type of query?
Best regards.
Geoff
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.