View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000217 | file | General | public | 2020-12-21 12:02 | 2024-03-04 17:19 |
| Reporter | Helge Kreutzmann | Assigned To | christos | ||
| Priority | low | Severity | tweak | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 5.39 | ||||
| Summary | 0000217: Issues in file man pages | ||||
| Description | Dear file maintainer, the manpage-l10n project maintains a large number of translations of man pages both from a large variety of sources (including file) as well for a large variety of target languages. During their work translators notice different possible issues in the original (english) man pages. Sometimes this is a straightforward typo, sometimes a hard to read sentence, sometimes this is a convention not held up and sometimes we simply do not understand the original. We use several distributions as sources and update regularly (at least every 2 month). This means we are fairly recent (some distributions like archlinux also update frequently) but might miss the latest upstream version once in a while, so the error might be already fixed. We apologize and ask you to close the issue immediately if this should be the case, but given the huge volume of projects and the very limited number of volunteers we are not able to double check each and every issue. Secondly we translators see the manpages in the neutral po format, i.e. converted and harmonized, but not the original source (be it man, groff, xml or other). So we cannot provide a true patch (where possible), but only an approximation which you need to convert into your source format. Finally the issues I'm reporting have accumulated over time and are not always discovered by me, so sometimes my description of the problem my be a bit limited - do not hesitate to ask so we can clarify them. I'm now reporting the errors for your project. If future reports should use another channel, please let me know. Man page: file.1 Issue: What ist "E<.Bk -words>"? "E<.Nm> E<.Bk -words> E<.Op Fl bcdEhiklLNnprsSvzZ0> E<.Op Fl Fl apple> E<.Op " "Fl Fl exclude-quiet> E<.Op Fl Fl extension> E<.Op Fl Fl mime-encoding> E<.Op " "Fl Fl mime-type> E<.Op Fl e Ar testname> E<.Op Fl F Ar separator> E<.Op Fl f " "Ar namefile> E<.Op Fl m Ar magicfiles> E<.Op Fl P Ar name=value> E<.Ar> E<." "Ek> E<.Nm> E<.Fl C> E<.Op Fl m Ar magicfiles> E<.Nm> E<.Op Fl Fl help>" -- Man page: file.1 Issue: Two quote signs around magic / magic numbers does not make sense "in the standard include directory. These files have a E<.Dq \"magic number" "\"> stored in a particular place near the beginning of the file that tells " "the E<.Tn UNIX> operating system that the file is a binary executable, and " "which of several types thereof. The concept of a E<.Dq \"magic\"> has been " "applied by extension to data files. Any file with some invariant identifier " "at a small fixed offset into the file can usually be described in this way. " "The information identifying these files is read from the compiled magic file " "E<.Pa /usr/share/file/misc/magic.mgc>, or the files in the directory E<.Pa /" "usr/share/file/misc/magic> if the compiled file does not exist. In " "addition, if E<.Pa $HOME/.magic.mgc> or E<.Pa $HOME/.magic> exists, it will " "be used in preference to the system magic files." -- Man page: file.1 Issue: the file command â the command <.Nm> "Causes the file command to output the file type and creator code as used by " "older MacOS versions. The code consists of eight letters, the first " "describing the file type, the latter the creator. This option works " "properly only for file formats that have the apple-style output defined." -- Man page: file.1 Issue: option â (This) option "option causes symlinks not to be followed (on systems that support symbolic " "links). This is the default if the environment variable E<.Dv " "POSIXLY_CORRECT> is not defined." "option causes symlinks to be followed, as the like-named option in E<.Xr ls " "1> (on systems that support symbolic links). This is the default if the " "environment variable E<.Ev POSIXLY_CORRECT> is defined." -- Man page: file.1 Issue: file â E<.Nm> "Causes the file command to output mime type strings rather than the more " "traditional human readable ones. Thus it may say E<.Sq text/plain; " "charset=us-ascii> rather than E<.Dq ASCII text>." "On systems where libseccomp E<.Pa ( https://github.com/seccomp/libseccomp>) " "is available, the E<.Fl S> flag disables sandboxing which is enabled by " "default. This option is needed for file to execute external decompressing " "programs, i.e. when the E<.Fl z> flag is specified and the built-in " "decompressors are not available. On systems where sandboxing is not " "available, this option has no effect." "The magic file entries have been collected from various sources, mainly " "USENET, and contributed by various authors. Christos Zoulas (address below) " "will collect additional or corrected magic file entries. A consolidation of " "magic file entries will be distributed periodically." "John Gilmore revised the code extensively, making it better than the first " "version. Geoff Collyer found several inadequacies and provided some magic " "file entries. Contributions of the E<.Sq \\*[Am]> operator by Rob McMahon, " "E<.Aq cudcv@warwick.ac.uk>, 1989." "E<.Em Note:> This Debian version of file was built without seccomp support, " "so this option has no effect." -- Man page: file.1 Issue: option â flag? "On systems where libseccomp E<.Pa ( https://github.com/seccomp/libseccomp>) " "is available, E<.Nm> is enforces limiting system calls to only the ones " "necessary for the operation of the program. This enforcement does not " "provide any security benefit when E<.Nm> is asked to decompress input files " "running external programs with the E<.Fl z> option. To enable execution of " "external decompressors, one needs to disable sandboxing using the E<.Fl S> " "flag." -- Man page: file.1 Issue: Missing full stop. "Some of the encoding logic is hard-coded in encoding.c and can be moved to " "the magic files if we had a !:charset annotation" -- Man page: file.1 Issue: This bug was closed in 2008? "Store arbitrarily long strings, for example for %s patterns, so that they " "can be printed out. Fixes Debian bug #271672. This can be done by " "allocating strings in a string pool, storing the string pool at the end of " "the magic file and converting all the string pointers to relative offsets " "from the string pool." -- Man page: file.1 Issue 1: security considerations) â security) considerations Issue 2: so move around the file â to move around in the file "If the offsets specified internally in the file exceed the buffer size ( E<." "Dv HOWMANY> variable in file.h), then we don't seek to that offset, but we " "give up. It would be better if buffer managements was done when the file " "descriptor is available so move around the file. One must be careful though " "because this has performance (and thus security considerations)." -- Man page: file.1 Issue: is E<.Ek> â file? This long string is difficult to review for translation "E<.Nm> E<.Bk -words> E<.Op Fl bcdEhiklLNnprsSvzZ0> E<.Op Fl Fl apple> E<.Op " "Fl Fl extension> E<.Op Fl Fl mime-encoding> E<.Op Fl Fl mime-type> E<.Op Fl " "e Ar testname> E<.Op Fl F Ar separator> E<.Op Fl f Ar namefile> E<.Op Fl m " "Ar magicfiles> E<.Op Fl P Ar name=value> E<.Ar> E<.Ek> E<.Nm> E<.Fl C> E<.Op " "Fl m Ar magicfiles> E<.Nm> E<.Op Fl Fl help>" -- Man page: file.1 Issue: Two quote signs around magic / magic numbers does not make sense "in the standard include directory. These files have a E<.Dq \"magic number" "\"> stored in a particular place near the beginning of the file that tells " "the E<.Tn UNIX> operating system that the file is a binary executable, and " "which of several types thereof. The concept of a E<.Dq \"magic\"> has been " "applied by extension to data files. Any file with some invariant identifier " "at a small fixed offset into the file can usually be described in this way. " "The information identifying these files is read from /etc/magic and the " "compiled magic file E<.Pa /usr/share/misc/magic.mgc>, or the files in the " "directory E<.Pa /usr/share/misc/magic> if the compiled file does not exist. " "In addition, if E<.Pa $HOME/.magic.mgc> or E<.Pa $HOME/.magic> exists, it " "will be used in preference to the system magic files." | ||||
| Tags | No tags attached. | ||||
|
|
Issue: What ist "E<.Bk -words>"? - See the "Keep" macro https://www.freebsd.org/cgi/man.cgi?query=mdoc&sektion=7 Issue: Two quote signs around magic / magic numbers does not make sense - Removed, don't make a difference Issue: the file command â the command <.Nm> - Use .Nm Issue: option â (This) option - Added "This" Issue: file â E<.Nm> - fixed .Nm Issue: option â flag? - changed all to option Issue: Missing full stop. - fixed. Issue: This bug was closed in 2008? - No it is still broken (string limits in magic descriptions) Issue 1: security considerations) â security) considerations Issue 2: so move around the file â to move around in the file - Rewrote and clarified. Issue: is E<.Ek> â file? This long string is difficult to review for translation - This is the list of flags. .Ek is the closing of .Bk macro. Issue: Two quote signs around magic / magic numbers does not make sense - duplicate, fixed. |
|
|
Thanks for the swift handling, no more comments from my side. |
|
|
Has this already landed in some kind of release? I wonder because I still see some issues in file(1) in all our upstream distributions. |
|
|
As of mid February 2023 I still see them in the major distros. What is the ETA for including them? |
|
|
Hello Christos, this is my yearly ping. Do you have an ETA for landing them in a release? Thanks! |
|
|
I apologize for my last note, all but one change (occuring twice) are actually fixed. So the only one left is: file → E<.Nm> "The magic file entries have been collected from various sources, mainly " "USENET, and contributed by various authors. Christos Zoulas (address below) " "will collect additional or corrected magic file entries. A consolidation of " "magic file entries will be distributed periodically." "John Gilmore revised the code extensively, making it better than the first " "version. Geoff Collyer found several inadequacies and provided some magic " "file entries. Contributions of the E<.Sq \\*[Am]> operator by Rob McMahon, " "E<.Aq cudcv@warwick.ac.uk>, 1989." |
|
|
These refer to the "magic file" not to the file command (the file containing magic entries). I am not sure when the next release will be. Need to find some spare time :-) |
|
|
Thanks, I marked this appropriately in our sources, so then all issues reported by me are fix and this bug can be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-21 12:02 | Helge Kreutzmann | New Issue | |
| 2021-01-03 20:25 | christos | Assigned To | => christos |
| 2021-01-03 20:25 | christos | Status | new => assigned |
| 2021-01-03 20:45 | christos | Status | assigned => feedback |
| 2021-01-03 20:45 | christos | Note Added: 0003517 | |
| 2021-01-05 15:39 | Helge Kreutzmann | Note Added: 0003524 | |
| 2021-01-05 15:39 | Helge Kreutzmann | Status | feedback => assigned |
| 2022-03-09 17:14 | Helge Kreutzmann | Note Added: 0003707 | |
| 2023-03-11 13:36 | Helge Kreutzmann | Note Added: 0003910 | |
| 2024-03-03 11:14 | Helge Kreutzmann | Note Added: 0004018 | |
| 2024-03-03 11:17 | Helge Kreutzmann | Note Added: 0004019 | |
| 2024-03-04 00:10 | christos | Note Added: 0004020 | |
| 2024-03-04 17:19 | Helge Kreutzmann | Note Added: 0004021 |
