Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #395686 > unrolled thread
| Started by | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| First post | 2025-12-06 01:05 +0000 |
| Last post | 2025-12-17 00:52 -0600 |
| Articles | 20 on this page of 119 — 23 participants |
Back to article view | Back to comp.lang.c
is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-06 01:05 +0000
Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 01:41 +0000
Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 02:00 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:40 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:35 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 15:07 +0000
Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-10 19:00 +0200
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 17:18 +0000
Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-10 19:42 +0000
Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-10 22:37 +0000
Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-10 22:35 -0500
Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-11 11:46 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-11 12:53 +0100
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:42 +0000
Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-10 15:58 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:44 +0000
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-10 12:46 -0500
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:45 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:41 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 20:57 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 22:07 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-11 01:09 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-11 12:33 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-12 19:25 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-12 22:54 +0000
Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 15:33 -0800
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-13 00:20 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-13 02:32 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-16 00:26 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-16 17:24 +0100
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-17 03:19 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-17 07:57 +0100
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-17 19:35 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 08:44 +0100
Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-18 12:49 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 14:06 +0100
Re: is_binary_file() gazelle@shell.xmission.com (Kenny McCormack) - 2025-12-18 13:17 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 16:03 +0100
Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-05 17:42 -0800
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:37 +0000
Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-06 16:05 -0800
Re: is_binary_file() Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2025-12-07 03:43 -0700
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-07 16:47 +0000
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 03:18 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:46 +0000
Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-06 02:42 +0000
Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-06 12:42 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:40 +0000
Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 18:04 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 19:06 +0000
Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 21:16 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:48 +0000
Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-08 19:26 +0000
Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-08 19:42 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 21:49 +0000
Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-06 03:14 -0500
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:56 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 20:16 +0000
Re: is_binary_file() David Brown <david.brown@hesbynett.no> - 2025-12-09 09:03 +0100
Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-09 09:43 +0000
Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-09 10:17 +0000
Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:15 +0000
Re: is_binary_file() tTh <tth@none.invalid> - 2025-12-09 12:22 +0100
Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-09 20:26 -0500
Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-09 06:38 -0500
Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-09 17:31 +0200
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 02:49 +0000
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 00:12 +0000
Re: is_binary_file() richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-12-28 00:43 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:33 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-07 19:04 +0100
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-06 20:37 -0500
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:02 +0000
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-09 16:29 -0500
Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-10 11:21 +0200
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-10 12:48 -0500
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:38 +0000
Re: is_binary_file() antispam@fricas.org (Waldek Hebisch) - 2025-12-07 03:43 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:04 +0000
Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-08 18:44 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 19:53 +0000
Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 15:42 -0800
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:41 +0000
Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-10 15:20 -0800
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 23:59 +0000
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-09 16:23 -0500
Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-07 19:01 +0000
Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-07 21:51 +0000
Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-07 22:49 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 13:51 +0100
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 16:04 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 19:27 +0100
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 05:51 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-29 16:06 +0100
Re: is_binary_file() mjos_examine <m6502x64@gmail.com> - 2025-12-29 11:49 -0500
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-29 20:49 +0100
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-30 01:52 +0000
Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 16:02 +0000
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:07 +0000
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 03:13 +0000
Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-27 01:28 -0500
Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 21:27 +0000
Re: is_binary_file() antispam@fricas.org (Waldek Hebisch) - 2025-12-28 05:46 +0000
Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 14:42 -0800
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:09 +0000
Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-09 12:45 -0800
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 20:36 +0100
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 20:50 +0100
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-09 15:09 +0100
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-10 09:18 +0100
Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-08 14:43 -0800
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 21:38 +0000
Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-11 17:33 +0000
Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-11 19:10 +0100
Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 14:56 -0800
Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-11 18:15 -0500
Re: is_binary_file() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-12 02:19 +0100
Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-14 08:27 +0000
Re: is_binary_file() Lynn McGuire <lynnmcguire5@gmail.com> - 2025-12-17 00:52 -0600
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2025-12-09 10:17 +0000 |
| Message-ID | <10h8svl$o52a$1@dont-email.me> |
| In reply to | #395732 |
On 09/12/2025 09:43, Richard Heathfield wrote: > ly - Lilypond source Off topic, but ... Lilypond is a lovely thing :)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2025-12-09 20:15 +0000 |
| Message-ID | <20251209121320.313@kylheku.com> |
| In reply to | #395733 |
On 2025-12-09, Richard Harnden <richard.nospam@gmail.invalid> wrote: > On 09/12/2025 09:43, Richard Heathfield wrote: > >> ly - Lilypond source > > Off topic, but ... Lilypond is a lovely thing :) Some fifteen years ago, I banged up this in it: https://www.kylheku.com/~kaz/Prelude.pdf (Change "pdf" to "mid" for MIDI.) I imagine it must have improved quite a bit since then. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-12-09 12:22 +0100 |
| Message-ID | <10h90pd$n2g$1@news.gegeweb.eu> |
| In reply to | #395731 |
On 12/9/25 09:03, David Brown wrote:
> But surely on Windows you can just look at the file extension - if it is
> ".txt", it's a text file, otherwise it's a binary file.
And what about PNM files who can be pure ascii encoded,
but was image files ?
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-09 20:26 -0500 |
| Message-ID | <10hai8o$17eg9$1@dont-email.me> |
| In reply to | #395734 |
On Tue, 12/9/2025 6:22 AM, tTh wrote:
> On 12/9/25 09:03, David Brown wrote:
>
>> But surely on Windows you can just look at the file extension - if it is ".txt", it's a text file, otherwise it's a binary file.
>
> And what about PNM files who can be pure ascii encoded,
> but was image files ?
>
teapot.ppm 196,623 bytes
50 36 0A 32 35 36 20 32 35 36 0A 32 35 35 0A # P6
# 256 256
# 255
13 5C C0 13 5C C0 13 5C C0 13 5C C0 13 5C C0 # binary byte tuples 0x13 0x5C 0xC0
******************************************************************
teapot2.ppm 710,359 bytes
P3 # P3 is the ASCII format option
# Created by IrfanView # (How you change storage formats)
256 256
255
19 92 192 19 92 192 19 92 192 19 92 192 19 92 192 # Plain ASCII digits (inefficient)
PNM supports both ASCII and binary payloads.
The magic value of P3 or P6 indicates the PPM payload types in the examples.
********************************************************************
$ file *ppm
teapot.ppm: Netpbm image data, size = 256 x 256, rawbits, pixmap
teapot2.ppm: Netpbm image data, size = 256 x 256, pixmap, ASCII text
Paul
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-09 06:38 -0500 |
| Message-ID | <10h91o9$pkgv$1@dont-email.me> |
| In reply to | #395731 |
On Tue, 12/9/2025 3:03 AM, David Brown wrote:
> On 08/12/2025 21:16, Scott Lurndal wrote:
>> Michael Sanders <porkchop@invalid.foo> writes:
>>> On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote:
>>>
>>>> It is the year 2025.
>>>>
>>>> How many times do you suppose someone has considered this question ?
>>>>
>>>> I'm not trying to be a smart ass by saying this, just that the
>>>> question is bound to be nuanced. You can do a fast and totally
>>>> inaccurate determination. You can do a computationally expensive
>>>> or I/O expensive determination.
>>>
>>> I get it Paul, but as with all things, there's lots of opinions on this.
>>>
>>>> There has to be a reason for doing this, and a damn good reason.
>>>>
>>>> *******
>>>>
>>>> There is the "file" command.
>>>>
>>>> It was invented in 1973.
>>>>
>>>> https://en.wikipedia.org/wiki/File_%28command%29
>>>>
>>>> The beauty of this command, is it has some sort of ordered
>>>> approach to file determination.
>>>
>>> And... is not generally available on Windows
>>
>> It is open source and could be built for windows.
>>
>> It's also included in any linux distribution running
>> under WSL.
>>
>
> It is available anywhere you find Windows ports of common *nix utilities, such as the msys2 project. (And while an msys2 installation can be quite large, it's possible to pull out individual utilities if you need to.) Still, it's fair to say that most Windows installations don't have it.
>
> But surely on Windows you can just look at the file extension - if it is ".txt", it's a text file, otherwise it's a binary file.
There are a couple ways to get it.
The problem with this one, is /etc/magic is as old as the hills
and does not have nearly as much capability. On the plus side,
it's not going to burn your house down either.
https://gnuwin32.sourceforge.net/packages/file.htm
A second source, is Cygwin, but again, it might depend on
when the port was done. Doing it this way has to be better
than the previous link, just because the previous one is
so old.
https://cygwin.com/packages/summary/file.html
And the Wiki on msys2 says this:
"MSYS2 ("minimal system 2") is a software distribution and a
development platform for Microsoft Windows, based on Mingw-w64 and Cygwin
"
It still means when the release was done, could matter.
I started with Cygwin64. This is an example of an executable, but
it relies on other dependencies.
https://mirror.csclub.uwaterloo.ca/cygwin/x86_64/release/file/file-5.46-1-x86_64.tar.xz
The installer is here.
https://cygwin.com/setup-x86_64.exe
# After installation, I checked the dependencies. This does not
# help you find the /etc/magic file for its usage.
$ cygcheck /usr/bin/file.exe
C:\cygwin64\bin\file.exe
C:\cygwin64\bin\cygmagic-1.dll
C:\cygwin64\bin\cygbz2-1.dll
C:\cygwin64\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
C:\cygwin64\bin\cyglzma-5.dll
C:\cygwin64\bin\cygz.dll
C:\cygwin64\bin\cygzstd-1.dll
Testing did not go well. I tested the "find.exe" in Cygwin64
and it did not finish. I used Process Monitor to see what it
was doing, and there was a lot of registry activity. (There
should not be registry activity by find.exe or file.exe )
I tried the file.exe command and it didn't provide output
and the machine hung. My machine never hangs. It's a model
citizen. Windows Defender did not trip. An offline scan
with Windows Defender did not find anything. This is possibly
Process Monitor using all RAM, but that does not normally
happen until 20 minutes or more have passed, and I was only
running tracing for a minute or two.
Cygwin materials are held on mirror sites, and I was using
a mirror (University of Waterloo). For the time being, I would
recommend some isolation while you test that.
*******
On to msys2.
https://www.msys2.org/
Name: msys2-x86_64-20250830.exe
Size: 93,680,251 bytes (89 MiB)
SHA256: B54705073678D32686A2CC356BB552363429E6CCBABBFECCB6D3CB7EC101E73B
"Last analysis 22 hours ago", so it is likely someone in this thread triggered a retest.
https://www.virustotal.com/gui/file/b54705073678d32686a2cc356bb552363429e6ccbabbfeccb6d3cb7ec101e73b [Clean]
Install on disk is 350MB in C:\msys64
https://www.msys2.org/docs/installer/
C:/msys64/msys2_shell.cmd -defterm -here -no-start -ucrt64 # Do not run elevated (use the unelevated terminal)
# Windows Terminal prompt changes color
$ cd /c/msys64/usr/bin
$ file.exe file.exe
file.exe: PE32+ executable for MS Windows 5.02 (console), x86-64 (stripped to external PDB), 10 sections
$ cd /s/disktype
$ file disktype.exe
disktype.exe: PE32 executable for MS Windows 4.00 (console), Intel i386, 16 sections # cygwin32 executable?
# I change directory to the corrupted Sent file and check it with the msys2 version.
$ file Sent
Sent: Mailbox text, 1st line "From - Wed Nov 26 06:13:35 2008"
# I compare to the WSL file command
$ file Sent
Sent: Non-ISO extended-ASCII text, with very long lines, with CRLF, NEL line terminators # The corruption detection...
This tells me the msys2 has an older version of magic determination on the file.exe command .
And for the cygwin64, use the rubber gloves on it.
It did not work as expected. Use your SafeHex handling
techniques, until it proves in for you.
Paul
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-09 17:31 +0200 |
| Message-ID | <20251209173109.00000a32@yahoo.com> |
| In reply to | #395735 |
On Tue, 9 Dec 2025 06:38:47 -0500
Paul <nospam@needed.invalid> wrote:
> On Tue, 12/9/2025 3:03 AM, David Brown wrote:
> > On 08/12/2025 21:16, Scott Lurndal wrote:
> >> Michael Sanders <porkchop@invalid.foo> writes:
> >>> On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote:
> >>>
> >>>> It is the year 2025.
> >>>>
> >>>> How many times do you suppose someone has considered this
> >>>> question ?
> >>>>
> >>>> I'm not trying to be a smart ass by saying this, just that the
> >>>> question is bound to be nuanced. You can do a fast and totally
> >>>> inaccurate determination. You can do a computationally expensive
> >>>> or I/O expensive determination.
> >>>
> >>> I get it Paul, but as with all things, there's lots of opinions
> >>> on this.
> >>>> There has to be a reason for doing this, and a damn good reason.
> >>>>
> >>>> *******
> >>>>
> >>>> There is the "file" command.
> >>>>
> >>>> It was invented in 1973.
> >>>>
> >>>> https://en.wikipedia.org/wiki/File_%28command%29
> >>>>
> >>>> The beauty of this command, is it has some sort of ordered
> >>>> approach to file determination.
> >>>
> >>> And... is not generally available on Windows
> >>
> >> It is open source and could be built for windows.
> >>
> >> It's also included in any linux distribution running
> >> under WSL.
> >>
> >
> > It is available anywhere you find Windows ports of common *nix
> > utilities, such as the msys2 project. (And while an msys2
> > installation can be quite large, it's possible to pull out
> > individual utilities if you need to.) Still, it's fair to say that
> > most Windows installations don't have it.
> >
> > But surely on Windows you can just look at the file extension - if
> > it is ".txt", it's a text file, otherwise it's a binary file.
>
> There are a couple ways to get it.
>
> The problem with this one, is /etc/magic is as old as the hills
> and does not have nearly as much capability. On the plus side,
> it's not going to burn your house down either.
>
> https://gnuwin32.sourceforge.net/packages/file.htm
>
> A second source, is Cygwin, but again, it might depend on
> when the port was done. Doing it this way has to be better
> than the previous link, just because the previous one is
> so old.
>
> https://cygwin.com/packages/summary/file.html
>
> And the Wiki on msys2 says this:
>
> "MSYS2 ("minimal system 2") is a software distribution and a
> development platform for Microsoft Windows, based on Mingw-w64
> and Cygwin "
>
> It still means when the release was done, could matter.
>
> I started with Cygwin64. This is an example of an executable, but
> it relies on other dependencies.
>
> https://mirror.csclub.uwaterloo.ca/cygwin/x86_64/release/file/file-5.46-1-x86_64.tar.xz
>
> The installer is here.
>
> https://cygwin.com/setup-x86_64.exe
>
> # After installation, I checked the dependencies. This does not
> # help you find the /etc/magic file for its usage.
>
> $ cygcheck /usr/bin/file.exe
> C:\cygwin64\bin\file.exe
> C:\cygwin64\bin\cygmagic-1.dll
> C:\cygwin64\bin\cygbz2-1.dll
> C:\cygwin64\bin\cygwin1.dll
> C:\WINDOWS\system32\KERNEL32.dll
> C:\WINDOWS\system32\ntdll.dll
> C:\WINDOWS\system32\KERNELBASE.dll
> C:\cygwin64\bin\cyglzma-5.dll
> C:\cygwin64\bin\cygz.dll
> C:\cygwin64\bin\cygzstd-1.dll
>
> Testing did not go well. I tested the "find.exe" in Cygwin64
> and it did not finish. I used Process Monitor to see what it
> was doing, and there was a lot of registry activity. (There
> should not be registry activity by find.exe or file.exe )
>
> I tried the file.exe command and it didn't provide output
> and the machine hung. My machine never hangs. It's a model
> citizen. Windows Defender did not trip. An offline scan
> with Windows Defender did not find anything. This is possibly
> Process Monitor using all RAM, but that does not normally
> happen until 20 minutes or more have passed, and I was only
> running tracing for a minute or two.
>
> Cygwin materials are held on mirror sites, and I was using
> a mirror (University of Waterloo). For the time being, I would
> recommend some isolation while you test that.
>
> *******
>
> On to msys2.
>
> https://www.msys2.org/
>
> Name: msys2-x86_64-20250830.exe
> Size: 93,680,251 bytes (89 MiB)
> SHA256:
> B54705073678D32686A2CC356BB552363429E6CCBABBFECCB6D3CB7EC101E73B
>
> "Last analysis 22 hours ago", so it is likely someone in this thread
> triggered a retest.
>
> https://www.virustotal.com/gui/file/b54705073678d32686a2cc356bb552363429e6ccbabbfeccb6d3cb7ec101e73b
> [Clean]
>
> Install on disk is 350MB in C:\msys64
>
> https://www.msys2.org/docs/installer/
>
> C:/msys64/msys2_shell.cmd -defterm -here -no-start -ucrt64 # Do not
> run elevated (use the unelevated terminal) # Windows Terminal prompt
> changes color
>
> $ cd /c/msys64/usr/bin
> $ file.exe file.exe
> file.exe: PE32+ executable for MS Windows 5.02 (console), x86-64
> (stripped to external PDB), 10 sections $ cd /s/disktype
> $ file disktype.exe
> disktype.exe: PE32 executable for MS Windows 4.00 (console), Intel
> i386, 16 sections # cygwin32 executable? # I change directory to
> the corrupted Sent file and check it with the msys2 version. $ file
> Sent Sent: Mailbox text, 1st line "From - Wed Nov 26 06:13:35 2008"
> # I compare to the WSL file command
> $ file Sent
> Sent: Non-ISO extended-ASCII text, with very long lines, with CRLF,
> NEL line terminators # The corruption detection...
>
Below is the list of files that I needed to run copy of file.exe
taken from msys2 on bare Windows:
Directory of C:\tmp\tst
12/09/2025 05:00 PM <DIR> .
12/09/2025 04:53 PM <DIR> ..
12/09/2025 04:54 PM 24,225 file.exe
12/09/2025 05:00 PM 10,357,200 magic.mgc
12/09/2025 04:57 PM 3,358,337 msys-2.0.dll
12/09/2025 04:58 PM 67,277 msys-bz2-1.dll
12/09/2025 04:58 PM 176,762 msys-lzma-5.dll
12/09/2025 04:57 PM 160,362 msys-magic-1.dll
12/09/2025 04:59 PM 88,576 msys-z.dll
12/09/2025 04:58 PM 1,136,580 msys-zstd-1.dll
8 File(s) 15,369,319 bytes
2 Dir(s) 760,461,594,624 bytes free
It's still less convenient than running from msys2 prompt, because
by default file.exe does not look for magic.mgc in the current
directory. So I had to run it as
'file.exe --magic-file magic.mgc my-files'
Can be "solved" by small envelop batch file, unless it creates some
other inconvenience.
> This tells me the msys2 has an older version of magic determination
> on the file.exe command .
>
> And for the cygwin64, use the rubber gloves on it.
> It did not work as expected. Use your SafeHex handling
> techniques, until it proves in for you.
>
> Paul
I never tried cygwin64. For what I do, the level of compatibility
provided by msys2 is sufficient.
I do have misfortune of using old cygwin, because it's how
Altera (then Intel then again Altera) packages their Nios2 SDK. During
the years it (cygwin) suffered from multiple issues caused by usual
malware that IT of our company stubbornly confuses for anti-malware.
The most recent example is Trend Micro virus that they call "antivirus"
that on few installations (but not on all of them) silently deletes some
vital components of cygwin.
Recently I was glad to discover that all components of said SDK that I
care about actually don't need cygwin. They are either proper Windows
exe, or bash, perl and python scripts. They work fine from msys2 prompt
and are actually faster that way than from within cygwin shell.
So now I have grand plan to gradually stop using old cygwin altogether.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-28 02:49 +0000 |
| Message-ID | <10iq5rf$3v50f$2@dont-email.me> |
| In reply to | #395735 |
On Tue, 9 Dec 2025 06:38:47 -0500, Paul wrote: > I tested the "find.exe" in Cygwin64 and it did not finish. I used > Process Monitor to see what it was doing, and there was a lot of > registry activity. (There should not be registry activity by > find.exe or file.exe ) You’ve got the source code, you can see where that’s coming from. If it’s not coming from the Cygwin code, it’s something in Windows itself. > I tried the file.exe command and it didn't provide output and the > machine hung. My machine never hangs. It's a model citizen. Windows > Defender did not trip. An offline scan with Windows Defender did not > find anything. That sort of thing seems par for the course with Windows ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-28 00:12 +0000 |
| Message-ID | <10ipsm4$3ssi3$5@dont-email.me> |
| In reply to | #395691 |
On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote: > .. with CRLF, NEL line terminators Who uses NEL? Only IBM, as far as I know. Also, the only difference between XML 1.0 and XML 1.1 is that the latter adds NEL as a permitted line terminator.
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2025-12-28 00:43 +0000 |
| Message-ID | <10ipuf0$1btn5$1@artemis.inf.ed.ac.uk> |
| In reply to | #396001 |
In article <10ipsm4$3ssi3$5@dont-email.me>, Lawrence DÿOliveiro <ldo@nz.invalid> wrote: >Also, the only difference between XML 1.0 and XML 1.1 is that the >latter adds NEL as a permitted line terminator. There are some differences concerning control characters too. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-12-06 17:33 +0000 |
| Message-ID | <oNZYQ.2257$8WR2.262@fx46.iad> |
| In reply to | #395686 |
Michael Sanders <porkchop@invalid.foo> writes: >Am I close? Missing anything you'd consider to be (or not) needed? Technically, there is no such thing as a "binary" file. All files are simply sequences of bytes with no format implied. Interpretation of the file content is purely application dependent. C-based applications have certain restrictions on text format due to the use of the ASCII NUL code as a string terminator, but that's C. The content of a text file processed by a different language, or by C using application-defined string containers can easily contain a NUL byte yet still be considered "text" if that distinction is necessary. Because of C/C++, a valid UTF-8 encoding will not include the NUL byte.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-12-07 19:04 +0100 |
| Message-ID | <10h4fil$3kqd3$1@raubtier-asyl.eternal-september.org> |
| In reply to | #395694 |
Am 06.12.2025 um 18:33 schrieb Scott Lurndal: > Michael Sanders <porkchop@invalid.foo> writes: >> Am I close? Missing anything you'd consider to be (or not) needed? > Technically, there is no such thing as a "binary" file. All files > are simply sequences of bytes with no format implied. Interpretation > of the file content is purely application dependent. > > C-based applications have certain restrictions on text format > due to the use of the ASCII NUL code as a string terminator, but > that's C. The content of a text file processed by a different > language, or by C using application-defined string containers > can easily contain a NUL byte yet still be considered "text" > if that distinction is necessary. > > Because of C/C++, a valid UTF-8 encoding will not include > the NUL byte. You're a philosopher of language because you can't handle ambiguity. But C is ambiguous at this point.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-06 20:37 -0500 |
| Message-ID | <10h2loi$1o59d$1@dont-email.me> |
| In reply to | #395686 |
On 2025-12-05 20:05, Michael Sanders wrote: > Am I close? Missing anything you'd consider to be (or not) needed? > > <stdio.h> > > /* > * Checks if a file is likely a binary by examining its content > * for NULL bytes (0x00) or unusual control characters. NULL is a macro that expands to a null pointer constant. I think you mean "null character". This isn't just nit-picking -C is a case-sensitive language, so it's essential to pay attention to case. > * Returns 0 if text, 1 if binary or file open failure. > */ You should return a distinct value for file open failure - a file that cannot be opened cannot be determined to be either a text or a binary file. You really cannot distinguish with certainty whether a file is a text file or a binary file based solely upon the contents. A file whose format is an array of two-byte 2's complement little-endian integers would normally be considered binary, yet it might happen to contain integers whose bytes all happen to be printable characters. The standard does not define what a "binary file" is. However, it does provide a promise that applies only to streams in text mode, which depends upon what was written to that file: "Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character." (7.23.2p2). I believe it therefore makes sense to consider something to be a text file if it meets those requirements, and otherwise is a binary file. Note that the last requirement implies that an empty file cannot qualify as text - at a minimum, it must contain a new-line character. This implies the use of the isprint() function; the only other characters you need to handle specifically are '\t', '\n', and ' '. Since the result returned by isprint() is locale-dependent, the program should, at least optionally, use setlocale().
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-08 18:02 +0000 |
| Message-ID | <10h73ri$9q1e$5@dont-email.me> |
| In reply to | #395701 |
On Sat, 6 Dec 2025 20:37:22 -0500, James Kuyper wrote: > NULL is a macro that expands to a null pointer constant. I think you > mean "null character". This isn't just nit-picking -C is a > case-sensitive language, so it's essential to pay attention to case. Of yeah. I'm at the stage of simultaneously getting a lot wrong, a lot right, & that makes my code dangerous at times. I'm slowly getting there. > You should return a distinct value for file open failure - a file that > cannot be opened cannot be determined to be either a text or a binary file. Noted. > You really cannot distinguish with certainty whether a file is a text > file or a binary file based solely upon the contents. A file whose > format is an array of two-byte 2's complement little-endian integers > would normally be considered binary, yet it might happen to contain > integers whose bytes all happen to be printable characters. Ah, I want it to be simple, but that's not the case. > This implies the use of the isprint() function; the only other > characters you need to handle specifically are '\t', '\n', and ' '. > Since the result returned by isprint() is locale-dependent, the program > should, at least optionally, use setlocale(). Hmm, now that's a curve-ball I did not see coming! I've got to think about this... Paul, thank you for sharing your knowledge, I appreciate your help sir. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-09 16:29 -0500 |
| Message-ID | <10ha4c3$kd3o$2@dont-email.me> |
| In reply to | #395701 |
On 2025-12-06 20:37, James Kuyper wrote: ... > "Data read in from a text stream will necessarily compare equal to the > data that were earlier written out to that stream only if: the data > consist only of printing characters and the control characters > horizontal tab and new-line; no new-line character is immediately > preceded by space characters; and the last character is a new-line > character." (7.23.2p2). > > I believe it therefore makes sense to consider something to be a text > file if it meets those requirements, and otherwise is a binary file. > Note that the last requirement implies that an empty file cannot qualify > as text - at a minimum, it must contain a new-line character. > > This implies the use of the isprint() function; the only other > characters you need to handle specifically are '\t', '\n', and ' '. > Since the result returned by isprint() is locale-dependent, the program > should, at least optionally, use setlocale(). I just realized an annoying complication. Whatever implementation-specific method is used to indicate end-of-line can only be portably identified as such by opening the file in text mode and looking for the newline characters that it gets converted into. But because of 7.23.2p2, text mode cannot be relied upon for precisely the files we're trying to identify.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-10 11:21 +0200 |
| Message-ID | <20251210112132.00004083@yahoo.com> |
| In reply to | #395744 |
On Tue, 9 Dec 2025 16:29:39 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 2025-12-06 20:37, James Kuyper wrote: > ... > > "Data read in from a text stream will necessarily compare equal to > > the data that were earlier written out to that stream only if: the > > data consist only of printing characters and the control characters > > horizontal tab and new-line; no new-line character is immediately > > preceded by space characters; and the last character is a new-line > > character." (7.23.2p2). > > > > I believe it therefore makes sense to consider something to be a > > text file if it meets those requirements, and otherwise is a binary > > file. Note that the last requirement implies that an empty file > > cannot qualify as text - at a minimum, it must contain a new-line > > character. > > > > This implies the use of the isprint() function; the only other > > characters you need to handle specifically are '\t', '\n', and ' '. > > Since the result returned by isprint() is locale-dependent, the > > program should, at least optionally, use setlocale(). > > I just realized an annoying complication. Whatever > implementation-specific method is used to indicate end-of-line can > only be portably identified as such by opening the file in text mode > and looking for the newline characters that it gets converted into. > But because of 7.23.2p2, text mode cannot be relied upon for > precisely the files we're trying to identify. Does not sound like a problem. According to my understanding, wide portability was never a part of the OP's spec.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-10 12:48 -0500 |
| Message-ID | <10hcbom$1b253$1@dont-email.me> |
| In reply to | #395755 |
On 2025-12-10 04:21, Michael S wrote: > On Tue, 9 Dec 2025 16:29:39 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... >> I just realized an annoying complication. Whatever >> implementation-specific method is used to indicate end-of-line can >> only be portably identified as such by opening the file in text mode >> and looking for the newline characters that it gets converted into. >> But because of 7.23.2p2, text mode cannot be relied upon for >> precisely the files we're trying to identify. > > Does not sound like a problem. According to my understanding, wide > portability was never a part of the OP's spec. His spec was unclear. At least part of my intent in raising these issues is to point out issues that he might not want to deal with, and which he can justify ignoring by specifying that his routine is not intended to deal with them. Thinking about this particular problem, I see no way to deal with it in general. Had I a need to write such a routine, I'd be happy to restrict the validity of my code to platforms where end-of-line is is indicated by a single new-line character. However, I suspect he might need Windows compatibility, and might not need portability to Unix-like systems.
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-10 11:38 +0000 |
| Message-ID | <10hbm46$1fc0e$2@dont-email.me> |
| In reply to | #395744 |
On Tue, 9 Dec 2025 16:29:39 -0500, James Kuyper wrote: [...] James if you can manage a spare moment, see my reply to Lew ie - is_text_file() Would like your critique. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-07 03:43 +0000 |
| Message-ID | <10h2t5s$3m1kg$1@paganini.bofh.team> |
| In reply to | #395686 |
Michael Sanders <porkchop@invalid.foo> wrote:
> Am I close? Missing anything you'd consider to be (or not) needed?
You miss definition: you should first decide what you consider to
be a binary file (this is hard part). You may wish consider
my experience many years ago: I looked at problem reports about
SUN OS. Those were considered text files, in total about 160 MB.
For my purposes it would be convenient to find character code _not_
appearing in those files. But checking found that the only code
which did not appear were 0. Report were mostly in English,
but there were non-English pieces contributing international
characters. There were handful of box-drawing characters.
There were (I think stray) control codes.
You can take from this that zero code was strong indicator of
non-text file. But do you consider UTF-16 encode text as binary?
Note that such text is likely to contain a lot of zero bytes.
Any byte different than zero will appear in a file considered by
its author to be a text file as long as you take large enough
sample.
If you have few hundred of characters from a file you can apply
a reasonably simple statistical test to decide if text came from
one of popular human langages and if yes test will tell you the
language.
For security puprose you may wish to check if a file oly contains
safe codes. But definition of "safe" depends on application.
In US context you could decide that anything outside printable
ASCII + newline is unsafe. Or you may add to this some selected
contol codes like tabs. In international context you probably
need to allow relevant national character codes, which depends
on specific environment.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-08 18:04 +0000 |
| Message-ID | <10h7402$9q1e$6@dont-email.me> |
| In reply to | #395702 |
On Sun, 7 Dec 2025 03:43:58 -0000 (UTC), Waldek Hebisch wrote: > You miss definition: you should first decide what you consider to > be a binary file (this is hard part). Yes. This is it - everything right here Waldek, that is my entire problem. Thank you for you post, it is interesting reading. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-08 18:44 +0000 |
| Message-ID | <10h76ag$att7$1@dont-email.me> |
| In reply to | #395720 |
On 08/12/2025 18:04, Michael Sanders wrote: > On Sun, 7 Dec 2025 03:43:58 -0000 (UTC), Waldek Hebisch wrote: > >> You miss definition: you should first decide what you consider to >> be a binary file (this is hard part). > > Yes. This is it - everything right here Waldek, that is my entire > problem. It's not clear what the actual problem is. What is the use-case for a function that tells you whether any file /might/ be a text-file based on speculative analysis of its contents? Is the result /meant/ to be fuzzy?
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web