Hi Euler, Thanks for providing us with some additional clues/hints here. Unfortunately, though, I'm not seeing the same behavior on my Windows 10 machine with Java 8 + DSpace 6.3. For me, the batch script (dspace.bat) works perfectly, and the DSPACE_CLASSPATH variable is unset properly. So, it almost seems like either there's a major difference between Windows 10 and Windows Server 2012, or maybe this is somehow caused by the fact that you have a second partition (as I only have a single partition on my Windows 10 machine)?
The only other idea that comes to mind is that you might have a very long CLASSPATH environment variable. If you look at the dspace.bat script, it initializes DSPACE_CLASSPATH to the value of CLASSPATH, and then appends on some DSpace specific paths. If your system's CLASSPATH environment variable is very long, it's possible that could also be triggering the "input line is too long" error mentioned at https://www.digizol.com/2006/12/input-line-is-too-long-windows-command.html Beyond that, I'm not sure what to suggest. If you are able to narrow down the issue on your end, we'd welcome bug fixes or patches (in the form of a pull request) to the default "dspace.bat" script. We've had this same "dspace.bat" script for a long time, but occasionally we discover minor bugs that require fixing. That said, I don't believe there were changes to this script between DSpace 5.x and 6.x. Good luck, Tim On Thu, Sep 20, 2018 at 7:38 PM euler <esne...@seafdec.org.ph> wrote: > Hi Tim, > > Thank you so much for your response. > >> This notes that Windows has limits to the number of characters that are >> allowed in a single command. It notes that sometimes you can get around >> these errors by making your paths shorter (e.g. instead of installing >> DSpace under C:/some/long/path/to/dspace/ , you could install under >> C:/dspace/). That also may be the issue you are seeing. > > This could not be the reason because the path where I installed dspace is > much shorter (E:\STIR). What I've found out when I'm also looking for > this type of message is that (sorry, couldn't find the page where I've seen > them) the batch file is appending the environment variable (in my case > DSPACE_CLASSPATH) in the input but it is not cleaning up the variable > after executing java: > > REM Execute Java > java %JAVA_OPTS% -classpath "%DSPACE_CLASSPATH%" > org.dspace.app.launcher.ScriptLauncher %* > > REM Clean up DSPACE_CLASSPATH variable > set DSPACE_CLASSPATH= > > I believe this could be the reason for the message because when I execute > the command "set", the DSPACE_CLASSPATH variable is still there. As I've > mentioned in my previous post, I tried to checkout a new 6.3 branch in a > different directory and set the install location also in a new directory > but still I received the same error message when executing the dspace batch > file. Copying the batch files from the first instance of dspace that is > working gave me "The input line is too long" message also. > > I've also mentioned in my previous post that I have two DSpace instance in > this server and that the first instance worked ok. I forgot to mention that > the first instance is located in a different partition. The solution I > found (well, not really a solution but a workaround) is to checkout a new > branch in a different partition (where the first DSpace instance also > resides) and build from there. Even though I still set its install > directory in its original location, executing the dspace command is now > working perfectly. I am still wondering what could be the cause of that > message and I can't remember anything that I did to trigger that since it > is working perfectly for months. > > Thanks again and I apologize for those who may have the same error but > have only one partition in their server because my workaround will not be > applicable for your case. > > Sincerely, > euler > > On Thursday, September 20, 2018 at 11:54:47 PM UTC+8, Tim Donohue wrote: > >> Hi euler, >> >> I've done some tests on my end with running DSpace 6.3 on Windows 10 >> (with Java 8), and I'm not able to reproduce these errors. That implies to >> me that either there's something different in your installation environment >> *or* somehow the [dspace]/bin/dspace.bat script (which is the Windows >> 'dspace' script) is becoming corrupted or changed during installation. My >> suspicion is that it's your environment -- this doesn't sound like a bug in >> the script itself, since it works fine on other Windows machines. >> >> Are you able to run *any* Windows batch (*.bat) scripts on this machine? >> >> Does the error itself not any specific line number in the "dspace.bat" >> script that is a problem? >> >> Searching around on Google for these errors, I also came across this: >> >> https://www.digizol.com/2006/12/input-line-is-too-long-windows-command.html >> >> This notes that Windows has limits to the number of characters that are >> allowed in a single command. It notes that sometimes you can get around >> these errors by making your paths shorter (e.g. instead of installing >> DSpace under C:/some/long/path/to/dspace/ , you could install under >> C:/dspace/). That also may be the issue you are seeing. >> >> Good luck, let us know what you find. >> >> Tim >> >> >> On Thu, Sep 20, 2018 at 1:06 AM euler <esn...@seafdec.org.ph> wrote: >> > Hi Mark, >>> >>> I did that and it is still the same message. Out of desperation, I clone >>> a new repository in a different directory. After mvn package and ant >>> update, I tried to run dspace -h from the [dspace-install]/bin directory. >>> I'm really frustrated now because I'm having the same error message despite >>> the fact that this is a new and totally different install. >>> >>> >>> On Wednesday, September 19, 2018 at 8:45:25 PM UTC+8, Mark H. Wood wrote: >>>> >>>> The first thing I would do is mechanically compare the two copies of >>>> bin\dspace.bat to see if the failing one is damaged in some way. >>>> >>> -- >>> All messages to this mailing list should adhere to the DuraSpace Code of >>> Conduct: https://duraspace.org/about/policies/code-of-conduct/ >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "DSpace Technical Support" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send an >>> email to dspace-tech...@googlegroups.com. >>> To post to this group, send email to dspac...@googlegroups.com. >> >> >>> Visit this group at https://groups.google.com/group/dspace-tech. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Tim Donohue >> Technical Lead for DSpace & DSpaceDirect >> DuraSpace.org | DSpace.org | DSpaceDirect.org >> > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
