I get the following error when running the configuration xml file from command line as stated on mybatis site. I run “java –jar mybatis-generator-core-1.3.2.jar –configfile mbg.xml –overwrite –verbose”
error:
Any help would be appreciated.
Most likely you have copy-pasted the command from their website. The problem is they used a strange character for "-".
As a proof, go to this website and insert the "-" (dash) character from their website command and click on "Show ASCII Key Code". It will show an window where the decimal key for that character is 8211. If you insert from your keyboard the "-" character, the decimal key displayed is 45, which is the correct character.
So, you need to type the command by hand or you can copy-paste the command below:
java -jar mybatis-generator-core-1.3.2.jar -configfile mbg.xml -overwrite -verbose
Related
I have a postgresql .sql dump file created by pg_dump on another windows 10 box. I am trying to restore it on my windows 10 laptop with
"psql -U user -d database -1 -f filename.sql". I created the database, but when I run the command to do the restore I get an error from psql after I give it my password:
psql:filename.sql:1:1: ERROR: syntax error at or near "ÿ_"
LINE 1: ÿ_;
The file looks like straight ascii (I only see two dashes on line one. I don't see a 'y' with an umlaut anywhere). I did a file on the .sql file with cygwin bash, and it says:
Little-endian UTF-16 Unicode text, with very long lines, with CRLF, CR line >terminators
I really don't want to recreate the database by hand. I am looking for any suggestions.
I tried psql with and without the '-1' option; no luck. I tried putting a ';' at the top of the sql file, which I found suggested somewhere; again no luck.
I did a psql -l on my postgresql installation and the encoding on all my databases (including the one to which I am trying to do the restore) shows UTF8.
There really is no code. It is just that I can't seem to restore this dump file because it errors out.
I think that captures my problem. The windows box that I got the dump from is not available to me now; so I'm just hoping there is a way to get around this problem. Recreating the database by hand table by table is something I would prefer to avoid.
Thanks--
Al
In my case , this exact thing happened because I was taking the dump using windows Powershell , due to which other characters got included in the dump file.
Simply using command prompt to take the solved my problem.
I can only give you leads how to debug the problem, because the cause is not immediately obvious.
First, there should be a line close to the beginning of the dump file that sets client_encoding. The dump file should be in that encoding.
I can see two possibilities:
The file got mangled during transfer. To test for that, calculate a checksum for both files and compare.
Always use binary mode to transfer PostgreSQL dumps.
some editor or something else sneaked a BOM (byte order mark) into the file at the very beginning.
That's my prime suspect, since the problem is at line 1.
Use a hex editor or od (in Cygwin) to verify that. If this is the problem, simply replace the BOM with spaces.
I'm adding the following line -classpath/p ${installer:sys.userHome}/.comput/updates/latest.jar to the vmoption file. (Tried both options: via installer 'Add VM option' action and via launcher config).
Works pretty fine with ASCII user name (with spaces as well), but fails with non-ascii user names (I'm testing with Russian). The vmoption file looks fine to me: the path is correct and has the right encoding: CP 1251 for my case:
However the path passed to JVM seems to have incorrectly decoded characters: On the attached screen you may see the actual path passed to JVM (checked via YourKit) from Install4J launcher:
and you may also compare it with the screen when the non-ascii path is passed via command prompt:
The only workaround I have found is to substitute the path with 8.3 Windows path, but converting to it on pure Java seems very error prone to me.
Appeciate your help very much!
gpg --output C:\ecshome\mboxes\store\20150410_030846_1_0001_6pik.msg.
asc --passphrase abcd. --no-default-keyring --decrypt C:\ecshome\mboxes\store\20150410_030846_1_0001_6pik.msg
When I try to decrypt an email message by using gpg from the command prompt, it works. But when I try to decrypt the same with a Perl script by using external command, it shows the "Secret key not available" error (On Windows).
You haven't shown us the way you quote that command in perl, but allow me guess that you haven't taken into account the fact that the backslash is both the Windows directory seperator and the Perl string escape. You should be aware that "\e", the 3rd character in your --output & --decrypt paths, is the character (ESC). The sequences "\m" and "\s" interpolate to 'm' and 's' respectively.
Possible solutions include either delimiting the string with q()/single quotes or doubling up the backslashes in qq()/qx()/double quotes/back quotes.
The problem was with pubkey ring. Apparently its stored for each user under their application data directory if you don't mention any home directory specifically at time of installation. If you execute from Command prompt it will directly take from the present user's applicatin data but from perl it wont check there.U have to specifically Configure GNUPGHOME to that folder (application data) then run the perl script.
From inside a .bat file, I m issuing this command
xcopy\s Folder1\folder2\folder3\blah-blah Folder1\temp\folder2\folder3
But I get the error:
The system cannot find the path specified.
I tried copying the same line to command line and tried it:
Then, I get the error, xcopys command not found.
If I try to use xcopy instead of xcopy/s, I get error:
File not found - Folder1folder2folder3blah-blah
If I use xcopy command with backward slash on command line: Invalid number of parameters.
I tried enclosing paths in quotes, but it does not help.
My file names don't have spaces in them but they do have -
I have checked the path of source and destination and they exist
Any help will be appreciated.
Thanks
I guess you're running under windows, so you have to use forward slashes for arguments.
xcopy/s is something very different from xcopy\s. The later searches for an application called s in a subfolder called xcopy. To further avoid confusion, separate the program from its argument(s) with spaces.
Hallo everyone once again,
I did various searches but couldn't gind a suitable/applicable answer to the simple problem below:
On pgAdminIII (Windows 7 64-bit) I am running the following command using SQL editor:
COPY public.Raw20120113 FROM 'D:\my\path\to\Raw CSV Data\13_01_2012.csv';
I tried many different variations for the path name and verified the path, but I keep getting:
ERROR: could not open file "D:\my\path\to\Raw CSV Data\13_01_2012.csv" for reading: No such file or directory
Any suggestions why this happens?
Thank you all in advance
Petros
UPDATE!!
After some tests I came to the following conclusion: The reason I am getting this error is that the path includes some Greek characters. So, while Windows uses codepage 1253, the console is using 727 and this whole thing is causing the confusion. So, some questions arise, you may answer them if you like or prompt me to other questions?
1) How can I permanently change the codepageof the console?
2) How can I define the codepage is SQL editor?
Thank you again, and sorry if the place to post the question was inappropriate!
Try DIR "D:\my\path\to\Raw CSV Data\13_01_2012.csv" from command line and see if it works - just to ensure that you got the directory, file name, extension etc correct.
The problem is that COPY command runs on server so it takes the path to the file from the server's scope.
To use local file to import you need to use \COPY command. This takes local path to the file into account and loads it correctly.