how to open stdout

[boss_bhat]

Assume stdout is closed and if i now
want to open stdout, how to open it?

IS this correct way of opening stdout

fopen(stdout,"/dev/null");


Thanks
Prasanna Bhat Mavinkuli

 

[Alexei A. Frounze]

Assume stdout is closed and if i now
want to open stdout, how to open it?

Don't close it. ("Doctor, when I do it it hurts.", "Don't do it.")

IS this correct way of opening stdout

fopen(stdout,"/dev/null");

Oh my goodness...
Alex

 

[boss_bhat]

please somebody explain me how to open STDOUT?

 

[Alexei A. Frounze]

please somebody explain me how to open STDOUT?

It's already open upon entry to main(). Just don't close it and you'll be
OK.

Alex

 

[Igmar Palsenberg]

Assume stdout is closed and if i now
want to open stdout, how to open it?

Don't close it. If it is closed :

int fd;

fd = open("/dev/tty", O_WRONLY);
stdout = fdopen(fd, "w");

This code depends on UNIX, since closing / opening any of the standard
streams is probably undefined

IS this correct way of opening stdout

fopen(stdout,"/dev/null");

Depends. If you actually want to use data send to stdout : no. If you
don't care : yes


Igmar

 

[SM Ryan]

(e-mail address removed) wrote:
# Assume stdout is closed and if i now
# want to open stdout, how to open it?
#
# IS this correct way of opening stdout
#
# fopen(stdout,"/dev/null");

Don't. Use
freopen("/dev/null","w",stdout)
instead.

 

[Lawrence Kirby]

Assume stdout is closed and if i now
want to open stdout, how to open it?

If it is closed you can't portably reopen it in C.

IS this correct way of opening stdout

fopen(stdout,"/dev/null");

No, fopen() takes a pointer to a string specifying a file name as its
first argument, and one specifying a mode as its second.

What you can do is change the file stdout is open to using the freopen()
function:

freopen("/dev/null", "w", stdout)

The 3rd argument must be an existing open stream for this to be valid, so
just make sure you don't close stdout if you want to do this.

Lawrence

 

[Irrwahn Grausewitz]

(e-mail address removed) wrote:
# Assume stdout is closed and if i now
# want to open stdout, how to open it?
#
# IS this correct way of opening stdout
#
# fopen(stdout,"/dev/null");

Don't. Use
freopen("/dev/null","w",stdout)
instead.

1. I know of several systems that don't know anything about /dev/null.

2. On the ones that do, writing to /dev/null is usually not the same
as writing to whatever-stdout-happened-to-point-to on program
startup.

3. Calling freopen with a third parameter that does not currently
point to a stream invokes undefined behaviour (AFAIK).

To OP:
Simply don't close stdout, if you want to make further use of it.

Best regards

 

[Kenneth Brody]

It's already open upon entry to main(). Just don't close it and you'll be
OK.

And if you need to associate stdout with something else for whatever
reason, check out freopen().

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

Don't close it. If it is closed :

int fd;

fd = open("/dev/tty", O_WRONLY);
stdout = fdopen(fd, "w");

stdout isn't an l-value.

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Igmar Palsenberg]

stdout isn't an l-value.

Depends. On this system, it is. On systems where stdout is a macro,
you're in trouble. If that's the case : stick with freopen()


Igmar

 

[SM Ryan]

# >[email protected] wrote:
# ># Assume stdout is closed and if i now
# ># want to open stdout, how to open it?
# >#
# ># IS this correct way of opening stdout
# >#
# ># fopen(stdout,"/dev/null");
-----------
# >
# >Don't. Use
# > freopen("/dev/null","w",stdout)
-----------
# >instead.
#
# 1. I know of several systems that don't know anything about /dev/null.
---------

Apparently it meant something to the original poster.
If he had used "[15,4]:kumquat.rfd", I would've copied
"[15,4]:kumquat.rfd" whether I use RMS or not.

# 2. On the ones that do, writing to /dev/null is usually not the same
# as writing to whatever-stdout-happened-to-point-to on program
# startup.

The original poster didn't want to write to whatever-stdout-happened-to-point-to.

# 3. Calling freopen with a third parameter that does not currently
# point to a stream invokes undefined behaviour (AFAIK).

