I recently acquired a MacBook. I compiled Mercurial 1.6.3, and set it all with NetBeans.
The thing is, whenever I try to commit, and since I'm writing the revision message and my name with accented characters (in Spanish), I'm getting an error like:
transaction abort!
rollback completed
abort: decoding near 'Naim? Batuta ': 'utf8' codec can't decode byte 0x8e in position 4: unexpected code byte!
I used locale on the console, and I got this:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
I tried setting LC_CTYPE="C.UTF-8", and now LC_CTYPE became ="C" as well, yet Mercurial keeps showing me the same message.
At first I thought it was NetBeans switching character encodings, but then I tried a simple hg commit, and it returned the same error.
I've read everywhere, and while such articles mention character encodings of Mercurial, Mac OS X, and Python, some patches to fix it (a while ago, so they should be already in Mercurial), I haven't found a real solution.
Has it happened to you before? How did you solve it? Please, help me. It works just fine on my desktop (Windows) machine, but sometimes I need to make modifications while I'm away, and this is driving me crazy.
Thanks in advance!
When I issue the locale command on my mac osx, I get the following
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
For you it should be
LANG=es_ES.UTF-8
LC_ALL=es_ES.UTF-8
Are you exporting these? Because, your locale should have shown a different value after exporting.
export LC_ALL=es_ES.UTF-8
export LANG=es_ES.UTF-8
Your Spanish locale should be es_ES.UTF-8 (if your terminal does use UTF-8), or es_ES (which will use ISO-8859-1 encoding). "C" locale knows nothing about Spanish accentend characters.
Anyway, if properly setting locale in your terminal doesn't help, then you can try setting
[ui]
fallbackencoding=ISO-8859-1
in your .hgrc config file.
No idea what really happened. I deleted any file I had of Mercurial from my compilation, and just used the installation package.
Yes, it now works wonders. Thank you all!
Related
Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
Recently on a fresh Ubuntu installation, suddenly PHPStorm stopped allowing me to use words with portuguese accents.
For example:
Trying TILDE+A should result in: ã
Instead it results in: a
And this happens with other accents like:
Trying DIACRITICAL SIGN+E should result in: é
Instead it results in: e
Currently the laptop configuration is as follows:
OS: Ubuntu 15.04
Java: OpenJDK 8 (OpenJDK 7 did not worked also)
PHPStorm 8.0.3
Keyboard: Portuguese
Note 1: I think the problem may be related with key bindings once that the standalone key c-cedilla works just fine.
Note 2: My mother language isn't English so errors may occur, feel free to correct me. I appreciate it.
Any further help would be appreciated, thanks a lot!
Well, so after some days struggling against this problem I finally found out what I already expected since the beginning, this is a problem related to java itself.
In order for special characters to work we've to clean up the XMODIFIERS environment variable, like so:
# Command to change the environment variable XMODIFIERS
export XMODIFIERS=""
# PhpStorm run, for testing if it worked
pstorm
And for me it did work!
So, after testing I just added the export command to my ~/.bashrc file so this change takes effect every time and not only that one when we've changed it manually in a terminal window. In the end of your .bashrc file paste the following (same command as above):
export XMODIFIERS=""
I got the tip from here: https://askubuntu.com/a/581769/410364
For some reason, add the export XMODIFIERS="" on rc file didn't work (put it on .bashrc and in the .zshrc). Even put in .profile file doesn't work. So, I create a shell file with:
export XMODIFIERS=""
/opt/PhpStorm-191.6183.95/bin/phpstorm.sh
and put that shell file in the PHPStorm .desktop file as a program filepath. It's work to me :)
To me works with this:
export IBUS_ENABLE_SYNC_MODE=1
ibus-daemon -d -r
I keep getting an "Executable '['git']' was not found in PATH. Current PATH" error message when trying GIT STATUS in Sublime Text 3. I have the SublimeGit plugin installed.
I have the following in my Package Settings > Settings - User
"git_executables": {
"git": ["/usr/local/bin/git"],
"git_flow": ["/usr/local/bin/git", "flow"],
"legit": ["legit"]
}
I have read https://docs.sublimegit.net/quickstart.html, but it does not go through windows paths.
Any help would be appreciated.
That error message can happen because of operations on a missing or moved file:
See issue 212 (for ST2, but possibly relevant for ST3).
Ok, I think why this bug happened.
There was a file that was moved to another location form outside ST2, and Git plugin failed to do something to the file because it no longer existed, but that situation was interpreted as missing git command.
Another workaround mentions:
Installing python via homebrew and restarting ST2 fixed this problem for me:
brew install python
Also, by David Gee -- davidagee :
On OS X Mountain Lion, the only way I was able to fix this, after trying everything in this thread, and additional mucking around with path settings, was to open "/Users/[me]/Library/Application Support/Sublime Text 2/Packages/Git/Git.sublime-settings" and to change git_command to "/usr/local/git/bin/git".
Adding a git_command setting to user prefs doesn't work.
The plugin seems to ignore the value when set in Preferences.sublime-settings.
I have been using mercurial for a few months now and just the other day when I went to do an hg commit, my editor launched but with an empty file named something like "/tmp/hg-editor-I48e8Z.txt" and in my terminal it automatically returned an "abort: empty commit message" error.
It had been working fine and it still works fine for other users on the same machine. The only way I've been able to commit is to specify the commit message at the command line. I really don't like doing that because I like that I can double-check which files will be included in the changeset when the editor pops up.
Does anyone know what may have caused this/how to fix this?
This is on a Redhat Linux machine, Mercurial version 1.
I use gvim. With:
export EDITOR = gvim
I had the problem. Changing to:
export EDITOR = 'gvim -f'
fixed the problem.
And of course, I just found out what it was...
I was setting my EDITOR and VISUAL environment variables incorrectly.
I try to commit a folder hierarchy into out Mercurial repository, which contains files, whiches absolute path length exceeds 255 characters (Windows max. path length).
For these files I receive an error message saying
The system cannot find the path specified
We use TortoiseHG and an Eclipse plugin for Mercurial, both don't work.
Has anybody found a solution for this?
(I do not want to change the repository's location on my HD)
There exists an extension which is aimed at solving this exact problem. It is: https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension
It uses \\?\ style names to transparently handle long files.
I'm the author, let me know if it works for you.
I've just installed Aaron Cohen' extension, as he suggested.
And it perfectly works with my TortoiseHG 2.6.1 ! Thanks, Aaron!
Though, I'd like to add a detailed guide here, because I cannot find one...
(At least here's what I did on my Win7 x64 - I'm not sure this is the shortest way possible)
1. Download Mercurial-py
Note the Python version required
I've downloaded "Mercurial-2.4.2 (64-bit py2.7)"
2. Download Python
Make sure you're downloading compatible version.
I used "Windows X86-64 MSI Installer (2.7.3)" link
3. Install Python
I've installed it to "D:\Python27"
4. Download pywin32
It's required by the Win32LongFileNamesExtension.
Note the Python version number in pywin32's filename.
I used "pywin32-218.win32-py2.7.exe"
5. Install pywin32
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\pywin32_system32\"
6. Install Mercurial
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\mercurial\"
7. Set PYTHONPATH enviroment variable
setx PYTHONPATH d:\Python27\Lib\site-packages\win32lfn\src;d:\Python27\Lib\site-packages\mercurial\
Use this cli command, or do the same using some other method
Of course, you should adapt paths to your needs
Restart your cli after this, to make sure env. variable is now properly set
8. Download win32lfn
Check for availible downloads on the project's repository page
If there's still nothing, just clone a repository from https://bitbucket.org/remleduff/win32lfn to "d:\Python27\Lib\site-packages\win32lfn\"
Now "win32lfn.pyc" should be in "d:\Python27\Lib\site-packages\win32lfn\src\"
9. Do interanal win32lfn tests
cd /D D:\Python27
python d:\Python27\Lib\site-packages\win32lfn\tests\testwin32lfn.py
10. Create a backup of your repository.
For me, everything went just fune, but you never know....
11. Add win32lfn to hgrc
[extensions]
win32lfn = d:\Python27\Lib\site-packages\win32lfn\src\win32lfn.py
you can find "hgrc" in your ".hg" folder, inside your repository
12. Test it!
The quick and dirty solution is to map a network drive.
For the path c:\some long path\project folder
Map \\localhost\c$\some long path\ to drive Z:\
cd z:\project folder
hg push
We are using this successfully as an interim solution, before migrating to shorter paths.
The mercurial plugins above look good but unfortunately there are numerous non-mercurial bugs related to path greater than 255 characters. For example the VS2010 failure at exactly 259 characters is a real corker!
http://support.microsoft.com/kb/2516078
See https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension (Aaron pointed to it via the mercurial-devel mailing list).
Another workaround without changing the path to the repo could be to create a second path to it by means of directory junction points. It may work because the reparsing is done at a very low level by the file system driver (or rather some installed filter), so the full (Unicode) path is known by that time and the expansion to beyond 260 characters should work fine. Give it a try. You can use the tool mklink on Windows Vista or 7 and junction.exe from Sysinternals on Windows 2000 or later. For mklink make sure to create a junction point. I'm not sure the reparsing mechanism works the same for directory symlinks (although I faintly remember that it should).
If you don't have a Unicode version of the program available, the limit is 260 characters (including drive letter part). There is nothing to get around it.
However, all ANSI functions are implemented by means of their Unicode counterpart and therefore you may get lucky by providing the full path prepended with \\?\. This may work, but likely won't because the program itself didn't consider anything beyond MAX_PATH (= 260). Ask the author to compile a Unicode version and use the prefix I mentioned. This will fix the issue.
This is a limit of the Win32 subsystem. The absolute path length limit is approximately 32,767 characters. Approximately because the object manager of Windows may expand it (symlinks in the object namespace and the likes).
Windows 10 system running the mercurial 4.4.1 client
Aaron Cohen extension will work I did need make a small one small tweak
based on a comment from mhaecki on this thread: https://bitbucket.org/remleduff/win32lfn/issues/13/not-compatible-with-version-431
in the win32lfn.py file I changed:
from mercurial import util, osutil,cmdutil
from mercurial.i18n import _
to:
from mercurial import util, cmdutil
from mercurial.cext import osutil
from mercurial.i18n import _