X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Date: Sat, 27 Mar 2021 17:26:21 +0300 Message-Id: <83mtuooepe.fsf@gnu.org> From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" To: djgpp AT delorie DOT com In-Reply-To: (djgpp AT delorie DOT com) Subject: Re: issue with popen and reading from stdout References: <83o8f4oftm DOT fsf AT gnu DOT org> Reply-To: djgpp AT delorie DOT com > From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" > Date: Sat, 27 Mar 2021 17:18:20 +0300 > > > The above program's expected effect is to read what "unrar -p" emits > > without any EOL conversions. Programs that run on MS-DOS/Windows > > usually output CRLF end-of-line sequences (i.e. 0x0d + 0x0a), so the > > program you show should: > > > > . read these CRLF EOLs without any conversion > > . write each line to stdout > > OK, so it's possibly an issue with unrar itself You expected unrar to produce lines with a single 0x0a at the end of each line? That's extremely unusual with DOS/Windows programs. > > Whether 'fwrite' add another 0x0d to each line depends on the mode of > > the stream 't'; if you open it in binary mode, I would expect to see > > the same CRLF EOLs as what "unrar -p" emits. If 't' is in text mode, > > you will see each line end with 0x0d 0x0d 0x0a, i.e. 2 CR characters > > followed by a single newline. > > It's opened with "w+b" mode, like: > fd = mkstemp(*filename); > t = fdopen(fd, "w+b"); Then you should expect to see the CRLF end of line in the temporary file, I think.