I'm working with Arduino.
I want to send Ctrl+z after a string in C. I tried truncating ^Z but that didn't work. So how to do that ?
Ctrl+Z = 26 = '\032' = '\x1A'. Either of the backslash escape sequences can be written in a string literal (but be careful with the hex escape as if it is followed by a digit or A-F or a-f, that will also be counted as part of the hex escape, which is not what you want).
However, if you are simulating terminal input on a Windows machine (so you want the character to be treated as an EOF indication), you need to think again. That isn't how it works.
It may or may not do what you want with Arduino, either; in part, it depends on what you think it is going to do. It also depends on whether the input string will be treated as if it came from a terminal.
I hacked this up as I needed similar
#include <stdio.h>
#define CTRL(x) (#x[0]-'a'+1)
int main (void)
{
printf("hello");
printf("%c", CTRL(n));
printf("%c", CTRL(z));
}
hope it helps 8)
I assume by "truncating" you actually meant appending.
In ASCII, CTRL+z is code point 26 so you can simply append that as a character, something like:
#define CTRL_Z 26
char buffer[100];
sprintf (buffer, "This is my message%c", CTRL_Z);
The sprintf method is only one of the ways of doing this but they all basically depend on you putting a single byte at the end with the value 26.
The following should work:
whatever you are trying to write append \032 at the end
For example:
strcpy(InputCommand,"hi\032");
GetSerialData(InputCommand,......); //this is my own function which uses serialPuts()
Related
I am trying to read non-printable characters from a text file, print out the characters' ASCII code, and finally write these non-printable characters into an output file.
However, I have noticed that for every non-printable character I read, there is always an extra non-printable character existing in front of what I really want to read.
For example, the character I want to read is "§".
And when I print out its ASCII code in my program, instead of printing just "167", it prints out "194 167".
I looked it up in the debugger and saw "§" in the char array. But I don't have  anywhere in my input file.
screenshot of debugger
And after I write the non-printable character into my output file, I have noticed that it is also just "§", not "§".
There is an extra character being attached to every single non-printable character I read. Why is this happening? How do I get rid of it?
Thanks!
Code as follows:
case 1:
mode = 1;
FILE *fp;
fp = fopen ("input2.txt", "r");
int charCount = 0;
while(!feof(fp)) {
original_message[charCount] = fgetc(fp);
charCount++;
}
original_message[charCount - 1] = '\0';
fclose(fp);
k = strlen(original_message);//split the original message into k input symbols
printf("k: \n%lld\n", k);
printf("ASCII code:\n");
for (int i = 0; i < k; i++)
{
ASCII = original_message[i];
printf("%d ", ASCII);
}
C's getchar (and getc and fgetc) functions are designed to read individual bytes. They won't directly handle "wide" or "multibyte" characters such as occur in the UTF-8 encoding of Unicode.
But there are other functions which are specifically designed to deal with those extended characters. In particular, if you wish, you can replace your call to fgetc(fp) with fgetwc(fp), and then you should be able to start reading characters like § as themselves.
You will have to #include <wchar.h> to get the prototype for fgetwc. And you may have to add the call
setlocale(LC_CTYPE, "");
at the top of your program to synchronize your program's character set "locale" with that of your operating system.
Not your original code, but I wrote this little program:
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
int main()
{
wchar_t c;
setlocale(LC_CTYPE, "");
while((c = fgetwc(stdin)) != EOF)
printf("%lc %d\n", c, c);
}
When I type "A", it prints A 65.
When I type "§", it prints § 167.
When I type "Ƶ", it prints Ƶ 437.
When I type "†", it prints † 8224.
Now, with all that said, reading wide characters using functions like fgetwc isn't the only or necessarily even the best way of dealing with extended characters. In your case, it carries a number of additional consequences:
Your original_message array is going to have to be an array of wchar_t, not an array of char.
Your original_message array isn't going to be an ordinary C string — it's a "wide character string". So you can't call strlen on it; you're going to have to call wcslen.
Similarly, you can't print it using %s, or its characters using %c. You'll have to remember to use %ls or %lc.
So although you can convert your entire program to use "wide" strings and "w" functions everywhere, it's a ton of work. In many cases, and despite anomalies like the one you asked about, it's much easier to use UTF-8 everywhere, since it tends to Just Work. In particular, as long as you don't have to pick a string apart and work with its individual characters, or compute the on-screen display length of a string (in "characters") using strlen, you can just use plain C strings everywhere, and let the magic of UTF-8 sequences take care of any non-ASCII characters your users happen to enter.
This piece of code is acting a bit strange to my taste. Please, anyone care to explain why? And how to force '\n' to be interpreted as a special char?
beco#raposa:~/tmp/user/foo/bar$ ./interpretastring.x "2nd\nstr"
1st
str
2nd\nstr
beco#raposa:~/tmp/user/foo/bar$ cat interpretastring.c
#include <stdio.h>
int main(int argc, char **argv)
{
char *s="1st\nstr";
printf("%s\n", s);
printf("%s\n", argv[1]);
return 0;
}
Bottom line, the intention is that the 2nd string to be printed in two lines, just like the first. This program is a simplification. The real program has problems reading from a file using fgets (not a S.O. argument to argv like here), but I think solving here will also solve there.
It seems the shell doesn't recognize and convert the "escape sequence". Use a shell software that supports \n escape sequence.
For all purposes, this just take care of \n and no other characters get special treatment.
This answer here does the job with lower complexity. It does not change "2 chars" into "one single special \n". It just changes <\><n> to "<space><newline>". That's fine. It would be better if there were a C Standard Library to interpret special chars in a string (as I know it has for RegExp for instance).
/* change '\\n' into ' \n' */
void changebarn(char *nt)
{
while(nt!=NULL)
if((nt=strchr(nt,'\\')))
if(*++nt=='n')
{
*nt='\n';
*(nt-1)=' ';
}
}
I have a character in a char-Array which I get with fputs(). But it contains a char which is getting count by the function strlen(). I decide to give me out the int value of this char to see where the problem is.
As char I can see nothing. Thought its a Whitespace but not sure. Would like if someone could tell me what it is and explain why it is there.
printf("%d",(int) input[6]); //--> give me the value of 10 out.
The value 10 is the ASCII value for the newline character (LF, or linefeed). Closely related is character 13, which is CR, or carriage return, which, on Windows systems, often precedes the LF character. I would suggest getting a copy of the ASCII table (they're all over the web) and referencing it from time to time.
Character 10 can be represented by '\n' in C code, as well as '\012', '\x0a', and '\u000a'
Character 13 (carriage return) can be represented by '\r', '\015', '\x0d', and '\u000d'.
It is the newline (LF (NL line feed, new line)) in ASCII. See all of the values here.
As already pointed out by the others, the character 10 in ASCII is LF (line feed).
If you wanted printf to output the character (not see its ordinal value), you could use the %c format specifier to pass a single character.
Example:
printf("-%c-", input[6]);
should yield:
-
-
I.e. two dashes separated by a line feed. Please keep in mind that the outcome on Windows depends on how your C runtime handles a single LF without CR as on Windows a line break is customarily represented by CRLF instead of just LF which is the standard on unixoid systems. The only exception to that rule were old Mac systems which used to use only CR to encode a line break.
Reading about how to use shift sequences to print characters from other character sets I've arrived at the following code (of which I'm sure the escape sequence is incorrect, however I do not know why):
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("\x1B\x28\x49\x0E\xB3"); /* Should print: ｳ */
return 0;
}
This however is not working for me as it outputs a "?" in the terminal rather than the character "ｳ". My font does indeed have support for the character. If someone could explain what I'm doing incorrectly and how I would go about correcting this(still using shift sequences), that would be greatly appreciated.
Thank you
Your are using ISO-2022-JP-3. Hence you need to write your program as follows:
int main ()
{
// switch to JIS X 0201-1976 Kana set (1 byte per character)
printf ("\x1B(I");
printf ("\x33"); /* ｳ */
// mandatory switch back to ASCII before end of line
printf ("\x1B(B");
printf ("\n");
return 0;
}
Note however that it is unlikely to be the character set expected by the terminal (on linux, this is most likely UTF-8). You can use iconv to perform the conversion:
$ ./main | iconv -f ISO-2022-JP-3
Alternatively you can use iconv(3) to perform the conversion inside your program.
What happens if you do echo 'ｳ' >/tmp/x && od -x /tmp/x - do you see the same hex characters as you are using in the example above? I'm betting not, and I've based this answer on that bet.
Your cat works because ｳ is encoded in your source file as UTF-8.
You have your terminal set to UTF-8 (or more likely it's just defaulting to UTF-8) so UTF-8 works, but Shift-JIS does not.
This code comes from K&R. I have read it several times, but it still seems to escape my grasp.
#define BUFSIZE 100
char buf[BUFSIZE];
int bufp = 0;
int getch(void)
{
return(bufp>0)?buf[--bufp]:getchar();
}
int ungetch(int c)
{
if(bufp>=BUFSIZE)
printf("too many characters");
else buf[bufp++]=c;
}
The purpose of these two functions, so K&R says, is to prevent a program from reading too much input. i.e. without this code a function might not be able to determine it has read enough data without first reading too much. But I don't understand how it works.
For example, consider getch().
As far as I can see this is the steps it takes:
check if bufp is greater than 0.
if so then return the char value of buf[--bufp].
else return getchar().
I would like to ask a more specific question, but I literally dont know how this code achieves what it is intended to achieve, so my question is: What is (a) the purpose and (b) the reasoning of this code?
Thanks in advance.
NOTE: For any K&R fans, this code can be found on page 79 (depending on your edition, I suppose)
(a) The purpose of this code is to be able to read a character and then "un-read" it if it turns out you accidentally read a character too many (with a max. of 100 characters to be "un-read"). This is useful in parsers with lookahead.
(b) getch reads from buf if it has contents, indicated by bufp>0. If buf is empty, it calls getchar. Note that it uses buf as a stack: it reads it from right-to-left.
ungetch pushes a character onto the stack buf after doing a check to see if the stack isn't full.
The code is not really for "reading too much input", instead is it so you can put back characters already read.
For example, you read one character with getch, see if it is a letter, put it back with ungetch and read all letters in a loop. This is a way of predicting what the next character will be.
This block of code is intended for use by programs that make decisions based on what they read from the stream. Sometimes such programs need to look at a few character from the stream without actually consuming the input. For example, if your input looks like abcde12xy789 and you must split it into abcde, 12, xy, 789 (i.e. separate groups of consecutive letters from groups of consecutive digits) you do not know that you have reached the end of a group of letters until you see a digit. However, you do not want to consume that digit at the time you see it: all you need is to know that the group of letters is ending; you need a way to "put back" that digit. An ungetch comes in handy in this situation: once you see a digit after a group of letters, you put the digit back by calling ungetch. Your next iteration will pick that digit back up through the same getch mechanism, sparing you the need to preserve the character that you read but did not consume.
1. The other idea also shown here can be also called as a very primitive I/O stack mangement system and gives the implementation of the function getch() and ungetch().
2. To go a step further , suppose you want to design an Operating System , how can you handle the memory which stores all the keystrokes?
This is solved by the above code snippet.An extension of this concept is used in file handling , especially in editing files .In that case instead of using getchar() which is used to take input from Standard input , a file is used as a source of input.
I have a problem with code given in question. Using buffer (in form of stack) in this code is not correct as when getting more than one extra inputs and pushing into stack will have undesired effect in latter processing (getting input from buffer).
This is because when latter processing (getting input) going on ,this buffer (stack) will give extra input in reverse order (means last extra input given first).
Because of LIFO (Last in first out ) property of stack , the buffer in this code must be quene as it will work better in case of more than one extra input.
This mistake in code confused me and finally this buffer must be quene as shown below.
#define BUFSIZE 100
char buf[BUFSIZE];
int bufr = 0;
int buff = 0;
int getch(void)
{
if (bufr ==BUFSIZE)
bufr=0;
return(bufr>=0)?buf[bufr++]:getchar();
}
int ungetch(int c)
{
if(buff>=BUFSIZE && bufr == 0)
printf("too many characters");
else if(buff ==BUFSIZE)
buff=0;
if(buff<=BUFSIZE)
buf[buff++]=c;
}