Very Computer

I'd like the same script to run on 2 different machines, Hp and Sun.
The problem is that sh resides in different directories.  Is there
a way to have exec look in two places?

P.S.  No, I don't have write access to /usr/bin, or /bin

Any help appreciated,

John
--
_________________________________________________________________
Office phone: 503-737-5583 (Batcheller 349);home: 503-757-8772
Office mail:  303 Dearborn Hall, OSU, Corvallis, OR  97331
_________________________________________________________________

On every single machine I've seen sh is referable as /bin/sh. SUNOS
does this by having a symbolic link /bin -> /usr/bin, thus although sh
might actually reside in /usr/bin you can refer to it has /bin/sh. If
this isn't true then I would argue that your OS is very broke.

--
Graduating soon, and no job yet to go to, all UK offers gratefully
considered, email above address for details and my CV or miss out.

Quote:>I'd like the same script to run on 2 different machines, Hp and Sun.
>The problem is that sh resides in different directories.  Is there
>a way to have exec look in two places?

Fortunetly, there is an alternate way to force a shell script to be run as a
Bourne shell (/bin/sh or /usr/bin/sh).  Instead of using the construct
#!/bin/sh
as the first line of the script, try using the old comment symbole
:
as the first line in the file.  This will also force execution as a Bourne
shell.
 -or-
Just put a blank line as the first line of the script.  This is harder to
see than the ":" but works just as well.

You can force the script to run as a C-shell script by placeing a
#
as the first character in the file.  That is unless the # is followed by a
! as in #! .

--

           8545 SE 68 St.,  Mercer Island, WA 98040; (206) 236-1676
The probability of one or more spelling errors in this missive approaches
unity.  If this bothers you, run it through your spell checker!

: I'd like the same script to run on 2 different machines, Hp and Sun.
: The problem is that sh resides in different directories.  Is there
: a way to have exec look in two places?

Dunno' about HP and Sun, but on ISC (and AT&T, I believe), if you just have
a colon alone on the first line as the first char in the file, sh will be
found and used.

--
                                        --Ami
                                          Have YOU hugged YOUR smurf today?
Like so many Americans, she was trying to construct a life that made
sense from things she found in gift shops.
                -- Kurt Vonnegut, Jr.

Unfortunately, such scripts are not equal to programs.
A script starting with #!/bin/sh can be executed by execve(2)
and friends.  A script starting with : cannot.  It can only be
executed by exec*p* and from shells.

Casper

If env is in the same place on both machines, you can begin the script with

   #! /where/ever/env sh

but this has the drawback that it requires sh to be in the current
PATH.  Mind, if sh is not in /bin, who knows where env will be.

--
Alan Watson                        | It was like talking to someone who'd just

Department of Astronomy            | was convinced that they had no problem
University of Wisconsin -- Madison | 'cos it wasn't hurting yet.
                                   |                          -- Peter da Silva

There are more problems than just that. On HP /bin/sh is very simple.
If you want to use the later-than-Unix-v7 feature getopts you have to
use /bin/posix/sh instead. Sun and lots of other vendors have getopts
in their /bin/sh. This problem will not be solved with a ':' on the
first line.

This problem also exists when you want to have perl scripts and perl
is installed in different directories on different machines.
I know that you can work around this for perl by using a shell wrapping
in the beginning at the cost of an extra process creation for the shell.

Please anybody, if you have any answer or clue to this problem I'd like
to know.

Thanks / Sven

Most vendors have a /usr/bin/env.

This works for me:

#!/usr/bin/env perl

Casper

| >> I'd like the same script to run on 2 different machines, Hp and
| >> Sun. The problem is that sh resides in different directories.  Is
| >> there a way to have exec look in two places?
|
| >> P.S.  No, I don't have write access to /usr/bin, or /bin
|
| >On every single machine I've seen sh is referable as /bin/sh. SUNOS
| >does this by having a symbolic link /bin -> /usr/bin, thus although sh
| >might actually reside in /usr/bin you can refer to it has /bin/sh. If
| >this isn't true then I would argue that your OS is very broke.
|
| There are more problems than just that. On HP /bin/sh is very simple.
| If you want to use the later-than-Unix-v7 feature getopts you have to
| use /bin/posix/sh instead. Sun and lots of other vendors have getopts
| in their /bin/sh. This problem will not be solved with a ':' on the
| first line.
|
I have the same problem between Sun and an Old Dec station running Ultrix
The default shell /bin/sh on ultrix is very very old and very brain dead
the solution is to use /bin/sh5 on this system. Something like your problem.

