When I run the code below, it runs the system command on the 4th last line before displaying the string 'proceeding' before it! I'm wondering why and how to fix it, any ideas?
if ((strlen(command)>0) && (command[strlen (command) - 1] == '\n'))
command[strlen (command) - 1] = '\0';
printf("proceeding"); // <-- the string
strcat(command,contents);
strcat(command,subject);
system(command); // <-- offending system command
sleep (1);
printf("\n ----- Search complete for: [%s]",command);
getchar();
There are of course variables such as 'command' and 'subject' which are manipulated and declared outside the code above, so If you need context than I will post the rest of the source code below.
Pull the chain and flush:
I.e.
After
printf("proceeding");
Put
fflush(stdout);
That will flush the stuff in the buffer (bowl!)
Before the system command is executed.
Try adding a '\n' to the printf.
It forces flushing the printf buffer. Otherwise, it is not necessary that printf immediately prints the passed params. You can google flushing the buffer latter
stdout is line buffered, so it will only display what's in the buffer after it reaches a newline
change printf("proceeding"); to printf("proceeding\n"); or flush stdout with fflush(stdout); will do the work.
The stdio stdout stream is line or fully buffered by default. To set it unbuffered (and to avoid having to write a fflush(stdout) after every output operation), use the ISO C setvbuf function declared in stdio.h:
setvbuf(stdout, (char *)NULL, _IONBF, 0);
once before doing the first I/O.
Related
#include <stdio.h>
#define MAXLEN 256
int main() {
int n;
char buf[MAXLEN];
while((n = read(0,buf,sizeof(buf))) != 0){
printf("n: %d:",n);
write(1,buf,n);
}
return 1;
}
The output of the program (where the first read and first write is typed by the user and echoed by the terminal) is:
read
read
write
write
n: 5:n: 6:
The output of printf comes after pressing Ctrl+D at the standard input and not along with the subsequent reads. Why does this happen?
Printf is buffered.
You can force printf to 'flush' its buffer using the fflush call:
#include <stdio.h>
#define MAXLEN 256
int main() {
int n;
char buf[MAXLEN];
while((n = read(0,buf,sizeof(buf))) != 0){
printf("n: %d:",n);
fflush(stdout); /* force it to go out */
write(1,buf,n);
}
return 1;
}
In general, printf() being buffered is a good thing. Unbuffered output, particularly to visible consoles that require screen updates and such, is slow. Slow enough that an application that is printf'ing a lot can be directly slowed down by it (especially on the Windows platform; Linux and unixes are typically impacted less).
However, printf() being buffered does bite you if you also fprintf(stderr,) - stderr is deliberately unbuffered. As a consequence, you may get your messages with some printf() missing; if you write to another FILE handle that is also associated with the terminal, and might be unbuffered, make sure you first explicitly fflush(stdout).
The manpage for fgets tells me:
It is not advisable to mix calls to input functions from the stdio
library with low-level calls to read(2) for the file descriptor associ‐
ated with the input stream; the results will be undefined and very
probably not what you want.
So the best solution would be not to to use write and printf on the same descriptor.
Printf is using stdio and it is buffered.
Push it out by sending a changing to "n: %d:\n"
You can use the std fflush() function to flush the std out buffer or you can make use of an additional \n at the end of the control string inside the printf. Something like this
printf("\n :%d:\n",n);
Its always better to use the write() & read() functions in C instead of printf() and scanf(). Printf and scanf have got some problems like printf stores the string parameter in stdout buffer. So a manual flush is required which is done through fflush function or by means of \n. In a small hello world printing program you will not find such a problem as the stdout buffer is flushed at the end of the program execution. Better use write() which works fine. scanf also have the problem of reading spaces and a lot of other problems related to stdin buffer.
For example in the code below:
main() { char a; int i=0,c; for(;i<2;i++) { scanf("%d",&c); scanf("%c",&a);} }
The above program as got the problem of reading \n into stdin on pressing enter. We could resolve this but not flushing the stdin buffer or making use of \n character. Always better to use the read() and write() functions.
Hope that helps....
Use fwrite (streams version) rather than write.
Note that, while is associated with file number 1, it isn't the same thing.
I have started looking into command processing with C but I have hit a problem with this C program. It is executing the ls command before it is intended.
Gcc info:
gcc version 6.2.1 20161124 (Debian 6.2.1-5)
This is the code:
#include <stdio.h>
#include <stdlib.h>
int main()
{
int i;
printf("Is command processor available?\n");
if (system(NULL))
{
printf("Command processor available!\n");
}
else
{
printf("Command processor not available!\n");
exit(1);
}
printf("Executing command ls");
i=system("ls");
printf("Returned value is: %d.\n",i);
return 0;
}
The piece of code I am speaking about is this specific line:
printf("Executing command: ls");
If the program is ran with that piece of code the output is:
Is command processor available?
Command processor is available
systemProcessing systemProcessing.c
Executing command: lsReturned value is: 0.
It executes the command before actually being told to
But when I finish the code off with a new line '\n', its output is as expected:
Is command processor available?
Command processor is available
Executing command: ls
systemProcessing systemProcessing.c
Returned value is: 0.
Why is it that with the newline added to the string the code prints what it is about to do before executing, but without it it executes and then prints that is is going to execute?
It's a buffering issue. You need to do:
printf("Executing command ls");
fflush(stdout); //<<
i=system("ls");
or, if your output is a line-buffered terminal and you're OK
with adding a line instead of an explicit fflush(stdout) call:
printf("Executing command ls\n");
stdio 101:
Small read/writes to the OS are inefficient, so stdio IO (by default) associates each file handle/descriptor with an input buffer and an output buffer. stdio output calls output into the appropriate FILE's (in this case, it's stdout) output buffer (by memcpying the string), and only when the (large) buffer is full will a system call to write the whole buffer be made (problem solved).
An explicit flush of an output buffer may be elicited with the fflush() function. Additionally, if stdio detects an output FILE is a terminal, it will use line buffering which means it will call fflush() whenever it encounters a newline in the output.
The buffering mode of an stdio FILE may also be explicitly manipulated with the setvbuf() function. See the manpage in the link to learn how it can be used.
Standard output via printf is buffered, which means it doesn't flush to destination immediately after calling printf. When you use system to run a separate process after calling printf without that being flushed that new process's output might print before your printf gets printed.
Adding a new line makes the difference since a new line is immediately flushing the buffer. You could have used fflush too instead of newline.
here is my loop code
#exe2.rb
loop do
print "#{::Time.now}\r"
sleep 1
end
and I use following c to capture its out:
fp = popen("ruby /home/roroco/Dropbox/rbs/ro_cmds/exe2.rb", "r");
while (fgets(var, sizeof(var), fp) != NULL) {
printf("%s", var);
}
but it stuck in fgets, how to make it work?
This is an effect of buffering. In UNIX stdout is line-buffered by default, which means that the stdio facility accumulates bytes till some buffer fills or it encounters a '\n'. This is beneficial to limit I/O thus improving performance (I/O is slow).
For this reason, change your ruby code to print a new line '\n' at the end instead of a carriage return '\r' (because fgets(3) is for lines). You don't need to change the C code as fgets(3) doesn't chomp the newline.
The Ruby interpreter treats stdout the same, unless it's a pipe. If that's the case it's fully buffered. The easiest way to get around that is doing a STDOUT.flush after every write in the ruby script.
I'm a newbie, trying to really understand systems programming. In the following program, I'm reading a file called 'temp1' (containing 1 2 3 4) and printing its contents to stdout. However, I also wanted to check the value of file descriptor returned by open. If I include the '\n' in printf call on line 5, the output prints value filep first and then contents of file. But if I remove the newline, the contents of file get printed first and then the value of filep.
Why would this happen ?
int main(){
char buf[BUFSIZ];
int n, filep;
// Open the file
filep = open("temp1", 'r');
printf("%d\n", filep); // the newline alters program behaviour
while((n=read(filep, buf, BUFSIZ)) > 0)
write(1, buf, n);
return 0;
}
I am using gcc 4.6.3.
<stdio.h> functions like printf are buffered. Output functions will call the write(2) syscall only from time to time, usually output functions like printf etc... are going only into the internal FILE buffer.
The stdout is line-buffered when outputting to a terminal (see isatty(3)). So if a printf format string ends with \n the write will occur.
You could add a fflush(stdout); or fflush(NULL); call before your while loop.
See fflush(3) and setvbuf(3)
If you don't flush stdout (either with a \n in printf format string, or explicitly thru fflush or fclose) the buffer is flushed only at the end of main (thru some implicit atexit(3) ...)
So what is happening to you is that (without the \n) data stays in the stdout buffer, and is actually written (by the write(2) inside stdio library) only at the exit of your program.
Read advanced linux programming.
#include <stdio.h>
#define MAXLEN 256
int main() {
int n;
char buf[MAXLEN];
while((n = read(0,buf,sizeof(buf))) != 0){
printf("n: %d:",n);
write(1,buf,n);
}
return 1;
}
The output of the program (where the first read and first write is typed by the user and echoed by the terminal) is:
read
read
write
write
n: 5:n: 6:
The output of printf comes after pressing Ctrl+D at the standard input and not along with the subsequent reads. Why does this happen?
Printf is buffered.
You can force printf to 'flush' its buffer using the fflush call:
#include <stdio.h>
#define MAXLEN 256
int main() {
int n;
char buf[MAXLEN];
while((n = read(0,buf,sizeof(buf))) != 0){
printf("n: %d:",n);
fflush(stdout); /* force it to go out */
write(1,buf,n);
}
return 1;
}
In general, printf() being buffered is a good thing. Unbuffered output, particularly to visible consoles that require screen updates and such, is slow. Slow enough that an application that is printf'ing a lot can be directly slowed down by it (especially on the Windows platform; Linux and unixes are typically impacted less).
However, printf() being buffered does bite you if you also fprintf(stderr,) - stderr is deliberately unbuffered. As a consequence, you may get your messages with some printf() missing; if you write to another FILE handle that is also associated with the terminal, and might be unbuffered, make sure you first explicitly fflush(stdout).
The manpage for fgets tells me:
It is not advisable to mix calls to input functions from the stdio
library with low-level calls to read(2) for the file descriptor associ‐
ated with the input stream; the results will be undefined and very
probably not what you want.
So the best solution would be not to to use write and printf on the same descriptor.
Printf is using stdio and it is buffered.
Push it out by sending a changing to "n: %d:\n"
You can use the std fflush() function to flush the std out buffer or you can make use of an additional \n at the end of the control string inside the printf. Something like this
printf("\n :%d:\n",n);
Its always better to use the write() & read() functions in C instead of printf() and scanf(). Printf and scanf have got some problems like printf stores the string parameter in stdout buffer. So a manual flush is required which is done through fflush function or by means of \n. In a small hello world printing program you will not find such a problem as the stdout buffer is flushed at the end of the program execution. Better use write() which works fine. scanf also have the problem of reading spaces and a lot of other problems related to stdin buffer.
For example in the code below:
main() { char a; int i=0,c; for(;i<2;i++) { scanf("%d",&c); scanf("%c",&a);} }
The above program as got the problem of reading \n into stdin on pressing enter. We could resolve this but not flushing the stdin buffer or making use of \n character. Always better to use the read() and write() functions.
Hope that helps....
Use fwrite (streams version) rather than write.
Note that, while is associated with file number 1, it isn't the same thing.