X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	"Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: setmode
Date:	Sat, 4 Apr 2009 03:34:38 -0400
Organization:	Aioe.org NNTP Server
Lines:	64
Message-ID:	<gr72bt$tjk$1@aioe.org>
References:	<gr3fv1$s9f$1 AT aioe DOT org> <uk561j05t DOT fsf AT gnu DOT org>
NNTP-Posting-Host:	pldq+kT97bAAp/ObDwnZyQ.user.aioe.org
X-Complaints-To:	abuse AT aioe DOT org
NNTP-Posting-Date:	Sat, 4 Apr 2009 07:31:09 +0000 (UTC)
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1933
X-Notice:	Filtered by postfilter v. 0.7.7
X-Newsreader:	Microsoft Outlook Express 6.00.2800.1933
Cancel-Lock:	sha1:0huNeHqiMoD98q2F8l+Aab29pGA=
X-Priority:	3
X-MSMail-Priority:	Normal
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Eli Zaretskii" <eliz AT gnu DOT org> wrote in message
news:uk561j05t DOT fsf AT gnu DOT org...
> > From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
>
> Redirecting stdout explicitly affects file
> descriptor 1 which was inherited from the parent shell, and `freopen'
> closes that descriptor.

That was why I tried reopening the console device, "CON", as the redirected
stdout in one of the examples.

> The new FILE object reuses the same file
> descriptor 1, but the redirection is lost when the original descriptor
> is closed, because the redirection is maintained by the OS, which is
> told that the file is closed.
...
> redirection is maintained by the OS

Time for me to try to find out more about this, I guess...  Of course, the
question becomes: Why would freopen() close or attempt to close stdin,
stdout, stderr?  I haven't looked at what the C spec. says here, but I'm
fairly sure Harbison & Steele 3rd ed. says file closing errors in freopen()
are ignored.  If correct, that would allow file close errors in freopen() by
design or intentionally for stdin, stdout, stderr.

> Why isn't using `setmode' good enough?  That's what all applications
> that need this do.

It is.  It works.  I use it enough.  But, I was really wanting ANSI C only
in this case.  And, when I thought about it, I saw no reason why freopen()
shouldn't work the same way...  Then, I skimmed the code and saw that
freopen() eventually called setmode().  That opened up the possibility that
freopen() could or might work the same way, or have a some method available
allowing it to work like setmode.   I haven't looked at it thoroughly, but I
do recall it clearing O_BINARY, although you indicated above that really
isn't the issue.

> Just be careful not to switch stdout to binary if
> it is not redirected,

Actually, I've found switching the console to binary to be quite useful.

> since switching the console device to binary has
> some unpleasant side effects in DJGPP: e.g., SIGINT is not produced by
> Ctrl-C.

Interesting...  Does this block Ctrl-C better than signal() to SIG_IGN on
SIGINT, SIGQUIT, SIGABRT inconjunction with setcbrk()?  This came up a while
ago in comp.os.msdos.programmer.  Unfortunately, it seems he never posted to
comp.os.msdos.djgpp.  My solution apparently didn't work for him.  Later, I
found out that it worked well for some of my applications, but it doesn't
work well for every application...  Some still leak large numbers of
ctrl-c's.
http://groups.google.com/group/comp.os.msdos.programmer/browse_thread/thread/98a6c66a3aa291ae/c83696ed4bae0310?hl=en

>     if (!isatty (fileno (stdout)))
>       setmode (fileno (stdout), O_BINARY);

Hmm...  Time to look at isatty().


Rod Pemberton

- Raw text -