The following was my solution to make a shell script that works properly
on a sun work proper using sh5 under ultrix.  Basically it looks for
a /bin/sh5 and if found switches shells automatically, Using a extra
flag to say if it is currently doing this.

Try this for your /bin/postix/sh problem or whatever shell you really want.

--------------8<-----------CUT HERE--------------8<---------------
#!/bin/sh
#
#  A shell script that works on Sun's and Dec stations
#
# Check the type of shell that is running

[ "$1" = '-sh5' ] && shift

# Shell script starts here
# ...

--------------8<-----------CUT HERE--------------8<---------------

------------------------------------------------------------------------------
       "[A computer is] like an Old Testament god,
            with a lot of rules and no mercy."   ---  Joseph Campbell
------------------------------------------------------------------------------

|>
|> >This problem also exists when you want to have perl scripts and perl
|> >is installed in different directories on different machines.
|> >I know that you can work around this for perl by using a shell wrapping
|> >in the beginning at the cost of an extra process creation for the shell.
|>
|> >Please anybody, if you have any answer or clue to this problem I'd like
|> >to know.
|>
|> Most vendors have a /usr/bin/env.
|>
|> This works for me:
|>
|> #!/usr/bin/env perl
|>
|>
|> Casper

If it is perl that you are running then one could also use ...

#!/bin/sh -- perl

    if 0;

... but this does expect sh to be in /bin/sh.  It has the advantage of
allowing one to pass any number of arguments to perl.
--
Brent Wiese                             Phone:     713-798-6034
Dept. of Molecular & Human Genetics Fax:       713-798-6521

Houston, TX 77030-3411  USA

Sorry, HP-UX have it in /bin/env.
(Maybe you're on a Sun and then /bin/env will work as well.)

Using an intermediate process to find out were perl is is not the perfect
solution. It can be made with sh as well. However sh is 20 times larger
than env.

        / Sven

|> I'd like the same script to run on 2 different machines, Hp and Sun.
|> The problem is that sh resides in different directories.  Is there
|> a way to have exec look in two places?
|>
|> P.S.  No, I don't have write access to /usr/bin, or /bin

Others have pointed out that /bin/sh should exist (possibly as a link)
on both of these systems.  However, I've run into a related problem on
Ultrix systems, in which /bin/sh is a moldy oldy sh that e.g. doesn't
understand functions or the ${varialbe:-word} syntax, while /bin/sh5
is what most people think of as a proper sh.  In that case I've written
sh scripts with the following preamble that detects the problem and tries
to get into a more suitable shell.

    #!/bin/sh

    # in case this is a moldy oldy Bourne shell that doesn't support
    # functions (e.g. on Ultrix), try to get into a more modern shell

    # rather than directly testing if the shell understands functions,
    # for my purposes it's easier to test if the shell understands the
    # ${variable:-word} syntax... the two go hand-in-hand on Ultrix

    if ( : ${HOME:-abc} ) 2>/dev/null; then
        : ok
    elif [ -f /bin/sh5 ]; then
        # use a modern Bourne shell
        [ $# -eq 0 ] && exec /bin/sh5 $0

    elif [ -f /bin/ksh ]; then
        # use a modern Korn shell
        [ $# -eq 0 ] && exec /bin/ksh $0

    elif [ -f /usr/bin/ksh ]; then
        # use a modern Korn shell (Ultrix doesn't put it in /bin/ksh, sigh...)
        [ $# -eq 0 ] && exec /usr/bin/ksh $0

    fi

--
Conrad Kimball           | Client Server Tech Svcs, Boeing Computer Services

(206) 865-6410           | Seattle, WA  98124-0346