Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
This item is to track the vstar.bat (MSDOS batch script) and vstar.sh (*nix batch script) to start VStar.
The /bin/sh startup script should probably be renamed from "vstar" to "vstar.sh"
On linux if my current working directory is $HOME and I have a directory $HOME/vstar containing the files from trunk, running ./vstar/vstar causes the error "Unable to access jarfile ./dist/vstar.jar" The script is using my current directory and not the dir that the shell script lives in. So it only works if you are in the directory with the script.
Opps, ignore that last comment about the current working directory. I hadn't set the environment variable properly.
It should be possible to have the script figure out where it is running out of and set this automatically.
Thanks for looking at these Mike. If you have a Windows machine handy, feel free to test vstar.bat. I added these scripts recently with minimal testing. I've been using the sh script though.
Point taken re: vstar.sh. I guess we ought to have vstar.csh also. What I liked about 'vstar' vs 'vstar.sh' is that the user can just type 'vstar', as a DOS user could with the batch script. I don't feel that strongly about it though.
Creating an installer per platform might make it possible to hide such differences in invocation, but I wouldn't say it's a high priority.
For the DOS vstar.bat script, it should be changed to:
if not "%VSTAR_HOME%" == "" GOTO RUN
On the side topic of starting VStar, is it possible to start vstar from the command line with plugins disabled? I really like the plugins and have only just started to try them out. From a testing/debug perspective it would be nice to have a -noplugins switch on the command line to temporarily disable the plugins to track down the source of an error.
One possibility for vstar.bat is to use:
which returns the directory that the script lives in (regardless of current working directory) per:
Tested only on XP, this allows clicking the script icon in a folder or running from the command line from any directory and the script will use the path relative to what directory it is in..
I'm not sure we need versions of the script for csh (or ksh, etc) Most people write scripts in sh when they want portability and most (all of the ones that I am aware of) *nix like systems will handle sh scripts just fine regardless of which shell the person is using. Works fine on Solaris, Ubunto, CentOS depite my choice of login shell. Trying to keep track of multiple startup scripts could get messy.
Nice. Yes, this is the kind of thing I've seen before for DOS. Feel free to commit your changes to the batch file.
I think there's similar approaches for Bourne shell re: CWD/PWD.
I agree re: csh vs sh vs ksh vs zsh. :)
Re: plugin disabling: good idea. I can do that.
I made the changes described below to the vstar.bat DOS startup script in svn 799. This has only been tested on Windows XP, so further testing is needed. (ie. Vista etc.)
It looks like there are two DOS dos batch scripts: 1) trunk/vstar.bat and 2) trunk/script/run_vstar.bat
I updated vstar.bat in svn 799 and updated run_vstar.bat in svn 801/802 The later was done due to the zip option in the build script which causes run_vstar.bat to get included in the zipfile. Due to the fact that the second script is in a subdirectory I needed to specify the path slightly differently. The two scripts work the same, but are not identical.
We should back up a step and rethink what the purpose of these scripts is going to be. Are they intended as a replacement for jnlp or as an alternative for those who want to work with the lateste svn revision between major public releases or something else?
Thanks for all this Mike.
In http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=803 I:
1. Added --noplugins command-line switch to disable loading of plugins.
2. Added support to vstar.bat and vstar scripts for passing command-line parameters.
3. Changed vstar script along the lines of Mike's vstar.bat script changes to get the script's directory so it can be run from anywhere.
I think the run_* scripts under script dir should be removed. I wanted to expose vstar and vstar.bat at the top-level to make them "first class" like vstar.jnlp. I don't want them to replace the JNLP, just to make standalone running of VStar equivalent to JNLP with respect to VM params. Does that make sense?
I agree with placing the scripts in the top level directory and removing them from the scripts subdir. This will also make the path cleaner within the script and it is the most logical place for them to be.
Removed run_vstar scripts; the vstar scripts at the top-level are the key ones now.
I've added the "vstar.bat" DOS and "vstar" unix scripts to the zip section of build.xml in svn 805
A couple of loose ends that I noticed:
* there is now an extraneous reference to: includes="run_vstar.*"
* the doc directory contains both a vstar_docs subdir and a redundant vstar_docs.zip file
* the source for plugins is included in the zipfile, but they are not in a form that is ready to use
Perhaps these items should be in a new tracker, but they are somewhat related to this one.
Removed run_vstar.* zipfileset entry and added filemode=755 attribute for vstar shell script; updated ReadMe.txt re: the new official run scripts.
So, that last commit leaves your last two bullets:
* the doc directory contains both a vstar_docs subdir and a redundant
* the source for plugins is included in the zipfile, but they are not in a
form that is ready to use
Re: the docs, I think you're right. We should include one or the other. The zip?
Re: plugins, given that I have been releasing a zip file containing jar files (which also contain plugin source) for the latest vstar release, perhaps the plugins dir tree should be omitted also?
I'm thinking of opening a new tracker on the broader topic of packaging to cover discussions of what the goals of each method (jnlp, zipfile, maybe others) are and what should be included in each distro. From a quick glance it looks like the javadocs are really only of interest to someone that wants to get the details of what is happening under the hood. So a zip within the zipfile is fine. Though I wonder what the point is in including the javadoc at all without also the source code in the zipfile. I would almost rather see ready to use plugins included in the zipfile.
Please do Mike. That's a fair comment about the javadocs. I suspect that the plugin developer will be more interested in them than anyone (apart from a VStar developer or other interested party).
Your comment about ready-made plugins is an interesting one also. Perhaps you're right. Let's talk.
My son tested that the batch script works on Windows 7.
I'm not sure whether creating a shortcut to the batch script works. I think he tried to drag it onto the task bar and it didn't work. Have to look at this again.
For Windows XP: creating a shortcut and then dragging it to the desktop of the Start bar works fine.
My son did this for Windows 7 just now also. Last time he dragged the file rather than creating a shortcut. Something worth adding to the doco I guess.
Tested DOS script on Vista. Works fine from the unzipped folder, or after doing a right click with "Send To -> Desktop (create shortcut)"