compiling in mandrake 9.1..and running executable

[gwlam12]

im having trouble running my executable in mandrake 9.1

i use the command gcc -o hw1 -Wall hw1.cpp

it compiles fine.

i type in hw1 and i get an error that says command does not exist or something. how come? what am i doing wrong.

i would also like to know how to install the GUI version of vim in mandrake 9.1. thanks.

 

[Barnaby W. Füi]

Running commands seems to be the one exception to "no path means look in current directory" rule that shells generallly follow. To run a file in the current directory, put a ./ before it, e.g. "./hw1"

oh, and I would imagine that gvim is already installed. Try running "gvim", or "vim -g".

 

[Nothinman]

Running commands seems to be the one exception to "no path means look in current directory" rule that shells generallly follow

Windows is the only OS I know of that uses the current directory in it's program searches and it's considered a security feature that unixes don't do this.

i would also like to know how to install the GUI version of vim in mandrake 9.1. thanks.

It might already be there, try running 'gvim' or 'vim -g'

 

[Barnaby W. Füi]

Originally posted by: Nothinman

Running commands seems to be the one exception to "no path means look in current directory" rule that shells generallly follow

Windows is the only OS I know of that uses the current directory in it's program searches and it's considered a security feature that unixes don't do this.

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

try running 'gvim' or 'vim -g'

Eerie

 

[bigalt]

most casual users like to add a line in their .login file that says,

setenv path $path .

or something similar, which adds the '.' path to the list it searches.

edit: that would also solve your problem, if you hate typing ./

 

[Nothinman]

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

But ls doesn't execute the file, so it's safe to list it's stats without any chance of causing a problem. Say you have '.' in your path and I put a custom ls command in my home directory, all have to do is ask you to do something in my home directory as root (assuming you're the admin) and when you cd /home/blah and type ls you just ran my trojan and gave me root.

 

[gwlam12]

ok, im not on my linux system right now so i will try running the executable later. thanks for the tip.

as for running vim -g, that is how ive been trying to run it when i get my error message saying "GUI not compiled at this time" or something to that effect. ive already tried instaling all vim packages that came with my mandrake cds

 

[Nothinman]

Then look for a vim-gtk package, it's probably on the CDs too.

 

[Barnaby W. Füi]

Originally posted by: Nothinman

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

But ls doesn't execute the file, so it's safe to list it's stats without any chance of causing a problem. Say you have '.' in your path and I put a custom ls command in my home directory, all have to do is ask you to do something in my home directory as root (assuming you're the admin) and when you cd /home/blah and type ls you just ran my trojan and gave me root.

I understand perfectly *why*, but it *is* a bit different from how paths work otherwise.

 

[gwlam12]

oh stupid me. gvim works. vim -g doesnt. thanks guys.

 

[Nothinman]

I understand perfectly *why*, but it *is* a bit different from how paths work otherwise.

Only for some things, for instance ld only loads shared libraries from the paths in /etc/ld.so.conf unless you use environment variables to change it.

 

[gwlam12]

Originally posted by: bigalt
most casual users like to add a line in their .login file that says,

setenv path $path .

or something similar, which adds the '.' path to the list it searches.

edit: that would also solve your problem, if you hate typing ./

can you give more specific instructions on that? im new to linux and ive looked online and in books, but cant find what i need to know. thanks.

 

[n0cmonkey]

Originally posted by: gwlam12

Originally posted by: bigalt
most casual users like to add a line in their .login file that says,

setenv path $path .

or something similar, which adds the '.' path to the list it searches.

edit: that would also solve your problem, if you hate typing ./

can you give more specific instructions on that? im new to linux and ive looked online and in books, but cant find what i need to know. thanks.

Edit ~/.bash_profile to include "PATH=$PATH:.;export PATH" Or something similar.

 

[n0cmonkey]

Originally posted by: Nothinman

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

But ls doesn't execute the file, so it's safe to list it's stats without any chance of causing a problem. Say you have '.' in your path and I put a custom ls command in my home directory, all have to do is ask you to do something in my home directory as root (assuming you're the admin) and when you cd /home/blah and type ls you just ran my trojan and gave me root.

Doesn't the shell follow $PATH in order? So wouldn't having /bin before . in your $PATH solve that problem?

 

[Barnaby W. Füi]

Originally posted by: n0cmonkey

Originally posted by: Nothinman

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

But ls doesn't execute the file, so it's safe to list it's stats without any chance of causing a problem. Say you have '.' in your path and I put a custom ls command in my home directory, all have to do is ask you to do something in my home directory as root (assuming you're the admin) and when you cd /home/blah and type ls you just ran my trojan and gave me root.

Doesn't the shell follow $PATH in order? So wouldn't having /bin before . in your $PATH solve that problem?

Yeah. Well, somewhat mitigate it anyways. /usr/bin would be before ., but you might forget that you haven't installed wget on your new system, and accidentally run a script put there by an evildoer

 

[n0cmonkey]

Originally posted by: BingBongWongFooey

Originally posted by: n0cmonkey

Originally posted by: Nothinman

Yeah, but it is an exception to the rule, in a certain way. "ls hw1" works, as well as "ls ./hw1". "./hw1" works, but "hw1" doesn't.

But ls doesn't execute the file, so it's safe to list it's stats without any chance of causing a problem. Say you have '.' in your path and I put a custom ls command in my home directory, all have to do is ask you to do something in my home directory as root (assuming you're the admin) and when you cd /home/blah and type ls you just ran my trojan and gave me root.

Doesn't the shell follow $PATH in order? So wouldn't having /bin before . in your $PATH solve that problem?

Yeah. Well, somewhat mitigate it anyways. /usr/bin would be before ., but you might forget that you haven't installed wget on your new system, and accidentally run a script put there by an evildoer

wget is usually one of the first things I install Good point though.

EDIT: wget is in /usr/local/bin for me usually, which is also before the .. Lastly, never wget as root!