2

Quick question. After compiling a program, I always have to explicitly tell it to run from the current directory by prepending ./ to the name. For example $ ./testprog -argument1

Is there a way to set up some kind of alias which would allow me to call it simply by saying $ testprog -argument1 , essentially allowing me to run the program from any location?

3

4 Answers 4

5

PATH=$PATH:. ... is easy for taking care of the ./ part... which you focused on, but paying more attention isn't really the meat of it. Besides that, many of us frown on it for security reasons. See Adding current directory to path for more discussion that aspect.

In case I've mis-interpreted (I have), I'll expand on what @DavidShwartz is saying.

Your remaining options include specifying the directory in question as part of the path (PATH=$PATH:/to/your/executable/dir), or if you only have a few programs in mind or they're scattered across many locations, using symlinks. If you're going the symlink route, I suggest setting ~/bin to be at the end of your path and creating your symlinks in ~/bin...

ln -s /to/your/executable/dir/program ~/bin/program

It is almost always best to put extra paths at the end of your $PATH statement. It is very rare that you want anything to override the system files. That will take care of reaching it.

For the last part, you can put a shell script in one of you $PATH directories which includes the options you want to pass. You can really cheat and skip the whole path thing entirely: alias runmyprogram '/to/your/executable/dir/program -argument1' (you can also include opening arguments here if you always want them)

There are more, but a shell script in your path or an alias command should do it.

7
  • Because if you are working in a directory were other users have write access, then they can trick you into trashing your stuff.
    – Zoredache
    Apr 3, 2012 at 21:36
  • @Zoredache Mainly because someone can forge an executable like ls or man and put it somewhere where you frequently run some stuff. If your PATH has '.' in it, local forged executable been started, not what you think.
    – Kondybas
    Apr 3, 2012 at 21:57
  • 1
    I almost wish you didn't tell him that. :-)
    – Kyle Smith
    Apr 3, 2012 at 22:40
  • 1
    This doesn't solve the OP's problem. It creates security issues and doesn't even let him run the executable regardless of his current working directory, which is what he asked about. Apr 3, 2012 at 23:52
  • 2
    @DavidSchwartz Sneak attack direction change at the end of the question. Got it. I got title fixation. :) Apr 4, 2012 at 1:39
3

Put your executable to folder in $PATH or add directory that contains this executable to $PATH

3

Most platforms provide a user-specific bin directory for just such things.

You can try a command like echo "${PATH}" to see if you have such a directory in your path. Look for something like /home/fred/bin in the path. It's usually very close to the beginning to allow you to override standard commands if you want. (Be careful!)

If you see that, make sure you have a bin directory in your home directory and put the executable there.

0

You can put the program somewhere you like, create a bashscript that invokes your program (meaning that points to it's location) and passes arguments. Call it mycommand and put it /usr/bin. Do chmod +x /usr/bin/mycommand and you now have a command that invokes your program.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .