IDE only starts if cwd is its own directory

[GoogleCodeExporter]

What steps will reproduce the problem?
1. cd ~
2. ~/arduino-0015/arduino

What is the expected output? What do you see instead?
The IDE should start.  Instead, you get:
Exception in thread "main" java.lang.NoClassDefFoundError: processing/app/Base

This is because the script assumes that it is run from it's own directory.
 The attached patch removes this assumption.

Original issue reported on code.google.com by p.d.oli...@gmail.com on 30 Apr 2009 at 9:45

[GoogleCodeExporter]

Hmm, today I find that that didn't work at all.  Here's another try.

Original comment by p.d.oli...@gmail.com on 3 May 2009 at 3:57

Attachments:

• arduino.diff

[GoogleCodeExporter]

Hi,
about the only solution to this problem is to dynamically detect the absolute 
path to
one of the jar-files in the arduino-directory structure, and then change the 
users
working directory to the appropiate parent-dir of the jarfile location.

This forum thread has some information on the topic
http://www.velocityreviews.com/forums/t147526-how-to-get-jar-file-name.html

Note:
This works only from Java 1.5 and up. As long as the Arduino-IDE is build with 
source- and target-argument 1.4 you can't use this.

Eberhard

Original comment by e.fa...@wayoda.org on 5 May 2009 at 2:16

[GoogleCodeExporter]

What's wrong with the approach of simply cd'ing to the right directory before 
launching the Java application?

Original comment by dmel...@gmail.com on 5 Jun 2009 at 8:25

[GoogleCodeExporter]

Make the launcher a shell script and have it do all the necessary contortions.  
This
is the way most launchers work anyway.

Original comment by clvrm...@gmail.com on 5 Jun 2009 at 9:02

[GoogleCodeExporter]

Hi, 
I agree it's not a big problem, but a bit annoying. 
Most people, including me, don't want to open a console-window simply to start 
their
Arduino-IDE, or write their own shell-script to start the app. The 
Arduino-software
cannot provide a default shell-script that works for everybody, because we 
don't know
the directory into which the user will install the IDE.

Java 1.5 provides a way to solve this, but since there are very few complaints 
about
this, I see this as a low priority issue. 

Original comment by e.fa...@wayoda.org on 6 Jun 2009 at 8:34

[GoogleCodeExporter]

Am I missing something, here?  This seems like a really simple fix to me.

dmellis: Huh?  Why would you want to do the extra typing?  Why would you want 
to have
to remember to do that before you ran the IDE?  Imagine if every program made 
you do
that; the concept of a "current directory" would no-longer even make sense in 
that
scenario.

clvrmnky: this *is* the launcher script.  Why would you want to add another one 
when
you could just fix this one?

e.fahle: You CAN provide a shell script that works for everybody.  The attached 
patch
does just that.  It figures out which directory it is run in, and changes to 
that
directory for you.

Original comment by p.d.oli...@gmail.com on 6 Jun 2009 at 11:35

[GoogleCodeExporter]

p.d.oliver: sorry, I meant having the shell script cd to the right directory, 
not the user.  wayoda seemed to be 
suggesting that this needed to be fixed inside the Java application, which 
didn't make sense to me.  I agree that 
we should be able to simply patch the launcher script.  

Can we just add a: cd `dirname $0` to the top of the script instead of using 
the $arduino_dir variable 
throughout?

Original comment by dmel...@gmail.com on 6 Jun 2009 at 1:16

• Changed state: Accepted
• Added labels: OpSys-Linux

[GoogleCodeExporter]

dmellis: sorry, that makes more sense now :-)

You would want to "cd $(dirname $(readlink -f $0))" instead of "cd `dirname 
$0`",
since this also handles the case where someone places a symlink to arduino 
somewhere
in their path.

I only used $arduino_dir because I first tried setting the environment variables
without doing the cd to see if that would work (so that, e.g., the Open 
Sketchbook
dialog would start in the expected place).  It didn't work, but I left these 
changes
in place because it should be a tiny bit faster than running `pwd` and a tiny 
bit
safer than assuming that a child process will never call chdir.

Original comment by p.d.oli...@gmail.com on 6 Jun 2009 at 1:55

[GoogleCodeExporter]

I guess my comments were addressing the notion that the Java source has to 
change.  I
assumed there was a launcher script that can be fixed, which is also the 
workaround
for anyone having the problem.

Original comment by clvrm...@gmail.com on 8 Jun 2009 at 4:01

[GoogleCodeExporter]

It would also be safer to use pushd instead of cd, and a popd at the end of the
script, just so the context is restored.  Won't make any difference invoking 
arduino
from a desktop launcher, but it could if running arduino is one of a number of
actions in a user built script.

pushd $(dirname $(readlink -f $0)) >/dev/null
[the usual]
popd >/dev/null

Original comment by ckjohn...@gwi.net on 14 Jun 2009 at 7:27

[GoogleCodeExporter]

Comment 10 is not true.  Scripts run under their own instance of their 
interpreter,
and can not influence the environment of their caller.

OTOH, if you're suggesting that you should be able to use the "." command to 
source
random scripts with the current shell, then you deserve everything you get :-)

Original comment by p.d.oli...@gmail.com on 14 Jun 2009 at 9:03

[GoogleCodeExporter]

Un-dot-edly 11 is correct, I stand corrected.

Original comment by ckjohn...@gwi.net on 15 Jun 2009 at 12:28

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 15 Aug 2009 at 8:28

• Added labels: Milestone-0018

[GoogleCodeExporter]

Updated patch against trunk.

Original comment by p.d.oli...@gmail.com on 18 Nov 2009 at 9:11

Attachments:

• arduino.r754.diff

[GoogleCodeExporter]

I dealed with this problem and other ones (like the problem of accessing the 
serial
port). I solved this by changing some things in the arduino script and adding a 
suid
wrapper. I also installed all the ide withoud user write permissions and I 
makes a
copy f the files which the user needs to modify. The result is easy transparent 
for
the user.

If anithing of this is usefull for you, you can check the source packet 
available in
the ftp site of blogdrake (check this post:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1259672641/2 )

Original comment by alejandr...@gmail.com on 9 Dec 2009 at 8:47

[GoogleCodeExporter]

Issue 161 has been merged into this issue.

Original comment by dmel...@gmail.com on 29 Dec 2009 at 5:10

[GoogleCodeExporter]

The other problem is the current script is full of cargo-cult junk when it 
comes to
setting the CLASSPATH - putting directories on CLASSPATH has no effect, see
http://java.sun.com/javase/6/docs/technotes/tools/solaris/classpath.html.  In 
fact
it's so bad I just rewrote it entirely for the Solaris Arduino distro, see 
below. 
This works irrespective of which directory it is run from.

----------
#!/bin/ksh93 -p
cd ${0%/*}
typeset AR_HOME=$PWD
export PATH=$AR_HOME/tools:$AR_HOME/hardware/tools/gcc-avr/bin:$PATH
export
CLASSPATH=$AR_HOME/lib/pde.jar:$AR_HOME/lib/core.jar:$AR_HOME/lib/antlr.jar:$AR_
HOME/lib/oro.jar:$AR_HOME/lib/RXTXcomm.jar
export LD_LIBRARY_PATH=$AR_HOME/lib:$LD_LIBRARY_PATH
exec java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
processing.app.Base
----------

Original comment by Alan.Bur...@gmail.com on 30 Dec 2009 at 5:26

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 29 Jan 2010 at 8:58

• Changed state: Fixed