What I am trying to do is create a program that will, while running, open examplecliprogram.exe with "--exampleparameter --exampleparameter2" as cli input, wait for examplecliprogram.exe to terminate, and then take the output and do something useful with it. I would like examplecliprogram.exe to run in the background (instead of being opened in another window) while the output from examplecliprogram.exe is displayed in the window running the overhead program.
So far I've explored options such as popen(), ShellExecute(), and CreateProcess() but I can't seem to get any of them working properly.
Primarily, I want this program to be able to run independently in a Windows environment, and compatibility with Linux would be a bonus.
edit: I have found one solution by calling system("arguments"). I don't know if this is a good solution that will transfer well to a gui, but at the very least it solves the fundamental problem.
This code runs on Windows and Unix (I tested in Visual Studio, GCC on Cygwin, and GCC on Mac OS X).
I had to use a macro to define popen depending on the platform, because on Windows, the function is _popen, while on other platforms the function name is popen (note the underscore in the former).
#include <stdlib.h>
#include <stdio.h>
/* Change to whichever program you want */
//#define PROGRAM "program.exe --param1 --param2"
#define PROGRAM "dir"
#define CHUNK_LEN 1024
#ifdef _WIN32
#define popen _popen
#define pclose _pclose
#endif
int main(int argc, char **argv) {
/* Ensure that output of command does interfere with stdout */
fflush(stdin);
FILE *cmd_file = (FILE *) popen(PROGRAM, "r");
if (!cmd_file) {
printf("Error calling popen\n");
}
char *buf = (char *) malloc(CHUNK_LEN);
long cmd_output_len = 0;
int bytes_read = 0;
do {
bytes_read = fread(buf + cmd_output_len, sizeof(char), CHUNK_LEN, cmd_file);
cmd_output_len += bytes_read;
buf = (char *) realloc(buf, cmd_output_len + CHUNK_LEN);
} while (bytes_read == CHUNK_LEN);
/* Nul terminate string */
*((char *) buf + cmd_output_len) = '\0';
/* Close file pointer */
pclose(cmd_file);
/* Do stuff with buffer */
printf("%s\n", buf);
/* Free buffer */
free(buf);
return 0;
}
You may want to have a look to this Microsoft example code. It was useful to me.
http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx
I used CreateProcess, unfortunately I can't recommend you anything other than 'carefull reading of msdn' and 'starting from simple and progress to complex'.
As for the portability - if you havent need to use some cross-platform toolkit until now, i wouldnt recommend you to start to use one just because of this. I would recommend you to write some 'start process' wrapper and implement it on each platform by its native way.
The cleanest and most portable way of doing this is to use GLib's g_spawn_sync().
You can find the docs online.
gchar * std_out = NULL;
gchar * std_err = NULL;
gint exit_stat = 0;
const char *argv[] = {"--foo", "123", "--bar", "22323", NULL};
if(!g_spawn_sync (NULL, argv, NULL, NULL, NULL, NULL, &std_out, &std_err, &exit_stat, NULL)){
fprintf(stderr, "Failed to spawn!\n");
};
/* std_out and std_err should now point to the respective output.*/
Related
I have the following C code:
#include <gio/gio.h>
int main(void) {
GSubprocess *process;
gchar *output;
gchar *error;
process = g_subprocess_new(G_SUBPROCESS_FLAGS_STDOUT_PIPE, NULL, "./for.sh", NULL);
g_subprocess_communicate_utf8(process, NULL, NULL, &output, &error, NULL);
g_print("%s", output);
}
and the following bash code:
#!/bin/bash
for i in {1..3}
do
echo "$i"
sleep 1
done
The issue I have with this is that the C code will wait until the bash code (or any other code for that matter) finishes to print its output. And what I'd prefer is to have it printed in real time, line by line.
I have found a solution for this in Python but I don't know how to translate it to C. Any pointers will be appreaciated.
The answer in code is this:
#include <gio/gio.h>
int main(void) {
GSubprocess *process;
GInputStream *stream;
char buffer[4];
process = g_subprocess_new(G_SUBPROCESS_FLAGS_STDOUT_PIPE, NULL, "./for.sh", NULL);
stream = g_subprocess_get_stdout_pipe(process);
while(g_input_stream_read(stream, buffer, sizeof(buffer), NULL, NULL))
g_print("%s", buffer);
return 0;
}
The funny things is that depending on the value of buffer[], the output is correct or accompanied by junk. If I change buffer[4] to buffer[8] I get junk. If I use buffer[12] then it's correct. Weird.
You need to get the stdout pipe from the GSubprocess using g_subprocess_get_stdout_pipe(), and then read from it using g_input_stream_read() (or some other input stream reading function) in a loop until the subprocess exits.
You might want to do the same thing with stderr, but in order to do that you’d need to poll both using a GMainLoop, since you can’t block on reading two streams at once.
Seeing your Python code might allow people to help you with the C translation of it.
On Linux (Raspbian on a Raspberry Pi) I would like to make it so that anything my C application prints using printf is sent back to me in a callback.
(No, I'm not talking about shell redirection with > some_file.txt. I'm talking about a C program making the decision by itself to send stdout (and therefore printf) to a callback within that same program.)
(Yes, I really do want to do this. I'm making a full-screen program using OpenGL and want to present any printf'd text to the user within that program, using my own rendering code. Replacing all printf calls with something else is not feasible.)
I feel like this should be easy. There are variations of this question on StackOverflow already, but none that I could find are exactly the same.
I can use fopencookie to get a FILE* that ends up calling my callback. So far, so good. The challenge is to get stdout and printf to go there.
I can't use freopen because it takes a string path. The FILE* I want to redirect to is not a file on the filesystem but rather just exists at runtime.
I can't use dup2 because the FILE* from fopencookie does not have a file descriptor (fileno returns -1).
The glibc documentation suggests that I can simply reassign stdout to my new FILE*: "stdin, stdout, and stderr are normal variables which you can set just like any others.". This does almost work. Anything printed with fprintf (stdout, "whatever") does go to my callback, and so does any printf that has any format specifiers. However, any call to printf with a string with no format specifiers at all still goes to the "original" stdout.
How can I achieve what I'm trying to do?
PS: I don't care about portability. This will only ever run on my current environment.
#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <assert.h>
#include <stdarg.h>
#include <alloca.h>
#include <string.h>
static ssize_t my_write_func (void * cookie, const char * buf, size_t size)
{
fprintf (stderr, "my_write_func received %d bytes\n", size);
char * copy = (char*) alloca (size + 1);
assert (copy);
copy[size] = 0;
strncpy (copy, buf, size);
fprintf (stderr, "Text is: \"%s\"\n", copy);
fflush (stderr);
return size;
}
static FILE * create_opencookie ()
{
cookie_io_functions_t funcs;
memset (&funcs, 0, sizeof (funcs));
funcs.write = my_write_func;
FILE * f = fopencookie (NULL, "w", funcs);
assert (f);
return f;
}
int main (int argc, char ** argv)
{
FILE * f = create_opencookie ();
fclose (stdout);
stdout = f;
// These two DO go to my callback:
fprintf (stdout, "This is a long string, fprintf'd to stdout\n");
printf ("Hello world, this is a printf with a digit: %d\n", 123);
// This does not go to my callback.
// If I omit the fclose above then it gets printed to the console.
printf ("Hello world, this is plain printf.\n");
fflush (NULL);
return 0;
}
This appears to be a bug in GLIBC.
The reason that printf("simple string") works differently from printf("foo %d", 123) is that GCC transforms the former into a puts, with the notion that they are equivalent.
As far as I can tell, they should be equivalent. This man page states that puts outputs to stdout, just like printf does.
However, in GLIBC printf outputs to stdout here, but puts outputs to _IO_stdout here, and these are not equivalent. This has already been reported as a glibc bug (upstream bug).
To work around this bug, you could build with -fno-builtin-printf flag. That prevents GCC from transforming printf into puts, and on my system produces:
$ ./a.out
my_write_func received 126 bytes
Text is: "This is a long string, fprintf'd to stdout
Hello world, this is a printf with a digit: 123
Hello world, this is plain printf.
"
This workaround is of course incomplete: if you call puts directly, or link in object files that call printf("simple string") and were not compiled with -fno-builtin-printf (perhaps from 3rd-party library), then you'll still have a problem.
Unfortunately you can't assign to _IO_stdout (which is a macro). The only other thing you could do (that I can think of) is link in your own puts, which just returns printf("%s", arg). That should work if you are linking against libc.so.6, but may cause trouble if you link against libc.a.
You can redirect to a pipe instead and process the written data in a separate thread.
#include <pthread.h>
#include <ctype.h>
#include <unistd.h>
#include <stdio.h>
// this is the original program which you can't change
void print(void) {
printf("Hello, %d\n", 123);
puts("world");
printf("xyz");
}
int p[2];
void *render(void *arg) {
int nread;
char buf[1];
while((nread = read(p[0], buf, sizeof buf)) > 0) {
// process the written data, in this case - make it uppercase and write to stderr
for(int i = 0; i < nread; i++)
buf[i] = toupper(buf[i]);
write(2, buf, nread);
}
return NULL;
}
int main() {
setvbuf(stdout, NULL, _IONBF, 0);
pipe(p);
dup2(p[1], 1);
close(p[1]);
pthread_t t;
pthread_create(&t, NULL, render, NULL);
print();
close(1);
pthread_join(t, NULL);
}
On debian stretch putting:
setvbuf (f, NULL, _IOLBF, 0); // line buffered
after the create_opencookie call worked.
I was playing with very simple encryption/decryption algorithm like this;
#include <stdio.h>
#include <stdlib.h>
#define BUFFESIZE 1024
int main(int argc, char *argv[]) {
int keylen = 0;
char *key = argv[1];
char *buffer = NULL;
size_t buffersize = 0;
size_t nbytes = 0;
size_t nread;
int i = 0;
while(*key++ != 0) keylen++;
key = argv[1];
do {
buffersize+=BUFFESIZE;
buffer = realloc(buffer, buffersize);
nread = fread(buffer+nbytes, 1, BUFFESIZE, stdin);
nbytes+=nread;
} while (nread > 0);
for(i=0; i<nbytes; i++) {
putchar(buffer[i] ^ key[i % keylen]);
}
return 0;
}
Encyption key is the first command-line argument to the program. I expect that this should get me originial file when encrypted/decrypted with same key. However, I sometimes get only small amount of the file back if I encrypt/decrypt it. My guess is that algorithm adds EOF control character in the middle of file.
How can I get around this problem?
I compiled this using MinGW gcc 4.8.1 on windows XP. If you're interested, you can find a sample input file demonstrating the problem in the edit history of this question.
Well, your code works for me on Linux (compiled with GCC 4.8.2), even using your sample input and key. This suggests that the issue is specific to Windows — most likely, that it's caused by stdin and stdout being in text mode by default. (On Linux and other Unix-ish systems, there's usually no difference between text mode and binary mode, so such issues do not show up there.)
To fix it, you will need to set stdin and stdout to binary mode. The standard way of doing this, as of C99, would be:
freopen(NULL, "rb", stdin);
freopen(NULL, "wb", stdout);
but alas, according to the answers in the thread I linked to above, the Windows C library does not support this C99 feature, so you'll need to fall back on the non-standard _setmode() instead:
_setmode(_fileno(stdin), _O_BINARY);
_setmode(_fileno(stdout), _O_BINARY);
If you want to remain portable, you could always use some conditional code, e.g. like this (warning: not actually tested on Windows!):
#if __STDC_VERSION__ >= 199901L
#define binmode(fh, w) freopen(NULL, ((w) ? "wb" : "rb"), (fh)) /* C99 */
#elif _MSC_VER >= 1200
#include <io.h>
#include <fcntl.h>
#define binmode(fh, w) _setmode(_fileno(fh), _O_BINARY) /* MSVC 6.0+ */
#elif defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
#define binmode(fh, w) /* Unix-ish, just do nothing */
#else
#error Not sure how to define binmode() on this platform
#endif
binmode(stdin, 0);
binmode(stdout, 1);
Or, of course, you could just sidestep the whole issue by opening your own input and output files (in binary mode) instead of using stdin and stdout.
I have a program written in Linux in C, and it works well on Linux platform, but it doesn't work in Windows. It compiles successfully in Windows, using Code Blocks(mingw32-gcc), but it doesn't work as expected, it simply throws an error and kills the program. How can I make it to work on Windows, Please help. This is the code:
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <assert.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
int i, size, k = 2, ftab, sect = 3;
char buf[512];
char vbuf;
int dev, fil_descr, off=0;
fil_descr = open(argv[2], O_RDONLY);
assert(fil_descr > 0);
read(fil_descr, buf, 512);
close(fil_descr);
printf("Bootsector file: %s\n" ,argv[2]);
dev=open(argv[1], O_RDWR);
assert(dev > 0);
write(dev, buf, 512);
ftab = open("filetable", O_CREAT|O_RDWR);
sprintf(buf, "{");
write(ftab, buf, 1);
for(i = 3; i < argc; i++)
{
off = off + (k * 512);
lseek(dev, off, SEEK_SET);
fil_descr=open(argv[i], O_RDONLY);
assert(fil_descr > 0);
size = 0;
while((read(fil_descr, &vbuf, 1))!=0)
{
size++;
write(dev, &vbuf, 1);
}
k = (size > 512)?2:1;
sprintf(buf, "%s-%d," ,argv[i], sect);
write(ftab, buf, strlen(buf));
printf("Input file \'%s\' written at offset %d\n", argv[i], off);
close(fil_descr);
sect = sect + k;
}
sprintf(buf,"}");
write(ftab, buf, 1);
lseek(ftab, 0, SEEK_SET);
read(ftab, buf, 512);
lseek(dev, 512, SEEK_SET);
write(dev, buf, 512);
close (dev);
close(ftab);
}
This is not a C program not working under Windows (although C is the programming language used).
What isn't woking is trying to compile a program using POSIX API functions (such as open, read, write) using a compiler targetting Win32. This includes the use of several headers that don't exist in this environment (which, if they existed, would declare functions that don't exist on the system).
You will either have to use a Unix compatibility layer (Microsoft used to sell that, not sure if they still do, also Cygwin might work), or use proper C, or use native Win32 API functions.
That said, it will also probably not work in the intended way if you switch to using the C standard library I/O funcitons or the native Win32 functions. The output "Bootsector:" suggests that you are trying something that will not work on the system drive at all, and only work with administrative privilegues on another disk.
In order to debug a problem like this, you should add some lines of code helping you to do so.
I changed the respective part of the program to
printf("Bootsector file: %s\n" ,argv[2]);
fil_descr = open(argv[2], O_RDONLY);
if (fil_descr < 0) {
perror("open");
}
printf("fil_descr: %d\n", fil_descr);
assert(fil_descr > 0);
and became aware of the fact that the 2nd command line argument must be a file name of a file to be read.
If I specify it correctly, it works fine.
The 1st file is being written to, and the remaining arguments are file names to be read as well.
Both the headers are linux specific,
#include <sys/types.h>
#include <unistd.h>
On Wi32
I am trying to start a executable who redirects to a filename (current date) e.g. the same as:
Someexecutable.exe > 20101220000000.txt
When I do this from windows cmd.exe everything works fine. However when doing this from my program as shown below the system seems ot either drop the redirect even if it creates the file and/or it seems to buffer a large amount of data before flushing to disk.
I can't change the executable that is being run.
The program beeing executed now only writes to stdout, but remember I can't change this at all. (the simplest way woud be to just do stdout = filehandle; but I that is sadly impossible for me right now!)
(Not required: Also the program waits as system() this is not required but what is the simplest way of detaching the program being run via system() )
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(int argc, char *argv[])
{
char execstr[512];
char s[30];
size_t i;
struct tm tim;
time_t now;
now = time(NULL);
tim = *(localtime(&now));
i = strftime(s,30,"%Y%m%d%H%M",&tim);
sprintf(execstr,"someexecutable.exe > %s.txt",s);
printf("Executing: \"%s\"\n",execstr);
system(execstr);
exit(0);
return 0;
}
I don't see any reason for this to not work, but if this is the case with you, one of the alternative solution could be to use popen and then read from the pipe for writing in the desired file. Here is some sample code which is printing on the screen. You can write that to file instead of screen/console as per your requirement.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(int argc, char *argv[])
{
char execstr[512];
char s[30];
size_t i;
struct tm tim;
time_t now;
char buf[128];
FILE *pipe;
now = time(NULL);
tim = *(localtime(&now));
i = strftime(s,30,"%Y%m%d%H%M",&tim);
#if 0
sprintf(execstr,"a.exe > %s.txt",s);
printf("Executing: \"%s\"\n",execstr);
#endif /* #if 0 */
if( (pipe = _popen("a.exe", "rt")) == NULL )
exit( 1 );
while(!feof(pipe))
{
if (fgets(buf, 128, pipe) != NULL )
printf(buf); /* write to the required file here */
}
_pclose(pipe);
return 0;
}
Your program works fine for me (testing in VS 2010). Some problems you might run into if you're running your tests in the IDE are:
the current directory for the program might not be what you expect it to be (so you might be looking for the output file in the wrong place). By default, the current directory for the program when run in the IDE will be the directory that has the project file (whatever.vcproj or whatever,.vcxproj) - not the directory that has the executable. This can be changed in the project settings.
the IDE's path might not be the same as what you get at a standard command line, so you program might not be finding someexecutable.exe
If you change you program so that the line with the sprintf() call looks like:
sprintf(execstr,"someexecutable.exe",s);
Do you see the output of someexecutable.exe in the console window?