[Toybox] [PATCH] Implement file(1).

[enh]

On Sun, Feb 14, 2016 at 10:40 AM, Rob Landley <rob at landley.net> wrote:
> On Sat, Feb 13, 2016 at 3:57 PM, Isaac Dunham <ibid.ag at gmail.com> wrote:
>> On Sat, Feb 13, 2016 at 09:56:29AM -0800, enh wrote:
>>> Unlike the POSIX file(1), there's no magic file here, just hard-coded
>>> common (non-obsolete) file formats. Personally most of my use of file(1)
>>> is as a one-line readelf(1) summarizer, so although I assume a full POSIX
>>> file(1) is out of scope (because just the database would likely be larger
>>> than all the rest of toybox), a subset that only supports in-use file types
>>> actually covers most of the use cases I encounter personally.
>>
>> FYI:
>> binary cpio (almost never seen) starts with a short having the octal value
>> 070707; there are big- and little-endian variants, so 0143561 is
>> 'byte-swapped cpio archive'
>> text-based cpio magic is a 6-byte string starting with "0707"
>> "ASCII cpio archive"
>> 070707 is 'odc' - "(pre-SVR4 orr odc)"
>> 070701 is 'newc' - "(SVR4 with no CRC)",
>> 070702 is 'newc' - "(SVR4 with CRC)"
>
> I've been meaning to add another one, since there's a periodic thread
> on linux-kernel about the fact cpio has no xattr support, and while
> we're at it fixing 32 bit timestamps, lack of nanosecond timestamp
> granularity, and 32 bit filesize limitations seemed like a good idea.
>
> I think the first go-round was here:
> http://lkml.iu.edu/hypermail/linux/kernel/1501.1/03905.html
>
> That's come up a couple times since then but no actual motion on it.
> (I should just sit down and do it. And send it to the posix list.)
>
> Anyway, the option of an external format file for the "file" command
> is not the _requirement_ for one. I wouldn't object to adding a check
> to read /etc/file.dat or whatever it is, processing what it finds
> there first (the file not existing being silently ignored), and
> falling back to the built-in types if it's not there.

yeah, what i wrote was confusing... you're all correct that it's not
required that the built-in support uses a magic file, but POSIX does
specify -m and -M options that let the user add their own magic file.

> (The main reason it's still on the todo list is I could never quite
> work out what format said file should have...)

for better or worse, POSIX has you covered there too. they specify the
format of the magic files too:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/file.html

their format seems to be of questionable utility, though, given that
it only supports the native endianness of the machine you're running
file(1) on.

> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1455485172.0