I’m trying to make a C program which is prompting the user to type a message from the console and then show that message the user has typed, as in the following example:
C:>promptTest
type your message >>>> test
typed : test
C:>
This is my code:
#include <stdio.h>
#include <string.h>
int main(){
char msg[32];
printf("type your message >>>>\t");
fgets(msg,sizeof(msg),stdin);
msg[strlen(msg) - 1] = '\0';
printf("typed : %s\n",msg);
return 0;
}
It can be built on both Windows7 and CentOS and it can be run normally on Windows like above.
However, it can’t be run on CentOS. I mean nothing accepts any message from the prompt like below:
$ ./promptTest
type your message >>>> test
typed :
$
How can I fix this?
Here is information about my machine.
$ cat /etc/redhat-release
CentOS release 6.4 (Final)
$
$ arch
x86_64
$
strlen() returns size_t not int.
Printing size_t on a 64bit IXish system using %d might fail, as the former most likly is 64bit while the latter expects 32bit.
So at least on a 64bit IXish system instead of
printf("### buf(%d) = %s\n",strlen(buf),buf);
printf("### message(%d) = %s\n",strlen(message),message);
do
printf("### buf(%zu) = %s\n",strlen(buf),buf);
printf("### message(%zu) = %s\n",strlen(message),message);
As a (ugly) workaround you could also cast strlen() down to int.
printf("### buf(%d) = %s\n", (int) strlen(buf),buf);
printf("### message(%d) = %s\n", (int) strlen(message),message);
This workaround however assumes no string being longer then INT_MAX.
I found the solution.
CL+LF coused this matter.
see Controlling prompt for command line
Related
I need to get this stripped-down C program working on Windows 7 using MSys2's gcc toolchain:
#include <stdio.h>
void wmain(int argc, wchar_t *argv[])
{
for (int i = 1; i < argc; i++)
wprintf(L"%s\n", argv[i]);
}
The code compiles with
gcc -Wall -municode -O2 -march=x86-64 -m64 test.c
but gives me the following output
>> ./a.exe kk лл
k (!)
:?:?
I have the following questions:
What am I doing wrong?
How would I downgrade the compiler to
version, say, 9.x, or 10.1? (I'm under the impression that the very
same program compiled about one year ago used to work correctly)
Edit [1]: Meanwhile I managed to set up a new MSys2 environment using gcc 9.3. The "error" persists, so it's not the compiler.
Edit [2]: "Some programmer dude" (cmp. below) described the "immediate" solution (THX!).
Even for the wide-character wprintf the format %s is for narrow character strings.
You need to use %ls to print wide-character strings:
wprintf(L"%ls\n", argv[i]);
However this might still not be enough, as the actual encoding of the input (including arguments) might not be what's expected. You need to take into account the encoding used by the terminal the program is running in.
We have started C programming in my Uni, and I appear to have fallen at the first hurdle. My very simple program will not print to the terminal. The code:
#include "stdio.h"
int main(){
printf("Memory size for type %s = %lu \n", "double", sizeof(double));
return 0;
}
I have used all my google-fu, and have only found that I apparently should use vprint, but it won't take three arguments, only two. Also, bizarrely, printing to a file works! See screenshot:
Terminal screenshot
The format specifier for size_t(the return type of sizeof) is %zu.
printf("Memory size for type %s = %zu \n", "double", sizeof(double));
Alright, apparently, when I simply run the program, Clang prints the output to a.out in the same directory as the code, and there's nothing I can do about it. Whatever, as long as the code works - means I can turn it in, and I'll be checking my work with ./a.out.
According to your screenshot, it appears that there is a misconception here :
gcc 1.c
gcc is used to compile the program (creating the executable, here using the source file 1.c), not to run it. The program might have been compiled under the name 'a.out'.
When you compile your program using :
gcc 1.c -o 1.txt
You are actually compiling the program with gcc and, using the option -o, creating the executable under the name 1.txt (a program can be named whatever you want, or almost)
Then when you type
./1.txt
you are actually running the program (1.txt) and you have the expected output.
I am working on an assignment for class, in which we have to build a simple shell interface for a Unix system in C. I am using Ubuntu and when I run the source code in that was provided using this command:
osh> cat shell.c
I get an error:
*** omake error: File /home/cameron/cs426/Project1/shell.c: line 11, characters 20-24
unexpected token: string: {
This is my first time using osh, so does anyone have any ideas as to what the issue might be?
Also, here's the code, just in case.
#include<stdio.h>
#include<unistd.h>
#define MAX_LINE 80 /* 80 chars per line, per command */
int main(void)
{
char *args[MAX_LINE/2 + 1]; /* command line (of 80) has max of 40 arguments */
int should_run = 1;
while(should_run){
printf("osh>");
fflush(stdout);
/**
* After reading user input, the steps are:
* (1) fork a child process
* (2) the child process will invoke execvp()
* (3) if command included &, parent will invoke wait()
*/
}
return 0;
}
It looks like this code was intended to be a shell. What you need to do is:
Open a terminal that runs a real shell. osh is the OMake shell, and is probably not relevant this assignment. The code you gave prints "osh", but isn't the osh.
Compile with gcc -o shell-that-calls-itself-osh shell.c The -o flag tells gcc where to put the compiled binary.
Run with ./shell-that-calls-itself-osh The ./ is to run code in the current directory.
I have installed MinGW on netbeans for C and C++ programming.
Here is a simple code that I am trying to run on netbeans :
#include <stdio.h>
int main(int argc, char** argv) {
printf("Inside Main...\n");
int n;
printf("Enter : ");
scanf("%d", &n); // When I remove this line, it is working.
printf("You have entered %d.", n);
return (1);
}
Whenever I try to access any value from netbeans console, I don't see anything.
Output with scanf(...)
Output without scanf(...)
And if I try to run these code from cmd, all are working
for scanf() you must use Netbeans External Terminal !
Normal Run
You can also use Netbeans Standard Output !
But this is more misleading.
While you see an empty Terminal do input 123
after hit enter , you get the output all at once .
I had the same issue while running a CPP program.External output didn't helped me. I set the console type to Standard output and it solved the issue.
Right Click cpp Application-->properties-->run--->Consoletype to standard output
I'm compiling the below C code with gcc. No errors are thrown during compilation or at runtime. I ran through the code with gdb, and the answer given in sum is correct at the end, yet the printf() does not display anything on the screen. I've tried all sorts of combinations of fprintf(), printf(), and fflush(), but nothing works.
What do I need to change so the program will print the result to stdout?
#include <stdio.h>
#include <stdlib.h>
int main()
{
int num = 9;
int i, sum; i = 1, sum = 0;
while (i < 2 * num) {
sum = sum + i * i;
++i;
}
printf("sum: %d\n", sum);
fflush(stdout);
return 0;
}
The code is correct, and should print sum: 1785 for any conforming implementation.
This is a guess (update: which turns out to be correct), but ...
You've named the source file test.c, and you compile it with:
$ gcc test.c -o test
(or something similar) and execute it with:
$ test
which produces no output.
The problem is that test is a standard Unix command (and also a built-in command in some shells). When you type a command name to the shell, it first looks for built-in commands, then for executables in directories specified in your $PATH environment variable.
To execute a command in the current directory, prepend ./ to the name:
$ ./test
sum: 1785
$
This applies to any command in the current directory. There are so many built-in commands that you can't reasonably avoid colliding with them. Cultivating the habit of running executables in the current directory by typing ./whatever means that name collisions don't matter.
(Don't be tempted to add . to the front of your $PATH; that's dangerous. Think about what could happen if you cd into a directory and type ls, if there happens to be a malicious ls command there.)
There is nothing wrong with your program. It has to work. Try running it with redirection:
./a.out > myout
..and see if you get any output. If not, I'd suspect there is a problem with some kind of standard library mismatch.
Another option to check would be to build using SUN C compiler as opposed to gcc and see if that works. If it does, gcc is the culprit.