batch file error?

[Dave Pawson]

set LOGCONFIG=file:%DTDANALYZER_HOME%/etc/log4j.properties

There is no log4j.properties file in the zip file. Or in the .gz file

bash script

#!/bin/bash
# Assume in installation directory. Else fail
dtdanalyzer_home=/installation/xml/dtdAnalyzer/dtdan

if [[ ! -f ${dtdanalyzer_home}/lib/DtdAnalyzer-0.1.jar ]]
then
echo "run from the installation directory. Quitting"
exit 2
fi


cp=
for jar in ${dtdanalyzer_home}/lib/*.jar
do
cp=${cp}:${jar}
done
cp=`echo ${cp}| cut -c2-` # cut the leading :





LOGCONFIG=${dtdanalyzer_home}/etc/log4j.properties

java -cp ${cp} -Xmx256M -Dlog4j.configuration=${LOGCONFIG}
-DDTDANALYZER_HOME=${dtdanalyzer_home}
gov.ncbi.pmc.dtdanalyzer.DtdAnalyzer $*

Tested with recent docbookx.dtd works fine... even without the log4j setting.

HTH





--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

[Chris Maloney]

Hi, Dave!

I'm so confused ... didn't you see the bash shell script? Here it is:
https://github.com/NCBITools/DtdAnalyzer/blob/master/dtdanalyzer.

As for the log4j ... I got that from the d2rq script. I know we're
not using it at present, but I thought, it looks like a pretty cool
utility, and maybe we'll want to use it in the future, so I didn't
take that setting out of the startup scripts. It doesn't break
anything, since nothing in the code is looking for this file. I'll
put a note about this fact in each of the existing scripts.

The bash script that I got from d2rq sets $DTDANALYZER_HOME based on
the directory in which the script resides. The only thing I'm not
crazy about is that it doesn't follow symlinks. So, if I set up a
symlink to point to the script from somewhere else, say:

cd /usr/bin
ln -s /home/maloneyc/DtdAnalyzer/dtdanalyzer

And then try to run /usr/bin/dtdanalyzer, it won't work, because
DTDANALYZER_HOME, inside the script, will be "/usr/bin".

I found a convoluted way of resolving that, here:
http://www.daniweb.com/software-development/shell-scripting/threads/342521/getting-pwd-of-the-script.
But I think it is too complicated, and probably brittle, and not
worth it.

This is really getting into the area of making a distribution package,
I think, so that people could get it with apt-get or rpm -- which is
beyond what I know how to do.

Let me know if you have any feedback on the existing bash script.

Thanks!
Chris

> --
> You received this message because you are subscribed to the Google Groups "DtdAnalyzer" group.
> To post to this group, send email to dtdan...@googlegroups.com.
> To unsubscribe from this group, send email to dtdanalyzer...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dtdanalyzer?hl=en.
>

[Dave Pawson]

On 14 October 2012 15:44, Chris Maloney <vold...@gmail.com> wrote:
> Hi, Dave!
>
> I'm so confused ... didn't you see the bash shell script? Here it is:
> https://github.com/NCBITools/DtdAnalyzer/blob/master/dtdanalyzer.

Yes... but didn't recognize it as a shell script?
It wasn't set +x
It didn't end in xxx.sh
which may have rung a bell.
Hence i wrote one.

>
> As for the log4j ... I got that from the d2rq script. I know we're
> not using it at present, but I thought, it looks like a pretty cool
> utility, and maybe we'll want to use it in the future, so I didn't
> take that setting out of the startup scripts. It doesn't break
> anything, since nothing in the code is looking for this file. I'll
> put a note about this fact in each of the existing scripts.

Or remove it until you start to use log4j...
though IIRC it has been superceded as a logger?

>
> The bash script that I got from d2rq sets $DTDANALYZER_HOME based on
> the directory in which the script resides. The only thing I'm not
> crazy about is that it doesn't follow symlinks. So, if I set up a
> symlink to point to the script from somewhere else, say:
>
> cd /usr/bin
> ln -s /home/maloneyc/DtdAnalyzer/dtdanalyzer
>
> And then try to run /usr/bin/dtdanalyzer, it won't work, because
> DTDANALYZER_HOME, inside the script, will be "/usr/bin".

I'm not happy about that. To me a more more robust
choice would be to document that an environment variable
should be set (and used by the script) or ask the user to
set the value in the script? Seems more logical since you can't
assume where the package is installed?

>
> I found a convoluted way of resolving that, here:
> http://www.daniweb.com/software-development/shell-scripting/threads/342521/getting-pwd-of-the-script.
> But I think it is too complicated, and probably brittle, and not
> worth it.

+1

>
> This is really getting into the area of making a distribution package,
> I think, so that people could get it with apt-get or rpm -- which is
> beyond what I know how to do.

Agreed, suggest keep it simple is a better approach.

>
> Let me know if you have any feedback on the existing bash script.

<grin/> I didn't use it! Will do (tomorrow now)

regards