From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.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.
0x0d 0x0a changes and corrupted".
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.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.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.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.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.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 27 Mar 2021 17:48:25 +0300
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.
The archived file is binary not a text, although unrar might have screwed up.
The archived file is binary not a text, although unrar might have screwed
up.
If "unrar -p" is supposed to output the archived file to stdout, then
unrar should do that in binary mode; if it doesn't, that's a bug
(possibly in the DOS port).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 344 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 38:26:10 |
| Calls: | 7,524 |
| Files: | 12,713 |
| Messages: | 5,643,198 |