Bash script not working as commandline MySQL JDBC

[RVic]

I'm quite at a loss here.I'm using JDBC to connect to a MySQL database. If I type the command in from the command line (passing it the parameters for db name and user / password) it runs fine:

exec java -classpath .:$CLASSPATH:/home/user/ggrip/upserver/mysql-connector-java-5.1.26-bin.jar:/home/user/ggrip/upserver/GGUser.jar GG.GGServer "127.0.0.1:3306" ggripserver1 ggripv2 root root

However, if I create a bash file of the identical command and execute it, I'm getting:
user@Mint15-32 ~/ggrip/upserver $ echo $SHELL
/bin/bash
user@Mint15-32 ~/ggrip/upserver $ ./ggrip.sh
java.sql.SQLException: Access denied for user 'root'@'localhost' (using password: YES)Error creating connection pool!
java.sql.SQLException: Can't connect with: com.mysql.jdbc.Driver to jdbc:mysql://127.0.0.1:3306/ggripv2 root root

I just don't get it?

 

[markspace]

I'm quite at a loss here.I'm using JDBC to connect to a MySQL
database. If I type the command in from the command line (passing it
the parameters for db name and user / password) it runs fine:

exec java -classpath
.:$CLASSPATH:/home/user/ggrip/upserver/mysql-connector-java-5.1.26-bin.jar:/home/user/ggrip/upserver/GGUser.jar
GG.GGServer "127.0.0.1:3306" ggripserver1 ggripv2 root root

However, if I create a bash file of the identical command and execute
it, I'm getting: user@Mint15-32 ~/ggrip/upserver $ echo $SHELL
/bin/bash user@Mint15-32 ~/ggrip/upserver $ ./ggrip.sh
java.sql.SQLException: Access denied for user 'root'@'localhost'
(using password: YES)Error creating connection pool!
java.sql.SQLException: Can't connect with: com.mysql.jdbc.Driver to
jdbc:mysql://127.0.0.1:3306/ggripv2 root root

I just don't get it?

My guesses are 1) you have a typo, since you didn't show us the actual
script, or 2) you there's a shell or variable expansion that's tripping
you up.

Look up bash shell debugging, try a few things there, and let us know
when you've found a few things more. Make sure the command is executing
exactly as you expect, not some close but different facsimile.

 

[RVic]

The script is the same as the command itself (in fact, when I run the command from the command line, I simply copy it from the text of the script and paste it into the terminal window):

ggrip.sh

 

[Robert Klemme]

The script is the same as the command itself (in fact, when I run the
command from the command line, I simply copy it from the text of the
script and paste it into the terminal window):

ggrip.sh -------- exec java -classpath
.:$CLASSPATH:/home/user/ggrip/upserver/mysql-connector-java-5.1.26-bin.jar:/home/user/ggrip/upserver/GGUser.jar
GG.GGServer "127.0.0.1:3306" ggripserver1 ggripv2 root root

I'm not assuming that it's related to the error but you should quote
your classpath properly.

As Mark said: use shell debugging (insert "set -x" at top of script and
also in the interactive shell).

Also, "type java" might give you an idea whether "java" is an alias on
your command prompt.

Cheers

robert

 

[Steven Simpson]

ggrip.sh

Is CLASSPATH exported? Whether it is won't affect the direct command,
but it will affect what the script receives.

 

[RVic]

Gentleman,

Thank each of you for your help. I got it solved by simply putting a semicolon at the end of the lone statement in the script!

 

[Robert Klemme]

Gentleman,

Thank each of you for your help. I got it solved by simply putting a
semicolon at the end of the lone statement in the script!

Huh? I don't see how that can be. The semicolon will just terminate
the statement and won't change anything at all about the command line
sent to java. I am more inclined to believe the reason Seven put forward.

Cheers

robert

 

[Mike Amling]

Gentleman,

Thank each of you for your help. I got it solved by simply putting a semicolon at the end of the lone statement in the script!

I've seen something very similar when using Cygwin. The editor, vim,
knew it was running on Windows and provided a line ending of CRLF.
Cygwin read the script and treated the CR as part of the last word on
the command line. Putting a semicolon at the end protected the command's
last word from being unintentionally extended.

Mike Amling