X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" 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: References: 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" wrote in message news:uk561j05t DOT fsf AT gnu DOT org... > > From: "Rod Pemberton" > > 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