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 <[email protected] <javascript:>> > 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
