The input line is too long and The syntax of the command is incorrect

1,988 views
Skip to first unread message

euler

unread,
Sep 19, 2018, 6:57:53 AM9/19/18
to DSpace Technical Support
Dear All,

I really need your help on how to resolve this error when issuing dspace commands from the command line. I have 2 dspace instances in the server and both have almost identical settings and configurations. They also have the same DSpace base version which is 6.3. I am on Windows Server 2012. The first instance works perfectly when I run commands in the command line but the 2nd instance always gave me the "The input line is too long." and "The syntax of the command is incorrect" message. As a result, my scheduled tasks that relied on these commands stopped working. After searching in the web for that same message, I found out that when I issued dspace -h command for example, it is adding the DSPACE_CLASSPATH in the input hence the message "The input line is too long". This made me wonder because I did not encounter this message in the first instance of DSpace in the same server. I did an mvn -U clean package hoping that it will solve my problem but it is still giving me this error or message. I also searched here in DSpace-Tech mailing list for posts that have the same problem but unfortunately, those posts have no responses.

Please help me on how to resolve this error. I only started having this problem after I merged my local branch to a remote branch that I pushed but it made me wonder because I did the same thing for the first instance and I did not have that error. I would be really grateful if someone could guide me on how to fix this. This is bugging me for days now because this is a production server.

Thanks in advance!
euler

Mark H. Wood

unread,
Sep 19, 2018, 8:45:25 AM9/19/18
to DSpace Technical Support
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.

euler

unread,
Sep 20, 2018, 2:06:02 AM9/20/18
to DSpace Technical Support
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.

Tim Donohue

unread,
Sep 20, 2018, 11:54:47 AM9/20/18
to euler, DSpace Technical Support
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


--
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

euler

unread,
Sep 20, 2018, 8:38:07 PM9/20/18
to DSpace Technical Support
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

Tim Donohue

unread,
Sep 21, 2018, 9:49:54 AM9/21/18
to euler, DSpace Technical Support
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
Reply all
Reply to author
Forward
0 new messages