I made the mistake of putting an ampersand (&) in a directory name. I renamed the directory, but now every time I change directory it prints an error message:
complete: Completion '[A list of directories' path]' contained a syntax error. Expected an argument, but found a '&'
I don't know where those path completions are stored. I looked into the folders listed in the $fish_complete_path list without luck...
This problem should be easy to fix, only I don't know where to look...
The behavior you're seeing is because there is an eval somewhere that is evaluating a string that wasn't properly escaped. In this case it would be the __fish_complete_cd function. Which, in fish 2.2.0, did in fact use eval in an unsafe fashion. As of fish 2.3.0 it no longer does so which means you can safely use an ampersand in a directory name.
Normally I would recommend opening a bug report at https://github.com/fish-shell/fish-shell/issues with as much detail as possible including the version of fish you're running (echo $FISH_VERSION) and steps to reproduce the issue. However, in this case we've already fixed the bug so all you need to do is upgrade your fish installation. Until you can do so you should be able to "fix" the immediate problem by simply starting a new shell: exec fish.
I also had fisherman installed. I uninstalled OMF, deleted fisherman files and plugins(I had z and get installed). Now it works. Not sure exactly which of those was the culprit.
I have installed scala, sbt on Mac. When I try to run sbt it gives an error Unrecognized VM option 'CMSClassUnloadingEnabledn-J-Xmx2Gn'. I think there is an issue with JVM but could not find any help for this error.
More error info:
Did you mean '(+/-)CMSClassUnloadingEnabled'?
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I faced the same issue after I ran the command I ran this command: echo '-J-XX:+CMSClassUnloadingEnabled\n-J-Xmx2G\n' >> /usr/local/etc/sbtopts.
It seems the file /usr/local/etc/sbtopts contained both options in same line, separated by \n, i.e. the actual contents of the file were -J-XX:+CMSClassUnloadingEnabled\n-J-Xmx2G\n
The solution was to remove \n by editing this file, and pressing enter key instead, so that the contents of file /usr/local/etc/sbtopts look the way David mentioned in his response.
My guess is that the sbt configuration is confused with regards to line breaks and
mangles something like
-J-XX:+CMSClassUnloadingEnabled
-J-Xmx2G
into one line
On Windows machines, check next settings :
System properties / Advanced / Environment Variables
System variables
2.1. e.g. Maven settings for Java 8 may have this setting which does not work on Java 17, as "CMSClassUnloadingEnabled" is disabled :
I have been struggling with a very weird issue that has suddenly popped up on the latest version of Eclipse Classic (4.2.2).
Everytime I try creating or refactoring a class or subclass in any of my projects (all Java) in my Eclipse workspace I get an error at the very top of my class that says
A class file was not written. The project may be inconsistent, if so try refreshing this project and building it
Again, this happens when I create new classes. And even when I rename current classes, then undo the renaming, its totally fine, but changing a single character in the name causes this error to happen for that specific class.
I have Auto Build on, and I tried multiple times to clean and refresh every project as well as restart Eclipse entirely.
I have literally no idea how to even start figuring out how to fix this. The solutions i've found through search didn't help, so i'm hoping I might find any clues here.
I had the same problem and here's how I solved it in the end:
It turned out that the disc space on the drive where workspace resides was full.
Silly mistake but worth checking.
In my case, this was caused by the fact that the build output directories were owned by a different user, and Eclipse could not write into them.
I had the same issues, the following worked for me:
Right click eclipse then running "as an Administrator"
Click Project > Clean.
Clean your workspace by starting eclipse from the command line with the -clean argument :
eclipse -clean
See also How to run eclipse in clean mode? and what happens if we do so?
I solved this problem by running Eclipse as root.
I had the same issue on Mac OS X. I had a maven project.
Try running the following command on Terminal. This looks like an access issue.
sudo mvn clean
Provide password for admin user.
Then open Eclipse and refresh your project.
We are using Eclipse here too and have to handle a workspace with more than 200 plug-ins. Every now and then people have similar problems with their workspace and inconsistencies reported in a weird way by Eclipse.
What people here usually do is (next step only in case previous step didn't help):
- trying to ContextMenu->Team->Clean/Refresh the whole workspace
- creating a new workspace and check out all necessary files from the repository
- reinstalling Eclipse to a new directory
From my experience after using the Eclipse IDE on a daily basis for many years, it doesn't make very much sense to waste too much time with these issues, unless they aren't solved by one of the steps above. It takes too much time to struggle with these things, while starting from scratch is done in an hour or less (and usually fixes the issue).
If your Eclipse still behaves strangely it might make sense to go through your installed plug-ins. Not all external plug-ins follow the Eclipse guidelines and can seriously harm the performance and operational consistency of your Eclipse installation (E.g. Sonar Plug-in, Toad Plug-in, ...)
In my case this kind of error caused due to disk space got full and it got resolved by just freeing disk space where eclipse have been installed.
That is c/d/e drivers.
I come up with the same error, and in my case, this is because the permission of the project/bin directory is not recursively 775
I fixed it by:
Remove the project/bin directory: sudo rm -rf project/bin
Switch to Eclipse, rebuild the project: Project->Clean...
Then no errors.
Try to launch Eclipse as Administrator.
In my case such error was caused by a question mark in a quoted method name (I use geb+spock combination for automated testing).
So this method name will throw an error "Do you want something?"()
And this will not "Do you want something"()
It may not be the best response but to fix it, I've just delete the error marker.
Had the same issue. but cleaning the project and restart eclipse didn't help and disk space was not the issue. Solved the issue by copy the code to notepad(just to not lose it) and then delete the class, recreate it and paste the code back in again.
I solved it changed the owner of the project files. I changed from root(old owner) to user my current(user that i use with eclipse).
Just changed and saved java file to recompile the class. Then error disappeared.
I was try run
Project->Clean...
And Rebuild. My problem was resolved
For linux (Debia) and working on Spring boot project (maven):
$ sudo mvn clean
Then open Eclipse and File -> Refresh.
I had same issue, it is something similar but this post didn't help in my case. I have many inner classes which is causing the compiler to create class names with all inner class names together that is creating class name more than 255 character file limit on NTFS! read it in some other blog. I thought it will be helpful to post here.
Ex : classA$InnerClassB$......InncerClassZ.class in target folder it won't generate the class if it exceeds this limit. Try renaming your inner class name shortened. In my case i have to add InnerclassZ as its exceeding its not generating class and Eclipse complaining.
A class file was not written. The project may be inconsistent, if so try refreshing....
I shortened InnerClassZ to IClassZ fixed the issue.
I had the same issue and it got fixed by running eclipse in administrator mode
Eclipse Shortcut-->Right click-->More-->Run as Administrator
I've been throught that error once when I used wsdl2java to extract java classes from a wsdl, it turns out that all classes were created in the same "class", causing end classes with long names (error - File name too long). When I organized and rename some classes the error disappeared.
I had this issue. I did the following, it resolved.
Open Eclipse in Administrator mode; Right click on eclipse.exe "Run as administrator"
Clean all projects.
#Denny's answer put me on the right track, though in my case it was the target directory. I deleted it for some reason and something automatically recreated with owner root. Changing the directory owner was not enough as it contained files that were also owned by root. So make sure to really remove the complete content of the directory and to change the owner.
In my case current user didn't have access to this project dir
Before giving a try to the above solutions. Just cleaned the project and it worked.
I installed DrRacket so I can learn programming concepts using SICP. But for the past week or so, every time I launch DrRacket the console windows comes up with the following message:
fl-:contract violation
expected: flonum?
given: 0
argument position: 2nd
other arguments...:
2.0
I am not sure how I got here. I tried uninstalling and re-installing as 32-bit and 64-bit, restarting my laptop, searched forums for a possible fix. No luck. Just want to get back to my normal window where I can type in code. Thanks.
hope u found the answer. For my case, I found out that from a file I had been working on, and my computer shut down unexpectedly, there were three files associated with the initial file name - upon resuming Windows. The file extensions were .rkt (original), .bak and .1. I renamed the '.1' file as a second copy of the original and the 'contract violation' problem ended. It appeared the '.1' file was due to the laptop shutdown and was the auto-retrieve file.
I've installed Aptana 1.5 today but after the install all my SVN projects give me an error like this when I try to commit, update, repair, etc:
Access is denied.
svn: Error resolving case of 'C:\Users\Brayn\My Documents\Aptana Studio Workspace\PentruConstrucii'
I've uninstalled my previous version of aptana, reinstalled aptana 1.5, changed my workspace and it still gives me this error.
Do you know what could it be ?
I've had this exact same error display if I end a directory name with a \ from a cmd.exe shell:
C:\> svn co http://my/repo/ "C:\Work\My Repo\"
svn: Error resolving case of 'C:\Work\My Repo"'
C:\> svn co http://my/repo/ "C:\Work\My Repo"
U C:\Work\My Repo
Checked out revision 13768.
I think it ends up interpreting the final \" as an escaped double-quote instead of a backslash and the end of the string.
"C:\Users" means Windows Vista or 7...
It may be related the way SVN handle Windows Vista symbolic link ("junction"): poorly, according to this ticket (also described in bug 3208):
This bug is reproducible 100% of the time.
1) If you invoke "svn delete" against a Windows Vista symbolic-link, such as
"c:\documents and settings\<username>\my documents\<some path>" then Subversion
will fail with "svn: Error resolving case of 'C:\Documents and
Settings\<username>\my documents\<some path>"'"
2) If you set the current working directory to "c:\documents and
settings\<username>\my documents\<some path>" and invoke "svn delete" against
the local filename the operation succeeds flawlessly.
It may be related to some ACL rights preventing the SVN to access the data:
Subversion tries (via APR) to resolve the exact case of all paths passed to it. This fails because this specific example has a path that is unreadable in its path.
You can see this via:
C:\>cacls "c:\Documents and Settings"
C:\Documents and Settings
Everyone:(DENY)(special access:) FILE_READ_DATA
I know you are referencing C:\Users here, but may be SVN try internally the old path.
Old question, but I had a related and similar problem with a solution that appears relevant to this:
My (unrelated electronic design automation) program was throwing svn: Error resolving case of "<blah blah> errors followed by what looked like my commit log message. I eventually figured out that some double quotes (") I was using for the log message was being interpreted as terminating the message, then the rest of my babbling was taken as input to svn. My solution was to just use single quotes instead.
For your case, it sounds like it could be your program (Aptana) could be screwing up because when it sees spaces in the path name, it encloses the path in quotes, possibly breaking something (redundant quotes?). It would be resolved when you just work in the root C:\ because there are no spaces in the WC root path ...\My Documents\....
I had similar issue today. But in my case, I was using backward slash in path instead of forward slash. I got it working After correcting that.
Its also recommended that path to be given inside double quotes.