I'm trying to send a bug report for the app file, /usr/bin/file

But consulting the man and sending an email

BUGS Please report bugs and send patches to the bug tracker at http://bugs.gw.com/ or the mailing list at ⟨file@mx.gw.com⟩ (visit http://mx.gw.com/mailman/listinfo/file first to subscribe).

Made me find out the mail address does not exist.

Is there another way of communicating to the community? Hopefully this here question is already part of it :)

So here's my email:

possible feature failure: the --extension option doesn't seem to output anything

$ file --extension "ab.gif" 
ab.gif: ???

It would be useful to easily be able to use the output of this to rename a file to its correct extension.

something like file --likely_extension would only output the likely detected extension or an error if the detection was too low

like thus:

$ file --likely_extension "ab.gif"

better though would be a --correct_extension option:

$ file --correct_extension "ab.jpg"

$ ls

Tyvm for this app :)

  • 8
    The second part of your problem description is a pure feature request which might run counter to the design philosophy held by some unix tool authors - do one thing only, do it well. Somebody might want to maintain the functionality of file(1) but resent having to maintain builtin basename(1) and mv (1) functionality :) Apr 30 '18 at 18:54
  • 3
    Write it........
    – JoelFan
    May 1 '18 at 1:47
  • You want a feature to do what can already be accomplished using existing commonly supported tools (like awk)? The software author may be inclined to let you know about, or at least be thinking about, The Linux Philosophy. Once you have a working patch, you'll be taken more seriously.
    – TOOGAM
    May 1 '18 at 4:43
  • In v5.25, file --extension does work for some file types (like .jpg). Maybe it doesn't "work" fir .gif because there are no other valid file extensions.
    – RonJohn
    May 1 '18 at 6:05
  • 2
    As an example, on my system: file --extension calf.jpg flower.gif outputs: calf.jpg: jpeg/jpg/jpe/jfif and flower.gif: showing the possible other extensions for those files (none in the case of the GIF file). Note that file only takes an educated guess at the type of a file - it uses a set of heuristics to do that. It's not detecting the extension from the name. If I rename calf.jpg to calf.txt it's still a JPEG file and file tells me that when I run file calf.txt it also tells me that the possible extensions are jpeg/jpg/jpe/jfif when I run file --extension calf.txt. May 2 '18 at 0:03

You are following the correct procedure to file an issue or enhancement request: if a program’s documentation mentions how to do so, follow those instructions.

Unfortunately it often happens that projects die, or that the instructions in the version you have are no longer accurate. In these cases, things become a little harder. One possible general approach is to file a bug with your distribution; success there can be rather hit-or-miss though... (I should mention that it’s usually better to report a bug to the distribution you got your package from, if you’re using a package; this is especially true if the packaged version is older than the current “upstream” version, and if you haven’t checked whether the issue is still present there.)

For file specifically, the official documentation has been updated to mention that the bug tracker and mailing list are down, and it also provides a direct email address for the current maintainer, which you could use to contact him.


In addition to Stephen Kitt's answer, you could consider (especially if you are a developer yourself, and if the program – file in your case – has source code that is not too difficult to understand) fetching the source code of that program (perhaps from your distribution) - since it is free software - and patching it, and also sending a patch.

If you take time to study the source code, you'll probably make a better bug report.

If you take more time to propose a fixing patch, you are likely to be considered more seriously (and IMHO you are acting more in the spirit of free software).

