Running shell scripts with ./ dot-slash

Question

I'm working on a file processing project and I am trying to run a shell script called runProcessing.sh in PuTTY. The server uses ksh. My supervisor told me to use ./ runProcessing.sh <param1> <param2> when executing a script, but whenever I use ./ it says either cannot execute or file not found. Whenever I put in just runProcessing.sh, it returns null pointer exceptions, which I have been working off of to continue my task for now.

I understand what ./ does when running scripts, but I'm not sure why it isn't working when I'm trying to run my script with it. Any tips or advice? I am a novice with Linux/UNIX.

Here is my script:

#!/bin/ksh
#
# Script to download processing files from the appropriate target
#
# $Id: runProcessing.sh 604 2013-01-14 21:56:35Z alex_rempel $
#

DIR=`dirname $0`
. $DIR/setEnvironment.sh
java $LDAPRUNMODE $JAVAOPT com.webproject.db.processing.FPJob  --logdir $CISLOGDIR --file [2] $* 
RET=$?

if [ $RET -gt 0 ]
then
    echo
    echo
    echo "------ runProcessing.sh Failed ------"
    echo
    echo
    exit $RET

`./something` (specifying the current directory as the place to find something) and `. something` (running something within your current shell rather than as a subprocess) both make sense. `./ something` is not valid usage. — Charles Duffy, Jul 02 '13 at 18:45
...by the way, your script is invalid because it has an `if` with no `fi`. You also need to quote your expansions, and shouldn't be using `$?` -- there's no point to it here. `if ! java ...; then ...; fi` suffices, with no reason to store `$RET`. Also, using all-uppercase for anything other than environment variables and builtins is bad form. (Relying on string-splitting to let folks pass in argument lists is _especially_ bad form, but it's pretty much ubiquitous amongst scripts launching Java apps... almost all of which are written by people who haven't the slightest clue about shell). — Charles Duffy, Jul 02 '13 at 18:46
well in my defense I modeled my script after a similar script for a similar process in my company's build, so forgive me for anything that is bad form. — superdiazepam, Jul 02 '13 at 20:38
As an aside, [Why is testing “$?” to see if a command succeeded or not, an anti-pattern?](https://stackoverflow.com/questions/36313216/why-is-testing-to-see-if-a-command-succeeded-or-not-an-anti-pattern) — tripleee, Nov 13 '20 at 07:25

score 2 · Accepted Answer · answered Jul 02 '13 at 18:50

The null-pointer exceptions are coming from your Java program, so they mean that the process was, in fact, started. They do not, as a rule, indicate a problem with your shell script or its invocation.

. something # this reads the file `something`, running each line as a command
            # in your current shell. (Actual behavior is a bit more sophisticated
            # than that, but it's close enough).

./something # this tries to run the file `something` in the current directory as
            # an executable. It doesn't need to be a shell script -- it can be
            # any kind of executable, and if it has a shebang line, that will be
            # honored to determine the interpreter or shell to use.

./ something  # <- this is simply invalid.

That said, you can record exactly what commands your script is running by starting it like so:

ksh -x ./something

This will display the commands your script runs. If the fault is caused by the script starting the JVM incorrectly, you can thus determine how the expected and actual invocations differ.

This helped me figure out if anything was wrong in the script, which turned out that aside from missing the fi at the end of the if-statement, was alright (enough). I have my issue mostly figured out now, I wasn't passing the proper parameters to the script when I was executing it. Thanks! — superdiazepam, Jul 02 '13 at 20:43

score 1 · Answer 2 · answered Jul 02 '13 at 20:21

Since you are running in the ksh environment you have another option that using the ./ operator.

Instead of making your script an executable, you can execute it by passing it as an argument to ksh, like so:

ksh yourScript

When you create a file in Unix/Linux, it is not automatically given permission to execute. Therefore, alternatively, you can modify the permissions of your script using chmod:

chmod +x yourScript

You should then be able to execute your script.

Running shell scripts with ./ dot-slash

2 Answers2