I am trying to inject key combinations (like ALT+.) into a tty using the TIOCSTI in Python.
For some key combinations I have found the corresponding hex code for Bash shells using the following table which works good.
From this table I can see that for example CTRL+A is '\x01' etc.
import sys,os,Queue
import termios,fcntl
# replace xx with a tty num
tty_name = "/dev/pts/xx";
parent_fd = os.open(tty_name, os.O_RDWR)
special_char = "Ctrl_a"
if special_char == "Ctrl_a":
send_char = '\x01'
if special_char == "Ctrl_e":
send_char = '\x05'
if special_char == "Ctrl_c":
send_char = '\x03'
fcntl.ioctl(self.parent_fd, termios.TIOCSTI, send_char)
But how can I get the hex codes for other combinations such as
ALT+f etc. I need a full list or a way how to get this information for any possible combo as I want to implement most bash shortcuts for moving, manipulating the history etc. to inject.
Or is there any other way to inject key-combinations using TIOCSTI ?
As I can only send single chars to a tty I wonder if there is anything else possible.
Thank you very much for your help!
The usual working of "control codes" is that the "control" modifier substracts 64 from the character code.
"A" is ASCII character 65, so "Ctrl-A" is "65-64=1".
Is it enough for you to extend this scheme to your situation?
So, if you need the control code for, for example, "Device Control 4" (ASCII code 20), you'd add 64, to obtain "84", which is "T".
Therefore, the control-code for DC4 would be "Control+T".
In the reverse direction, the value for "Control+R" (history search in BASH) is R-64, so 82-64=18 (Device Control 2)
ASCIItable.com can help with a complete listing of all character codes in ASCII
Update: Since you were asking specifically for "alt+.":
The 'Control mean minus 64" doesn't apply to Alt, unfortunately; that seems to be handled completely differently, by the keyboard driver, by generating "key codes" (also called "scancodes", variably written with or without spaces) that don't necessarily map to ASCII. (Keycodes just happen to map to ASCII for 0-9 and A-Z, which leads to much confusion)
This page lists some more keycodes, including "155" for "alt+."
I am assigning to the lpszIcon member of the MSGBOXPARAMSW structure(notice the W). I want to use one of the predefined icons like IDI_APPLICATION or IDI_WARNING but they are all ASCII (defined as MAKEINTRESOURCE). I tried doing this:
MSGBOXPARAMSW mbp = { 0 };
mbp.lpszIcon = (LPCWSTR) IDI_ERROR;
but then no icon displayed at all. So how can I use the unicode versions of the IDI_ icons?
There is no ANSI or Unicode variant of a numeric resource ID. The code that you use to set lpszIcon is correct. It is idiomatic to use the MAKEINTRESOURCE macro rather than a cast, but the cast has identical meaning. Your problem lies in the other code, the code that we cannot see.
Reading between the lines, I think that you are targeting ANSI or MBCS. You tried to use MAKEINTRESOURCE but that expands to MAKEINTRESOURCEA. That's what led you to cast. You should have used MAKEINTRESOURCEW to match MSGBOXPARAMSW. That would have resolved the compilation error you encountered. You could equally have changed the project to target UNICODE.
But none of that explains why the icon does not appear in the dialog. There has to be a problem elsewhere. If the dialog appears then the most likely explanation is that you have set hInstance to a value other than NULL. But the code to set lpszIcon is correct, albeit not idiomatic.
I have a blob in postgresql database. Have inserted a C structure into it.
struct temp {
uint64_t a,
uint64_t b,
uint64_t c
};
Now when I write q query in shell for retrieving it.
select resource,.....,blob_column from rtable where rId is=1
I got the result as a blob from database. the result is
x00911ee3561ac801cb0783462586cf01af00000000000000
But now in shell script I need to iterate on this and display the result on console. Tried different things like awe,split , convert_from ,convert function but nothing is helping me.
Can someone tell me how can I read this hex string and get back the integers?
Is this some kind of exersise in programmer-torture? I can't imagine why you'd possibly do this. Not least because your struct-as-a-blob could be subject to padding and alignment that will vary from compiler to compiler and platform to platform. Even then, it'll vary between architectures because of endianness differences. At least you used fixed-width types.
Assuming you only care about little-endian and your compilers don't add any padding or alignment (likely for a struct that's just 3 64-bit fields) it's possible. That doesn't make a great idea.
My preferred approach would be to use some Python code with struct, e.g.
python - "x00911ee3561ac801cb0783462586cf01af00000000000000" <<__END__
import sys
import struct
print "{} {} {}".format(*struct.unpack('#QQQ', sys.argv[1][1:].decode("hex")))
__END__
as this can even handle endianness and packing using appropriate modifiers, and you can easily consume the output in a shell script.
If that's not convenient/suitable, it's also possible in bash, just absolutely horrible. For little-endian, unpadded/packed-unaligned:
To decode each value (adapted from https://stackoverflow.com/a/3678208/398670):
$ x=00911ee3561ac801
$ echo $(( 16#${x:14:2}${x:12:2}${x:10:2}${x:8:2}${x:6:2}${x:4:2}${x:2:2}${x:0:2} ))
so, for the full deal:
x=x00911ee3561ac801cb0783462586cf01af00000000000000
uint64_dec() {
echo $(( 16#${1:14:2}${1:12:2}${1:10:2}${1:8:2}${1:6:2}${1:4:2}${1:2:2}${1:0:2} ))
}
uint64_dec ${x:1:16}
uint64_dec ${x:17:16}
uint64_dec ${x:33:16}
produces:
128381549860000000
130470408871937995
175
Now, I feel dirty and need to go wash. I strongly suggest the following:
CREATE TYPE my_struct AS (a numeric, b numeric, c numeric);
then using my_struct instead of a bytea field. Or just use three numeric columns. You can't use bigint because Pg doesn't have a 64-bit unsigned integer.
I have some existing Visual C++ code where I need to add the conversion of wide character strings to upper or lower case.
I know there are pitfalls to this (such as the Turkish "I"), but most of these can be ironed-out if you know the language. Fortunately in this area of code I know the LCID value (locale ID) which I guess is the same as knowing the language.
As LCID is a Windows type, is there a Windows function that will convert wide strings to upper or lower case?
The C runtime function _towupper_l() sounds like it would be ideal but it takes a _locale_t parameter instead of LCID, so I guess it's unsuitable unless there is a completely reliable way of converting an LCID to a _locale_t.
The function you're searching for is called LCMapString and it is part of the Windows NLS APIs. The LCMAP_UPPERCASE flag maps characters to uppercase, while the LCMAP_LOWERCASE maps characters to lowercase.
For applications targeting Windows Vista and later, there is an Ex variant that works on locale names instead of identifiers, which are what Microsoft now says you should prefer to use.
In fact, in the CRT implementation provided with VS 2010 (and presumably other versions as well), functions such as _towupper_l ultimately end up calling LCMapString after they extract the locale ID (LCID) from the specified _locale_t.
If you're like me, and less familiar with the i8n APIs than you should be, you probably already know about the CharUpper, CharLower, CharUpperBuff, and CharLowerBuff family of functions. These have been the old standbys from the early days of Windows for altering the case of chars/strings, but as their documentation warns:
Note that CharXxx always maps uppercase I to lowercase I ("i"), even when the current language is Turkish or Azeri. If you need a function that is linguistically sensitive in this respect, call LCMapString.
What it neglects to mention is filled in by a couple of posts on Michael Kaplan's wonderful blog on internationalization issues: What does "linguistic casing" mean?, How best to alter case. The executive summary is that you achieve the same results as the CharXxx family of functions by calling LCMapString and not specifying the LCMAP_LINGUISTIC_CASING flag, whereas you can be linguistically sensitive by ensuring that you do specify the LCMAP_LINGUISTIC_CASING flag.
Sample code:
std::wstring test("Does my code pass the Turkey test?");
if (!LCMapStringW(lcid, /* your LCID, defined elsewhere */
LCMAP_UPPERCASE | LCMAP_LINGUISTIC_CASING,
test.c_str(), /* input string */
test.length(), /* length of input string */
&test[0], /* output buffer (can reuse input) */
test.length())) /* length of output buffer (same as input) */
{
// Uh-oh! Something went wrong in the call to LCMapString, so you need to
// handle the error somehow here.
// A good start is calling GetLastError to determine the error code.
}
I've got some legacy code I'm trying to compile, and my available compilers are choking. Here are the lines causing the problems:
line 5:
DIMENSION MMO(12)/31,28,31,30,31,30,31,31,30,31,30,31/
lines 7, 8:
DEFINE FILE 4(ANSI,FB,140,3360,0)
DEFINE FILE 7(SDF, ,42,42)
line 119:
1905 FORMAT(J2,J4,J2,29I5)
Lahey-Fujistu 95 says:
1116-S: "fz32.f", line 5, column 24: Comma expected.
1110-S: "fz32.f", line 5, column 28: Missing name.
1336-S: "fz32.f", line 7, column 7: DEFINE FILE statement not supported.
1336-S: "fz32.f", line 8, column 7: DEFINE FILE statement not supported.
1511-S: "fz32.f", line 119: Invalid character string 'J' found in format specification.
1515-S: "fz32.f", line 119: Edit descriptor must be specified after the repeat specification in a format specification.
...and more missing name errors
gfortran 77 says:
fz32.f:5:
DIMENSION MMO(12)/31,28,31,30,31,30,31,31,30,31,30,31/
^
Invalid form for DIMENSION statement at (^)
fz32.f:7:
DEFINE FILE 4(ANSI,FB,140,3360,0)
1 2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
fz32.f:8:
DEFINE FILE 7(SDF, ,42,42)
1 2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
fz32.f:119:
1905 FORMAT(J2,J4,J2,29I5)
^
Unrecognized FORMAT specifier at (^)
fz32.f:119:
1905 FORMAT(J2,J4,J2,29I5)
^
Unrecognized FORMAT specifier at (^)
fz32.f:119:
1905 FORMAT(J2,J4,J2,29I5)
^
Unrecognized FORMAT specifier at (^)
gcc fails with similar errors.
So does anyone know what compiler could have been used to build this code?
Also, on lines 7 and 8, ANSI and SDF are not defined earlier in the code. How do these lines work? I expect them to be formatting flags, but I don't see that documented anywhere.
DEFINE FILE are likely from IBM OS/360's FORTRAN compiler and are related to the operating system JCL. There are probably other implementations, but there is no need (and little utility) on a modern o/s to specify the future number of records and record size in a file. See this for details.
The initialized dimension (a non-standard language extension) can be changed to a data statement:
DIMENSION MMO(12)
DATA MMO/31,28,31,30,31,30,31,31,30,31,30,31/
I vaguely recall coming across the J format code before, but don't recall what it means. Given the context, you might change them to I and see if that will work:
1905 FORMAT(I2,I4,I2,29I5)
I think that these are all non-standard Fortran. That was pretty common up to FORTRAN 77 when the vendors tried to compete by offering convenient extensions. It was also a lock-in trap, but people were less sensitive to that back then. I think that you would be better off translating your code to standard compliant by deducing what this stuff is supposed to do. It depends on how many lines that you have how difficult that would be. There are some code conversion products (e.g., SPAG, http://www.polyhedron.com/spagqa0html) -- I don't know whether they would understand these extensions.
This one:
DIMENSION MMO(12)/31,28,31,30,31,30,31,31,30,31,30,31/
is just a non-standard version of a data statement. In F77 you could do
DIMENSION MMO(12)
DATA MMO /31,28,31,30,31,30,31,31,30,31,30,31/
or in modern fortran you could do
integer, dimension(12) :: mmo = [31,28,31,30,31,30,31,31,30,31,30,31 ]
The define stuff is a little more obscure (and probably identifies the compiler as a DEC compiler or related -- oof, that's old). It looks like you're going to want to convert
DEFINE FILE 4(ANSI,FB,140,3360,0)
DEFINE FILE 7(SDF, ,42,42)
Into something like
OPEN(unit=4, access='direct', reclen=FB)
OPEN(unit=7, access='direct')
and see how that goes.
The J specifier I can't find anywhere (and googling for J is about as helpful as you'd think). So maybe I'm wrong about DEC. Can you give us an example as to how format 1905 is used?