Bash Script as command

whited · 12-05-2007, 02:52 PM

So I have a program.bash which is in my working directory. I want to be able to just right "program" without the ./ and have it run. Is there any way to do this?

reddazz · 12-05-2007, 03:08 PM

Make sure your script has something like

Code:

#!/bin/bash

or

Code:

#!/usr/bin/env bash

at the top. Make your script executable and then copy it to somewhere in your path e.g. /usr/local/bin.

tronayne · 12-05-2007, 03:11 PM

Rename the program to "program.sh" then type "make program" (shell program source is .sh, the make utility knows how to create an executable shell program from properly-named source).

In your home directory .profile or .bash_profile or whatever file you use to set environment variables, put

Code:

PATH=.:${PATH}
export PATH

Log out and log back in so that takes effect.

chrism01 · 12-05-2007, 04:37 PM

shell code is run as source (actually interpreted). You don't use make on it. Just do as reddazz said.

ilikejam · 12-05-2007, 04:39 PM

Just something to note - having '.' in your PATH is potentially not a great idea:

http://it-support-servicestatus.web....ATH-060607.htm

Dave

unSpawn · 12-05-2007, 05:07 PM

Quote:

Originally Posted by ilikejam

Just something to note - having '.' in your PATH is potentially not a great idea

Agreed, esp. not if you're using the root account. Making an alias in your shells resouce file would be "easier".

tronayne · 12-06-2007, 08:43 AM

Oh, golly.

OK, I learned this stuff the Bell Labs way -- you know, most of those shell programs in /bin (13) and /usr/bin (420) (plus others spread all over the place) that start life as prog.sh in a directory of mixed source code (mostly, in the case of Unix-like systems, C), living in a source code control system (used to be SCCS, nowadays more likely CVS) and built to executables and installed with the make utility. Thousands of source code files, well commented, with source code control keywords, the whole bit.

Silly me, I continue to follow that model; shell program source is prog.sh, type make run prog by typing its name and all is well with the world; kind of a if it's worth doing it's probably worth doing consistently, I suppose. I also embed a standard set of CVS keywords to keep track of what I did, why I did it, when I did it and all that kind of thing (simply because I can't remember a lot of stuff a week from now). I even have a standard template for all shell programs (yes, I use Korn shell, not BASH, but there you are -- my stuff has to run on Solaris boxes as well as Linux boxes):

Code:

#!/bin/ksh
#ident  "$Id$"
#
#       Name:           $Source$
#       Version:        $Revision$
#       Modified:       $Date$
#       Purpose:
#       Author:
#       Date:
#       $Log$
#
#       define a fatal error function
function fatal
{
        print -u2 "${1}"
        exit 1
}
#       initialize flags to null
aflag=
bflag=
#       define usage message
USAGE="Usage:\t${0} [-a value] [-b value] args"
#       process command line arguments
while getopts :?a:b: name
do
        case ${name} in
        a)      aflag=1
                aval="${OPTARG}";;
        b)      bflag=1
                bval="${OPTARG}";;
        :)      print -u2 "${0}:\t${OPTARG} requires a value"
                fatal "${USAGE}";;
        \?)     print -u2 "${0}:\tunknown option"
                fatal "${USAGE}";;
        esac
done
if [ ! -z "${aflag}" ]
then
        print "Option -a ${aval} specified"
fi
if [ ! -z "${bflag}" ]
then
        print "Option -b ${bval} specified"
fi
shift $((${OPTIND}-1))
if [ "$*" ]
then
        print "Remaining arguments are:\t${*}"
fi
exit 0

Is that overkill? Well, maybe, but I don't have to type a bunch of stuff every time I start a new shell program...

And current directory first on the path? Well, I've been doing this on and off since 1962, starting with punch cards (How was Thomas Watson buried? Nine edge down, that's how) and getting into early efforts at usable systems with GE then Honeywell GECOS then Multics, then Unix System 3, then System V and derivatives (you know, BSD, Sun OS, Linux, etc., etc.). Following that simplest of rules that thou shalt not work as root has served me well on my own Linux systems along with the hundred or so users I develop for on a Solaris farm. It's convenient, particularly if you're modifying a program that is installed in a production environment so you execute the one you're working on rather than the older production version.

