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
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
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
Try './a.out'. It is likely that '.' is not in your path.
Thank you. I have added . to PATH and it now works.
Thank you. I have added . to PATH and it now works.
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
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?
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 $PATHand 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
I hope you put it at the end.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun
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/
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
I did. It now seems it shouldn't be there at all and I need a ~/bin directory for my executables.
>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
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
Nooooooooooooooooooooooooooooooooo! Don't put . in your path.
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
The problem now is how to remove it!
./a.out
-- The theory of Communism may be summed up in one sentence: Abolish all private property.
/usr/local/bin or /opt/local/bin
-- "When one man dies it's a tragedy. When thousands die it's statistics." Josef Stalin
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.
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.