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:02:13 +0300 Message-Id: <83o8f4oftm.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: 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 16:39:08 +0300 > > The code is basically: > > p = popen(cmdline, "rb"); > while ((n = fread(buf, 1, BUFLEN, p)) > 0) { > fwrite(buf, 1, n, t); > } > pclose(p); > > ... where cmdline is like "unrar p -inul ponylips.rar". The "p" makes > unrar to extract to stdout, -inul makes unrar to emit no messages. > > The issue is: Whatever I do, including inserting calls like > setmode(fileno(stdout),O_BINARY), extracted file has 0x0a -> 0x0d 0x0a > changes and corrupted. For what it's worth, manually running that cmd > on the console itself, like "unrar p -inul ponylips.rar > ponylips.mod" > gives the same result. I don't think I understand what you mean by "extracted file has 0x0a -> 0x0d 0x0a changes and corrupted". 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 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.