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]

<bo*******@yahoo.co.in> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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]

<bo*******@yahoo.co.in> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

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]

bo*******@yahoo.co.in wrote:

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

[Lawrence Kirby]

On Thu, 08 Sep 2005 00:01:41 -0700, boss_bhat wrote:

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

[SM Ryan]

bo*******@yahoo.co.in 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
She broke your heart and inadvertently drove men to deviant lifestyles.

[Irrwahn Grausewitz]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

bo*******@yahoo.co.in 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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Kenneth Brody]

"Alexei A. Frounze" wrote:

<bo*******@yahoo.co.in> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

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.

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:Th*************@gmail.com>

[Kenneth Brody]

Igmar Palsenberg wrote:

bo*******@yahoo.co.in wrote:

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");

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:Th*************@gmail.com>

[Igmar Palsenberg]

Kenneth Brody wrote:

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.

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]

Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >bo*******@yahoo.co.in 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."

--
SM Ryan http://www.rawbw.com/~wyrmwif/
If your job was as meaningless as theirs, wouldn't you go crazy too?

[Irrwahn Grausewitz]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote: <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.
# 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.

<snip>
"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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Walter Roberson]

In article <43***********************@news.xs4all.nl>,
Igmar Palsenberg <ig***@jdimedia.local> wrote:

Kenneth Brody wrote:

stdout isn't an l-value.

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]
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

[Kenneth Brody]

Igmar Palsenberg wrote:

Kenneth Brody wrote:

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.

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:Th*************@gmail.com>

[SM Ryan]

Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# <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?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Quit killing people. That's high profile.

[Irrwahn Grausewitz]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote: <snip># >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.

<snip>
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>
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.