Alternative to magic.h and infer.
Zero dependencies. Fully extensible.
Works in no_std, async, and embedded contexts.
Comments
0cf8612b2e1e•6mo ago
Minor thing, I find it off putting when a project describes itself as “one of the best frameworks”. Just launch straight into the offering and let users decide. You already have multiple selling points, no need for the blatant self promotion.
reimisdev•6mo ago
You're right – that phrase was a bit much. I'll revise it. Thanks for pointing it out!
landr0id•6mo ago
I hate to be one of those people that asks “what differentiates this from X”, but is there a selling point for why I’d want to use this over https://github.com/theseus-rs/file-type if I’m in a sync + std context and don’t really care about dependency count?
reimisdev•6mo ago
These two crates follow different philosophies. file-type is great for lightweight, static detection. In contrast, `magical_rs` is designed to be a framework — it lets you define custom rules, layer logic via DSLs, and even embed custom function pointers for advanced matching.
So if your use-case involves complex formats, edge-case detection, or internal tooling where you need full control — magical_rs gives you the power without forcing you to fork the crate.
self_awareness•6mo ago
I mean, for full control we generally only need a file handle, not a framework. ;)
reimisdev•6mo ago
You are absolutely right if you only need to detect simple file types. But of course no one forks a library to add the 3 file types they need and then re-builds them, and not to mention that because it's a static rule, if you want to detect more complex file types, it almost means you'll have to rewrite the entire core for that.
self_awareness•6mo ago
I think it could utilise somehow the file(1) database (/usr/share/misc/magic.mgc, /usr/share/misc/magic), it has lots of file formats detections already, although the format itself is a little limited.
0cf8612b2e1e•6mo ago
reimisdev•6mo ago