Hence the whole "Don't [fclose stdout and fopen again]."

"I hate when you mortals need all the details spelled out."

 

[Irrwahn Grausewitz]

Irrwahn Grausewitz <[email protected]> wrote:

# 1. I know of several systems that don't know anything about /dev/null.

Apparently it meant something to the original poster.
If he had used "[15,4]:kumquat.rfd", I would've copied
"[15,4]:kumquat.rfd" whether I use RMS or not.

Which would not have been the "correct way of opening stdout", too.
Well, at least in the realm of comp.lang.c.

# 2. On the ones that do, writing to /dev/null is usually not the same
# as writing to whatever-stdout-happened-to-point-to on program
# startup.

The original poster didn't want to write to whatever-stdout-happened-to-point-to.

Umm. I cannot tell, he neither claimed he wanted, nor the opposite.

"I hate when you mortals need all the details spelled out."

"I hate it when people use the least appropriate quoting character
in a C language group."

Best regards

 

[Kenneth Brody]

Depends. On this system, it is. On systems where stdout is a macro,
you're in trouble. If that's the case : stick with freopen()

"It may be an l-value on some systems" == "It's not a l-value as far as
clc is concerned".

Of course, one could make a similar argument about "/dev/tty".

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Walter Roberson]

Kenneth Brody wrote:

Depends. On this system, it is. On systems where stdout is a macro,
you're in trouble.

C89 -defines- stdout as being a macro.

It might happen that the expansion of the macro gives you something
that could be used as an l-value, but you shouldn't count on that.

A common Unix value for stdout is the local equivilent of &__iob[1]

 

[SM Ryan]

# <snip>
# ># 1. I know of several systems that don't know anything about /dev/null.
# >
# >Apparently it meant something to the original poster.
# >If he had used "[15,4]:kumquat.rfd", I would've copied
# >"[15,4]:kumquat.rfd" whether I use RMS or not.
#
# Which would not have been the "correct way of opening stdout", too.
# Well, at least in the realm of comp.lang.c.

You just keep digging yourself deeper in a hole. You've snipped the part
where you piddle all over yourself, so it's not clear whether you think
an RMS file name is somehow more an ANSI C than a Unix one. Or whether
you don't know that freopen is ANSI C.

# ># 2. On the ones that do, writing to /dev/null is usually not the same
# ># as writing to whatever-stdout-happened-to-point-to on program
# ># startup.
# >
# >The original poster didn't want to write to whatever-stdout-happened-to-point-to.

Perhaps you could conclude that from his closing and reopening stdout.
Generally speaking, people who close files don't expect them to remain open.

# Umm. I cannot tell, he neither claimed he wanted, nor the opposite.

Actually you're trying to chase me out of comp.lang.c.


# "I hate it when people use the least appropriate quoting character
# in a C language group."

Want some cheese with that whine?

 

[Irrwahn Grausewitz]

# SM Ryan <[email protected]> wrote:

# >If he had used "[15,4]:kumquat.rfd", I would've copied
# >"[15,4]:kumquat.rfd" whether I use RMS or not.
#
# Which would not have been the "correct way of opening stdout", too.
# Well, at least in the realm of comp.lang.c.

You just keep digging yourself deeper in a hole. You've snipped the part
where you piddle all over yourself, so it's not clear whether you think
an RMS file name is somehow more an ANSI C than a Unix one.

I cannot find any mention of specific file names in the standard.
What would make a file name "more an ANSI C one"? C&V, please.

Or whether
you don't know that freopen is ANSI C.

If I wouldn't know I would've told you already.

# ># 2. On the ones that do, writing to /dev/null is usually not the same
# ># as writing to whatever-stdout-happened-to-point-to on program
# ># startup.
# >
# >The original poster didn't want to write to whatever-stdout-happened-to-point-to.

Perhaps you could conclude that from his closing and reopening stdout.

My crystal ball is broken. Too bad.

Generally speaking, people who close files don't expect them to remain open.

People who close a file associated with a standard stream should not
expect to get any other file successfully opened and associated to
that stream, not even using freopen. Your call to freopen might leave
you standing in the rain with only a closed stdout to cover your head.

Actually you're trying to chase me out of comp.lang.c.

Huh?!? Actually, I'm trying to take over the whole abusenet and sell
it to MS. :>

<snip>