[osmosis-dev] [PATCH] Some issues with Osmosis launch scripts

[Igor Podolskiy]

Hi,

one of my students and I managed to discover different issues with the 
Osmosis launch scripts in the $OSMOSIS/bin directory, both on Windows 
and Unix-like systems.

The shell script (osmosis) will fail or even worse, silently pass 
incorrect parameters to the Java process if any of the parameter values 
contain spaces. Consider the following command entered in an interactive 
shell:

osmosis --read-apidb database="osm" user="os m" password="os m" --write-null

This will fail with the "Only one default (un-named) argument can exist 
per task." message. Changing the quoting on the original command line 
doesn't help.

The problem is with the way osmosis shell script executes the java 
runtime. The relevant lines of the script read like this:

EXEC="$JAVACMD ... $MAINCLASS $OSMOSIS_OPTIONS $@"
exec $EXEC

While interpolating the $@ in this expression, the shell discards all 
original quoting. The solution I've found for this is doing the following:

EXEC="$JAVACMD ... $MAINCLASS $OSMOSIS_OPTIONS"
exec $EXEC "$@"

Apparently, the exact sequence "$@" instructs the shell to preserve 
original quoting in the arguments, while "foo $@" does not. It doesn't 
make any sense to me, either, but it's probably some compatibility 
burden from decades ago. Anyway, the attached patch 
osmosis-shell-quoting.patch makes the necessary change (tested on Ubuntu 
9.10 with bash 4.0.33 and /bin/sh which is linked to dash 0.5.5.1 here).

The Windows batch script gets the quoting right, but fails if Osmosis is 
installed on a drive different from the current working directory of the 
user. This is somewhat tricky, so I'll try to explain it step by step.

Assume that Osmosis is installed in c:\osmosis, PATH includes 
c:\osmosis\bin, and the current working directory is d:\data. User types:

d:\data> osmosis --read-xml dump.osm --write-null

The osmosis.bat script does the following:

set SAVEDIR=%CD%       # SAVEDIR == d:\data
set MYAPP_HOME=%~dp0.. # MYAPP_HOME == c:\osmosis\bin\..
cd %MYAPP_HOME%        # expands to cd c:\osmosis\bin\..  <-- BUG!
                        # %CD% == d:\data
set MYAPP_HOME=%CD%    # MYAPP_HOME == d:\data, which is clearly wrong.
# everything fails hereafter as the classpath points to d:\data\lib etc.

The bug is that the current working directory (%CD%) didn't change after 
cd %MYAPP_HOME% since the working directories are per-drive as they were 
in DOS 2.0 or so and we're on drive D: and did just change the CWD for 
drive C:.

The solution is really simple: all this %SAVEDIR% theater for "getting 
the absolute path" isn't necessary at all, because %~dp0 already returns 
the absolute path ('d' magic letter gets the drive, 'p' gets the full 
path, as documented on TechNet), so

set MYAPP_HOME=%dp~0

is perfectly sufficient, AFAIK.

The attached osmosis-batch-cwd.patch does the necessary change, tested 
on Windows 7 (32-bit).

Both patches apply to current trunk. I'd also like to thank Markus Bernd 
Wagner from the University of Stuttgart for discovering the shell script 
issue. If anything is wrong with the patches, just say so, I'll try to 
fix it.

Best regards
Igor
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmosis-shell-quoting.patch
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20110215/a6767dee/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmosis-batch-cwd.patch
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20110215/a6767dee/attachment-0001.ksh>