The thing is that on non-english versions of XP code pages for console and gui apps differ, for example if I on my Polish version write in console:
echo zażółć gęślą jaźń > somefile.txt
The content of that file is:
zaľ˘† g©lĄ ja«ä
This isn't happening if I put that into cmd file. That is this text with polish letters. But if I create a file or directory that is named using non English only chars, then no matter if it's run from cmd or from finger the effect is always gibberish.
So my question is how to get this second code page that rest of windows is running with. In my case this CP is 1250 - but how to get this number from c++ ?
GetConsoleCP() and GetConsoleOutputCP() both return 852 (which is correct) and GetThreadLocale() gives 1045.
If I try to chcp 1045 it gives "wrong code page".
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP - this registry key stores the ANSI code page number (it should be 1250 in your case) and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP stores OEM code page.
Oh, and there are GetACP and GetOEMCP functions.
Related
I'm trying to print some tables in Windows console using C++.
My codes under default console settings:
cout << "╭─┬╮\n"
"├─┼┤\n"
"╰─┴╯\n";//Code I hope to work
cout << "╭ ─ ┬ ╮\n"
"├ ─ ┼ ┤\n"
"╰ ─ ┴ ╯\n";//Have an extra whitespace behind every character
gave me
The characters only take one space instead of two. They are squeezed together.
I have tried but didn't work:
Change code page to 65001(UTF-8)
Turn on and off every option except legacy mode in cmd settings hoping it would work.
Change font
I then used legacy console mode and this time it work, but for some reason I need it to work in newer mode. Can you tell me how to configure it right or is it just a bug?
OS: Windows 10 1909
Environment: CLion 2021.2.4 + MSVC v142, C++11
Having this line of code:
print "S\x00A\x00V\x00A"
produces different output. On Windows:
S A V A
and on Linux:
SAVA
What is the difference between the the 2 platform and what can I do to remove the whitespaces from the Windows case?
The difference is at the terminal level.
Windows cmd prints the zero-char as empty whereas your Linux terminal doesn't print it.
Note that in PyScripter console or PyCrust console (wx-based) you only get S (probably because the zero is seen as a line-termination char). So it's definitely not portable :)
To get rid of it just perform a replace:
print("S\x00A\x00V\x00A".replace("\x00",""))
I have a file,namedtest.txt
182.7 100.0
182.6 100.0
182.8 100.0
I want to sure weather the line ends with the digits 100.0:
So I use the following code:
for line in open('test.txt','rt'):
print repr(line),line.endswith('100.0\n')
print
But the Output in Ubuntu is:
'182.7 100.0\r\n' False
'182.6 100.0\r\n' False
'182.8 100.0' False
But the Output in windows server 2008 is:
'182.7 100.0\n' True
'182.6 100.0\n' True
'182.8 100.0' False
I already using rt in open function,so why there is difference between different systems yet?
The function strip() can take care of the ending new line character, and it is independent of the operating system used, the code can be
print "{line} {expr}".format(line=repr(line), expr=line.rstrip().endswith('100.0'))
Thanks! Is the answer obvious now? The file was created on Windows, where lines end with "\r\n", not with "\n". So long as you read the file on Windows in text mode, Python can hide that from you. But you read the file on Linux, where the distinction between "text" and "binary" modes doesn't exist, and you get exactly whatever bytes are in the file.
My advice is to force line ends to the native convention on whatever platform you move files to. Short of that, in Python 2 you can open files in "universal newline mode" instead, as briefly explained here.
I am writing a program for Windows that eventually has to launch a different pre-existing .exe that sits on the same computer. It passes multiple parameters to this .exe file. I am reading the actual command and parameters and constructing the command but I also tried hard coding it with the same results. Here's the hard coded version (I picked this out of an older C program that uses the same.exe):
system("c://IQapture//dmon2_6_IHD -p2 c://IQapture//mon_table_101_Tx8.txt 11 0 0");
So in the original program inside int _cdecl main(int argc, char**argv) this use of system works. In my C++ program inside a C++ class method when I issue the command the correct program launches but it immediately puts up an error dialog stating that an error has occurred. I echo'd the system string used to launch the exe out to the console. Right after it fails, I copy and paste the same line that was echo'd and this time the exe runs without error. This is repeatable. In case it was timing related I tried adding a 10 second delay before issuing the system command but it didn't matter. Plus the original older program doesn't require a delay. This implies to me that the string is correct and the target program works. Somehow the system() invocation is different from a direct command line invocation. The program compiles and builds fine. I'm using Visual Studio 2010.
Does anyone have ideas on how to make the system() invocation work like the command line invocation?
That really doesn't look like the kind of thing that Windows would be happy with... Try it with backslashes instead:
system("c:\\IQapture\\dmon2_6_IHD -p2 c:\\IQapture\\mon_table_101_Tx8.txt 11 0 0");
If that still doesn't work, you quite likely have one of the following issues:
Your current working directory is wrong;
An environment variable is missing;
Your program is running with the wrong user permissions;
Your program is tying up a resource that the spawned process requires (eg you have not closed a file that it requires as input).
There are a lot of things to consider - the environment, the user running the program, the parent process and what's inherited... Take a look at the parameters to the CreateProcess function. Chances are your system call's invocation isn't matching the command line's (though that may not be the issue, simpler things are more likely.)
I'd advise working backwards from the error to rule out simple causes such as the environment, current directory, etc. before delving into such things as creation flags and security attributes.
You have your slashes backwards. Try:
system("c:/IQapture/dmon2_6_IHD -p2 c:/IQapture/mon_table_101_Tx8.txt 11 0 0");
You can use the backslash \ but because that is an escape sequence starter in a string (for C/C++) that is why you use two in a row. As the compiler will convert \\ into a single slahs in the string:
Thus:
system("c:\\IQapture\\dmon2_6_IHD -p2 c:\\IQapture\\mon_table_101_Tx8.txt 11 0 0");
// Is equivelent to the command line string:
> c:\IQapture\dmon2_6_IHD -p2 c:\IQapture\mon_table_101_Tx8.txt 11 0 0
But Windows has supported both types of slashes for longer than I can remember. So the following command line is equivalent.
> c:/IQapture/dmon2_6_IHD -p2 c:/IQapture/mon_table_101_Tx8.txt 11 0 0
Using '/' in a string (in C/C++) does not require escaping. So you just need to use it as is:
system("c:/IQapture/dmon2_6_IHD -p2 c:/IQapture/mon_table_101_Tx8.txt 11 0 0");
I am trying to execute a dos command from within my C++ program, however soon as I add quotes to the output filepath (of a redirection) the command no longer gets executed and returns instantly. I've shown an example below of a path without spaces, but since paths may have spaces and thus be quoted for the shell to understand it properly I need to solve this dilemma - and I'm trying to get the simplest case working first.
i.e.
The following WORKS:
sprintf(exec_cmd,"\"C:/MySQL Server 5.5/bin/mysqldump.exe\" -u%s -p%s %s > C:/backup.bak",user,password,db_name);
system(exec_cmd);
The following does NOT work (notice the quotes around the output):
sprintf(exec_cmd,"\"C:/MySQL Server 5.5/bin/mysqldump.exe\" -u%s -p%s %s > \"C:/backup.bak\"",user,password,db_name);
system(exec_cmd);
I'm guessing it is choking somewhere. I've tried the same "exec_cmd" in popen to no avail.
Any help/advice is greatly appreciated.
I don't think your shell (cmd.exe) allows redirection to a file name with spaces. I couldn't make my command.com from DOS 6.22 accept it (I don't have a cmd.exe nearby to test).
Anyway, you can use the --result-file option to pass the redirection to the command itself.
mysqldump ... --result-file="file name" ...