So use the freedom provided by free software: study its source code (freedom#1) and improve it (freedom#3).

Today it is very easy to publish (e.g. on github) your improved version and share it (freedom#2).

Be sure to have the latest release of the file program. Many distributions are not using that (and perhaps the bug in your distro has already been fixed upstream).

I am not sure that your --correct_extension behavior belongs to file (which is a program to query, not change, your data). But if it does, it probably should be spelled --correct-extension or --rename-extension ... And once you try to implement that, you might discover that there are weird corner cases (what about a gzipped tar file, or a compressed C source file, or something which might need several file extensions).

Notice that (contrary to Windows) on Linux & Unix a file is actually an inode (see inode(7)) and can have several names (or none), and can be opened by several processes at once (read about file descriptors) - or none, even if most files have only one name (but see link(2) & stat(2)). Since the same file could be named foo.txt and bar.gz it does not make a lot of sense to attach importance to file extensions. See also path_resolution(7).

So, if you try implementing your correct-extension idea, you'll find out that it is not that simple to implement (and even to specify), and that there is no obvious simple behavior for that.

Probably, your idea is not very good, and cannot be easily implemented on Linux and POSIX systems (at least, not for all cases).

So I recommend to avoid even submitting a feature request (in its initial form, it is a loss of time for you, and for the developers of file). Or else, work on it a lot, improve its specifications, and submit a patch.... Of course you'll spend a lot of work on that (and I really don't think it is worth the pain).

Perhaps also read some Unix programming book (like the old ALP, or something newer; and also intro(2) & syscalls(2)) and Operating Systems: Three Easy Pieces.

  • 10
    How could I forget that — indeed, the best way to “ask” for a feature is to implement it! Apr 30 '18 at 13:46
  • 2
    +1 for pointing out that file provides information, and does not change anything. Also, the notion that the "extension" of a file in any way indicates what application(s) should be used to open it is very Windows-oriented. Linux has always followed the "magic number" approach of putting a distinctive signature in the first few bytes of a file, and then allowing the name to be anything. By way of analogy, I were a file in a Windows system, I'd have to be "Monty Harder.human" in order for anything to know what I am, but Linux sees that as part of my content, and the name is unconstrained. Apr 30 '18 at 16:46
  • 1
    If you can locate the correct source code you can also locate the committer. Apr 30 '18 at 17:20
  • 2
    @StephenKitt Even before Linux, Unix had shebangs and file with the magic file, so I don't know how "retro-fitted" it is. MacOS' approach put an explicit file type in the file metadata ("resource fork"), which is stored inside the file but in a separate container. Apr 30 '18 at 20:21
  • 2
    @l0b0 I see your point but I do think it's helpful to say that the best (not only) way to request a feature involves implementing it yourself, if you can. People who don't have the necessary programming skill can safely ignore this, but people who do will find it useful.
    – David Z
    Apr 30 '18 at 22:26

You ask:

What's the correct way to ask for a feature in GNU Linux?

and to answer that, it's important to know that there's no such single thing as "GNU Linux", per se. The GNU Project is a collaborative effort to develop free software. Some of that free software — along with large amounts of other free and open source software — is collected by other projects: either collaborative, open projects like Fedora* or Debian, or corporate efforts with varying degrees of openness, or even individuals. These collections are called "Linux Distributions" or "GNU/Linux distributions" (there is a political debate there which I won't get into).

In general, if you are interested in feature enhancement, the best thing to do is to work with the developer who wrote the software — the distributions have a lot of work to do to just collect the various software and make it work together, and normally would prefer those changes to happen "upstream".

So, you did the right thing here — you found the documented upstream source and tried to report there.

It appears, however, that the documented communication methods for the piece of software you are interested in aren't working. In that case, you have several options:

  1. Try to find other ways to contact the developers of the software. In this case, most distros include the file command originally written by Ian Darwin and nominally housed at http://www.darwinsys.com/file/, with the mailing lists you've mentioned. But like those mailing lists, the main site appears to be down. In this day and age, checking GitHub is a good second step, and I found https://github.com/file/file — which says Read-only mirror of file CVS repository, updated every half hour. NOTE: do not make pull requests here, nor comment any commits, submit them usual way to bug tracker or to the mailing list. That's not immediately helpful, but I notice that there have been changes to that repo in the past week. So, one possible next move is to see who did those commits and contact them.
  2. You could ask the person responsible for the package in the distro you use. For file in Fedora, see this page. Since they work with the software regularly, they may have other means of contacting the upstream. Depending on the distro, this is best done by filing a bug or by direct contact — you kind of need to know the individual culture. (In Fedora, I'd suggest the devel mailing list.)
  3. If you are using a commercial distribution, like Red Hat Enterprise Linux*, you can file a support ticket. As a paying customer, you may be able to influence your vendor to find a solution.
  4. If all else fails, the project you're interested might be dead upstream. In that case, you can "fork" the project — create your own version, and build a new upstream community around it. If your version is maintained and the other one is dead, it is likely the distributions will follow.

* I work on Fedora. And I'm employed by Red Hat.

  • 2
    "it's important to know that there's no such single thing as "GNU Linux"" – In particular, it is important to realize that Linux has nothing to do with GNU and GNU has nothing to do with Linux. Asking for a Linux feature from the GNU project or asking for a feature for a GNU utility from a Linux developer will most likely be simply ignored. Apr 30 '18 at 16:32
  • 3
    Or asking for a feature for a non-GNU utility from either of those.
    – user253751
    May 1 '18 at 0:22

This is a bug in your distribution. If the distribution is shipping man-pages that are out of date, you should file a bug against the package that provided it. If you are using debian, you can use a tool such as reportbug to make this simpler.

  • 4
    No, this isn’t a bug in the distribution: the upstream man page still provides the same information. Apr 30 '18 at 13:32
  • 1
    In any case, the maintainer of the package in the distribution should know how to file bugs with the original maintainer of the package May 1 '18 at 15:04
identify -format %m file.gif[0]

%m image file format (file magic)

The [0] means the first frame, which could help if you accidentally use it on a video as otherwise it uses ffmpeg libraries to make a temporary copy of each frame.

This only works for images. I don't know how to do it for generic files. ffmpeg returns 'avc1' for a random mp4 file (other mp4 files may return different strings, and you still have to parse it), and I don't see a way to get from that to 'mp4'. 'avc1' isn't anywhere in /usr/share/mime.

ffmpeg, or equivalently ffprobe, lists some file formats the demuxer uses at the start of its output. For an mp4 file it says

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from . . .
[. . .]
Video: h264 (Main) (avc1 / 0x31637661)

for a png it says

Input #0, png_pipe, from . . .
[. . .]
Video: png, rgb24(pc)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.