Control: tags -1 upstream Control: forwarded -1 https://bugs.astron.com/view.php?id=162
On 2020-05-17 11:19:38 +0200, Christoph Biedl wrote: > Vincent Lefevre wrote... > > > I get the following error: > (...) > > because testname foo does not exist. This should silently be ignored, > > so that if the testname is added in a later version, one can > > unconditionally use "file -e foo" on all machines. > > > > As an example, "file -e json" works in Debian/unstable, but not > > in stretch. > > While I understand the wish to create scripts around file(1) that work > in all Debian distributions, and I'd agree probing the features of the > available file(1) version first is annoying and painful ... I am somewhat > uneasy about that particular way of solving issue: If anyone > accidentially mistypes the requested testname, file(1) will happily > continue while it certainly should break then. I don't think that commands should try to detect mistypes, unless there is no drawback. Note that this would be different for something like "--include" instead of "--exclude", since if one explicitly asks for some test that is not available, the request cannot be satisfied, and this must be regarded as an error by default. > Can we find another way of handling your request? A possibility would be to output a warning and ignore the provided testname (this is fine for exclusion rules), *and* add an option to disable warnings (e.g. -q / --quiet in addition to -e, or --exclude-quiet in place of -e), since warnings can be annoying in scripts (redirecting stderr to /dev/null would not be a solution since this would hide error messages). > One idea was relaxing that check, but via an additional option and not > by default. Feels bad since this a permanent digression from upstream. > > Another idea was using backports. They have been requested in several > places and I'm confident there will be a way to provide them on a > regular base soon. The problem with backports for tools used by other software is the risk of breaking things when there are no clear specs, and this is the case with "file", where files can suddenly get misdetected like in bug 949878. > And finally, I could hack the known testnames into old versions, making > them a no-op there. If you convince SRT to accept that, I'll be happy to > do my part. > > ... and I'm open for other ideas. I think that the solution should allow one to avoid this issue with new tests added in the future. I've just reported it upstream. BTW, portability across distributions is also important. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
