topic C printf code not appearing in Operating System - HP-UX

C printf code not appearing

Curtis Deese — Thu, 14 Oct 2010 14:31:15 GMT

I have a short test C program that uses several printf commands. When I run the program, there is never any output. Why am I not getting any output from the printf statements and how do I resolve the problem?

The program is below:

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

main()
{
char user_id[30];
char password[30];
char server_name[30] ;

strcpy(user_id, "XXX");
strcpy(password, "XXX");
strcpy(server_name, "XXX");

printf("user_id %s\n", user_id);
printf("password %s\n", password);
printf("server_name %s\n", server_name);
Return 0;
}

Re: C printf code not appearing

Dennis Handly — Thu, 14 Oct 2010 14:52:55 GMT

If your output is buffered, you may have to call fflush(3) to get the output to come out immediately.

Other than the typo for "Return" and the lack of int for main, the program seems fine.

What HP-UX version are you using? What architecture? What compiler version?
Still Integrity 11.31?

Re: C printf code not appearing

Curtis Deese — Thu, 14 Oct 2010 15:22:15 GMT

I am using HP-UX 11.31 Integrity. I do not know the compiler version, but I am using cc. The file is a ProC file (test.pc)

Here is the Makefile I am using:

include /u01/app/oracle/product/11.2.0/db_1/precomp/lib/env_precomp.mk

CFLAGS=-D_USE_BIG_FDS -Ae -DHPUX -DORAIA64 -DHPUX_IA64 +DD64 -DSS_64B \
-IT_SERVER -DHPPA64 -DSLS8NATIVE -DSLU8NATIVE +DD64 -DSS_64BIT_SERVER

all: test

test: test.o
$(CC) -o test test.o -L $(LIBHOME) $(PROLDLIBS)

test.o: test.c
$(CC) $(CFLAGS) $(PRECOMPPUBLIC) -c test.c

test.c: test.pc
$(PROC) $(PROCPLSFLAGS) iname=test.pc

clean:
rm -f test.o testlog.o test.c

cleanall: clean
rm -f test

Re: C printf code not appearing

Steven Schweda — Thu, 14 Oct 2010 23:50:35 GMT

> The program is below:
> [...]

That's "test.pc"?

> [...] The file is a ProC file (test.pc)

"The file" is the same as "The program"?

Some of us lack Oracle, making it tough to
see what's happening here. Care to exhibit
"test.c"? (Have _you_ looked at it?)

> [...] I do not know the compiler version,
> but I am using cc. [...]

uname -a
cc -V

> [...] $(LIBHOME) $(PROLDLIBS)

> [...] $(PRECOMPPUBLIC) [...]

Can't see those macros from here, either.

Re: C printf code not appearing

Hein van den Heuvel — Fri, 15 Oct 2010 01:27:59 GMT

KISS.

Reduce, try, expand, retry.
You might be building/running the wrong thing.

Try this.... just feed it into cc and execute a.out
---
#include
#include
main()
{
char user_id[30];

strcpy(user_id, "XXX");

printf("user_id %s\n", user_id);

}

That works right?
Now feed it to pro*c, then cc. ... still works?
Add some switches... still works?
Use the make file.
Check with ls -ltr test.*
Every thing in 'order' and build as expected?

Good luck!

btw... what is 'Return' ? typo?

Re: C printf code not appearing

Dennis Handly — Fri, 15 Oct 2010 02:39:37 GMT

As Steven said, what's in test.c? Does ProC somehow remove your printf calls?

Re: C printf code not appearing

Tom Henning — Mon, 18 Oct 2010 11:07:29 GMT

I will assume that the program compiles and you called the executable 'test'. You are trying to execute the program by typing 'test' from a bourne or ksh shell. If you execute:

type test

it will respond with (at least on my system it does) "test is a shell builtin.". So your program never gets executed. Try running it with: ./test or call it something else.

Re: C printf code not appearing

Curtis Deese — Mon, 18 Oct 2010 11:20:33 GMT

./test worked. I don't know what I was thinking naming the program 'test'. Thanks for your help.

Re: C printf code not appearing

Steven Schweda — Mon, 18 Oct 2010 17:18:07 GMT

> ./test worked. [...]

One of the advantages to showing actual
commands with their actual output is that
other people can see your actual mistakes.
If all you say is that you ran your program,
then many people will assume that you
actually did what you said that you did.
This may force you to wait for someone to
guess what you did (wrong), which is often
not the fastest path to the answer.