problem running a C program in the cygwin shell in Win XP

[Amy N.]

Hi,

I just installed cygwin on Windows XP. I used Visual Studio to compile a test
C program. If I were at the shell in cygwin, and typed this command:

$ date > tmp_file

The content of the file tmp_file in that directory would look something like this:

Mon Jul 27 01:22:25 PDT 2009

So when I compiled my program that looks something like below, and ran the .exe file at the prompt at the cygwin shell, the "date" command executes, the "tmp_file" got created with the correct info, but the C program hangs. I have to press <RETURN> for the program to end.

What causes this, and how do I fix this problem? Thanks.

Here's the samle of that command in the C function:

system ("date > tmp_file");

[Amy N.]

It looks like it's not the UNIX commands that are causing the problem.

If I type the Windows commands, I still have the same problem.

I think that my syntax for the system command is not correct.

[slingerland3g]

Well with gcc alone, this works on my WinXP with Cygwin. By any chance are you calling getchar() at all?

In Netbeans, I get what you get, without that, then I have to hit return to exit. My date_file is created as expected.

[Salem]

date is both a cygwin command and a DOS command.

The cygwin one just prints the date.
The DOS one prints the current date, and prompts you for a new date. Pressing return just accepts the old date.

[slingerland3g]

Then running this within a cygwin shell you should be fine.

[Amy N.]

OK, I just changed it to something else, like:

system ("ls -l > tmp_file");



The same problem occurred. The compiled program hangs when it reaches this command. To make it continue, I have to press <RETURN>. It looks like the system command is waiting for a key to be pressed by the user, before it can continue in the C program.

What do I need to do in my C program, so that it thinks that a <RETURN> was pressed, so that it can continue?

[slingerland3g]

I believe your <RETURN> is to exit out of your IDE, if that is the environment you ran your program in. Do you get this same behaviour when you execute your .exe from the command line?