a.out problem

I wrote a "Hello world" program in C.
gcc hello.c
creates a.out without warnings or error messages. ls shows that a.out
exists.
a.out
gets the response
-bash: a.out: command not found
Reply to
Peter Percival
Loading thread data ...
On a sunny day (Thu, 5 Jul 2018 14:22:06 +0100) it happened Peter Percival wrote in :
Try ./aout
For compile, better use gcc -Wall -o hello hello.c
./hello
Reply to
Jan Panteltje
Try './a.out'. It is likely that '.' is not in your path.
Reply to
gi-tux
Thank you. I have added . to PATH and it now works.
Reply to
Peter Percival
Thank you. I have added . to PATH and it now works.
Reply to
Peter Percival
please reconsider that approach carefully, it opens up a bunch of potential security risks
--
We gave you an atomic bomb, what do you want, mermaids? 
		-- I. I. Rabi to the Atomic Energy Commission
Reply to
Alister
I am new to all this! What are they? Is there an appropriate directory in which I can put my executables, and whose name I may safely add to PATH?
Reply to
Peter Percival
Its not unreasonable to do that in a development directory, but two caveats:
1) do make sure that the '.' is the last item in PATH or you may wonder why a standard program no longer works
2) If you want to make a program or script you've written available in more than one directory, put it in /usr/local/bin, *NOT* /bin or /usr/bin and make sure /usr/local/bin is immediately in front of '.' at the end of $PATH
and make sure that its access permissions are rwxr-xr-x, i.e. only you can overwrite or erase it but everybody has read and execute permissions.
Putting it in /usr/local/bin makes sure that it can't get overwritten by a new, shiny system program that appears in a system update.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
I hope you put it at the end.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
On Thu, 5 Jul 2018 16:11:22 +0100, Peter Percival declaimed the following:
Primarily -- any malevolent program could do things like create scripts with the same name as system software, and if you attempt to invoke the system utility in a compromised directory, it will run the script. {As a somewhat silly example, say a symlink was created to have "vim" -> "/bin/rm" and you didn't know... Typing "vim mysource.c" would result in deleting your source file rather than editing it).
During development, just get into the habit of deliberately specifying "./" while in the directory with the program. Beyond that, you may want to study the Linux "standard" file system layout (I'm not up on the preferred usages, but things like /opt, /usr/local/bin might be candidates... Or create a single user "mkdir ~/bin" and put that on the PATH).
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
The usual/easy thing is to create a directory 'bin' in your home directory, i.e. mine is /home/chris/bin, and add that to your PATH (it *may* get added automatically, some login scripts do this for you). Then you can put any shell scripts and/or other executables there and they will be found when you try to run them with just their name.
--
Chris Green
Reply to
Chris Green
I did. It now seems it shouldn't be there at all and I need a ~/bin directory for my executables.
Reply to
Peter Percival
On a sunny day (Thu, 5 Jul 2018 16:11:22 +0100) it happened Peter Percival wrote in :
/usr/local/bin
and for scripts I use /usr/local/sbin/
The other thing you may look into is writing a simpe Makefile, put all you dependencies there, define 'make install'
then you can simple type make make instal ... make install man make clean ... make coffee
And then later we talk about configure, configure.ac, and Makefile.am etc and then later about automatically creating makefiles for X with xmkmf
;-)
Best is to look at the many open source packages to see how it is done. read some ..... manuals
Reply to
Jan Panteltje
It all depends on what you want to achieve:
A ~/bin directory on the path is a great place to keep finished (or at least the latest good version) of your own scripts and programs. It makes them available to you no matter what your current directory and helps keep the last known good version from being broken by an ill-considered improvement attempt. It's useful in multi-user environments where several people may have scripts with the same name that do different things (think students doing exercises for example).
A /usr/local/bin directory on the path is a great place to keep finished (etc.) scripts and programs that you want to be available to all user ids (which may or may not be human users).
The current directory (when working on a program) is probably where you'll have the latest work-in-progress incarnation which may or may not work well. Having . on the path saves a little typing with this but has the disadvantage that if you need to run the last known good version instead of the work-in-progress then you'll need the full path.
Another use for having . (or ./bin or similar) on the path is to make the same script name context (ie. current directory) sensitive which can be a neat trick sort of like OO with the script name as the method name and the directory as the class. The one time I did something like this it was for a directory based persistent object setup with a .class symlink to the class directory and a .properties file contained the JSON encoded instance properties. The class directories all had a bin subdirectory so the path included ./class/bin rather than . it was an interesting approach to a persistent object store that worked quite well. Of course those paths were purely internal use they didn't get into any user paths.
For most purposes though having . in the path is slightly more trouble than it's worth and occasionally a RPITA so most of us don't do it.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
Nooooooooooooooooooooooooooooooooo! Don't put . in your path.
Reply to
mm0fmf
As usual... it depends.
I've always run with '.' at the end of $PATH, but I'm careful about restricting access:
- the firewall on am ADSL router is locked down so tight that from the outside its not possible to tell whether its turned off or alive and well.
- My main machines (laptops and a desktop) all run fairly restrictive firewalls and are logged out when not in use. I tend to use a lot of directories and logins, so different projects and running services (mail handling, house web server) all tend to have their own logins and associated directory structures.
- I have a small, encrypted partition which is used for sensitive data, e.g external passwords etc.
- My RPi is the same, but no firewall or encrypted partition. However, its turned off unless I'm using it.
- my desktop acts a house server, so runs a web server, mail server, spamassassin.... and is also my central CVS version control repository, so contains the master copies of all program source and shell scripts. - the house server is backed up overnight every night and all machines are backed up to offline disks each week immediately before their weekly software update.
I can live with this level of protection: I haven't lost anything yet. Others may want more protection or less.
Either way its something to think about, work out what you need and are prepared to manage, and then get it set up and working.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
The problem now is how to remove it!
Reply to
Peter Percival
./a.out
--
The theory of Communism may be summed up in one sentence: Abolish all  
private property. 
 Click to see the full signature
Reply to
The Natural Philosopher
/usr/local/bin or /opt/local/bin
--
"When one man dies it's a tragedy. When thousands die it's statistics." 

Josef Stalin
Reply to
The Natural Philosopher
You need to read some good introductions on how to use the shell (CSH or BASH or whatever). To remove it from your path, undo whatever you did.
Reply to
mm0fmf

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.