This is probably something simple, but command line support is broken in
the current release.

*** Bug 1082 has been marked as a duplicate of this bug. ***

edit]
patch for dist.sh file for building the command line version of processing.
copies care.jar and pde.jar on mac os x

Hello,

If the problem that was preventing this for working for others is the same
as what prevented it for me then indeed the solution is simple. The problem
i was getting when trying to use the command line release was ClassNotFound
errors being generated. It turns out some jars were not being correctly
copied into the lib directory by dist.sh, namely core.jar and pde.jar. I
have attached a patch demonstrating one way of solving the issue on my
platform (mac os x). I scanned through previous revisions a bit and i think
the problem was that the make.sh script in the macosx/ build directory
changed where it was putting those particular jars (there was a new
variable $RESOURCES that the dist.sh for the command line version did not
know about, my patch simply incorporated that path into it). I haven't
tried this on other OS's and i also noticed the following messages.

cp: ../../xml: No such file or directory
cp: ../../candy: No such file or directory

So the candy and xml libs are probably not being copied either.

Hope this helps
Yannick

P.S

The attachment above is the one i am referring to, i didn't know the
attachment form would not bring me back to this one.

P.P.S

Awesome project by the way! :)

Another problem i found (not sure if anyone else is experiencing this), was
being unable to use the generated launcher script from outside the
directory it was sitting in. A bit of investigating showed that the
classpath was not including all the jars. I have included a modified
version of this file that fixes this. My bash fu is not that great so i am
not sure if this is the best way to do this, but basically i cd into the
containing directory, and then reset the $APPDIR variable. Worked for me
(mac os x).

#!/bin/sh

APPDIR="$(dirname -- "${0}")"
cd $APPDIR
APPDIR=`pwd`

# includes java/* in case a Java install is available
for LIB in \
java/lib/rt.jar \
java/lib/tools.jar \
lib/*.jar \
;
do
CLASSPATH="${CLASSPATH}:${APPDIR}/${LIB}"
done
export CLASSPATH

export PATH="${APPDIR}/java/bin:${PATH}"

#java processing.app.Commander $*
# if you know a better way to do this, submit it to dev.processing.org/bugs
java processing.app.Commander "$1" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9"

Also, unrelated to this but causing me a few problems was an extra space at
the beginning of the shebang line (i also corrected this in the code i
pasted above).

Cheers

edit]
Implement --preferences command line switch

I was trying to get Processing to launch from the command line (via emacs,
really) and discovered that it was failing because --preferences was ignored.
This is my attempt at implementing it.

*** Bug 1208 has been marked as a duplicate of this bug. ***

*** Bug 1209 has been marked as a duplicate of this bug. ***

re: finding / loading the default preferences (lib/preferences.txt) when run from commandline.

the problem for me is that i'm not in the directory of pde.jar. so Base.getContentFile() returns a
wrong path (user.dir) and everything goes down from there .. but: one can get the path to the
jar from which a class was loaded (Base -> pde.jar) and that seems to work fine (both
commandline and "normal operations") here on my machine (mac):

// (line ~1724)
static public File getContentFile(String name) {

File pde_jar = new File( Base.class.
getProtectionDomain().
getCodeSource().
getLocation().
getFile() );

String path = pde_jar.getParentFile().getAbsolutePath();

// ... rest as before


and .. just to have all things together: this should go into Commmander() (line ~150):

} else if (arg.startsWith(preferencesArg)) {
preferencesPath = arg.substring(preferencesArg.length());

}

thanks!
F

edit]
patches on revision 5537 to fix commandline support

these patches on Base and Commander fix all commandline problems for me.

everything boiled down to being path problems (getting preferences.txt,
sketchbook, libraries). i had to make Editor and addLibraries() "static public"
which might not be desireable but should be ok since Editor makes no sense in a
static context anyway. addLibraries() still takes a JMenu which is odd too for
cmdline but just passing null works. well .. just have a look.

F

Hello, I am trying to use command line --export-applet on a server that
doesn't have an X11 Gui available (I guest most servers don't have a gui
available). But looks like commander still wantso to open up a gui, and
close it once it is done. (I see a window opening and closing when I run it
in my MacOSX). But this causes trouble on my remote server:

./processing --sketch=Sine --output=test --export-applet
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation
which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
at java.awt.Window.<init>(Window.java:318)
at java.awt.Frame.<init>(Frame.java:419)
at java.awt.Frame.<init>(Frame.java:384)
at processing.app.Base.showError(Base.java:1715)
at processing.app.Base.initRequirements(Base.java:293)
at processing.app.Commander.main(Commander.java:91)

is there a way to keep commander silent and without using GUI? isn't it the
purpose of providing a command line access to an application? running it
without using gui?

Thanks a lot!
Sinan

that's a completely unrelated problem, please file a new bug report for it.

*** Bug 1298 has been marked as a duplicate of this bug. ***

*** Bug 1476 has been marked as a duplicate of this bug. ***