I'm far more worried about installing open source software that a bad guy may have embedded a nasty in that gets installed with mode 4755 as root than I am about current directory first on path. It's always at the back of my mind that everything owned by root can lead to a catastrophe when somebody, somewhere pulls this one (I do a bug hunt on file modes every time I install something just to make sure). I used to install every add-on owned and grouped bin just to avoid this kind of thing but current practice seems to be that root owns it all and that's that.

Anyway, that's my two cents worth for what it's worth -- write it as prog.sh, make it, test it, edit the source, and repeat.

jschiwal · 12-06-2007, 09:56 AM

For a script couldn't you use your revision control system directly to check out the script?

tronayne · 12-06-2007, 01:57 PM

Quote:

Originally Posted by jschiwal

For a script couldn't you use your revision control system directly to check out the script?

Of course -- but I'd rather follow the source code separate from executable rule and use the system tools to get stuff "made" and installed where and how I want it installed. I don't like having executables in CVS (with the single exception of the configure program) and I find it much, much easier to realize what some source code file is based on the file name extension (but not ever having that extension hanging on an installed executable -- makes about as much sense to me to install prog.sh as an executable is it does to install prog.c, or, shudder, prog.exe as an executable on a Unix-based system).

And, really, this is a tempest in a teapot: Unix-like systems are meant to reflect the personal preferences of the owner (or maybe the group preferences of the organization) so no big deal one way or the other.

chrism01 · 12-06-2007, 04:47 PM

I was only trying to point out that you don't need to make (as in compile/link) a shell prog, it's already to go. Of course you can use make to manage/install anything, but these days most people assume make=compile.

jschiwal · 12-06-2007, 08:09 PM

What kind of dependencies could you have for a bash script. My point is that running make on a single script won't do anything.

chrism01 · 12-07-2007, 12:25 AM

Ah, but if you are strict with 'the source code separate from executable rule' as tronayne is, then you use make to 'generate' the executable, even though in this case that would mean a CVS checkout and/or a cp, but no compile/link.
If you use the src code ctrl throughout a proj (formally iow), you can 'make' the whole proj, inc documentation that way.
I've seen it done on very large projects.
It's nice because you get a defined clean product (inc docs) esp for external releases/clients.
Actually, in re keeping a copy of the exes in CVS (or whatever) it's not necessarily a bad idea. It means you can tell at a glance if the exe in prod is the same size as the one in dev. Of course if the toolset is upgraded then the same src may compile to diff size exes.
I does also give you an idea of the time lag between dev compiled ver and prod ie release delays (and possibly an indicator if the dates don't look right even if the size does....)

jschiwal · 12-07-2007, 06:48 PM

I just realized that the source could be in a non-executable location, so you could have a make install target that would copy the script to ~/bin/.

I don't write production grade scripts. Just short ones I put in ~/bin/. There is a plugin for vim available that starts you off with a commented header similar to the own given on a post above. For most users, I think that should be enough formalization for their bash scripts.

The OP wanted to make the mistake of adding the current directory to his path, so this is probably beyond what he would want to do.

PAix · 12-08-2007, 07:52 AM

In conclusion, Tronayne is perfectly correct, but just a little industrially over strengthed and formal for the average person asking this particular question.

Not particularly useful to the original questioner, but I think the point has been established as a viable option in an industrial strength formal production environment.

Now I know why we don't ask about driving quetions, in case the OP learned correctly how to drive on the other side of the road

.

tronayne · 12-08-2007, 08:33 AM

Lesson learned during a wasted youth:

A quick and dirty shell program will turn into a permanent utility
The system won't work without that utility
Somebody, somewhere, sometime will blow away that utility
You will get a call at three in the morning
Better to be safe than sorry

It really doesn't hurt to have a src directory and a bin directory too.

Y'all have a great holiday!