|Anonymous | Login | Signup for a new account||2017-11-22 09:18 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001119||[1003.1(2016)/Issue7+TC2] Shell and Utilities||Objection||Enhancement Request||2017-02-15 01:48||2017-02-27 09:50|
|Final Accepted Text|
|Summary||0001119: When the file named by the <file> operand does not exist, `file` should not exit with zero status|
$ file /this/does/not/exist
/this/does/not/exist: cannot open `/this/does/not/exist' (No such file or directory)
$ echo $?
This is apparently conformant, but it is nonsensical and divergent from the specification for `ls`, `cat`, etc.
|Desired Action||`file` should exit with nonzero status when the file named by the <file> parameter cannot be found.|
|Tags||No tags attached.|
Vincent Lefevre (reporter)
|A change could break existing scripts. http://www.darwinsys.com/file/ [^] uses an option -E to regard filesystem errors (such as file not found) as usual errors.|
Besides the fact that such a change could break existing scripts, file's
task is to return information about the path name and:
LC_ALL=C file /tmp/missing
/tmp/missing: cannot open: No such file or directory
may be seen as "information" about the path in question.
edited on: 2017-02-21 14:19
Also, note the ellipsis on the file operand. If it was required to return non-zero if any operand was not present, a script wouldn't know which operand the return applied to anyways. This proposal could be an extension behavior for the limiting case of only one file operand, but 'test -e file' already provides the same info unambiguously. The Exit Status section could be more descriptive that >0 returns relate to system conditions like utility not found/not executable or out of memory/file handles, and not about a particular operand.
As an aid to parsing, numbering the file types expected to be reported and including this in the output for each file, using "%s:%2d %s" as first part of format strings, would be more the way I'd expect an extension to be implemented. This can be added to the current outputs anyways without affecting conformance, but then the number assignments would be more prone to vary among implementations. This would also distinguish the 'does not exist' case from the 'cannot read/write only' case. A new switch, e.g. -n[umber code], could control whether this format is used instead of the current one for backwards compatibility purposes. If a MAGIC file supports additional types these can be required to use numbers higher than the "data" one; new standard types would bump the "data" number up, and -n by itself could be used to report this value for assignment to a test variable.
Vincent Lefevre (reporter)
I think that an extension (even for several files) could be useful in the case the user expects the file(s) to be there and readable. Such an extension can allow scripts to be simpler and provide more security, e.g. in scripts with "set -e". This makes error detection much easier.
Then, when this is enabled, one may wonder whether the error messages are written to stdout like in the normal case or to stderr.
edited on: 2017-02-23 19:05
I agree in principle, but an expectation like that can be invalidated at any time by a separate process with higher privileges than the script so its reliability would still be suspect. Error handlers couldn't assume an operand error was due to a hardware failure unless the script was running as root and blocked all other root processes or all media involved was physically read only.
I would limit it to a generic "all files processed, but one or more have unknown type" single status code, unequal to the reserved status codes, so larger MAGIC files/new standard types don't trigger status code overflow as a future issue. A report of that nature I'd expect to go to stderr all the time as a warning, and could trigger a case statement in the script limited to checking the stdout output for which files had problems for additional reporting, as simpler in concept than a case statement mixing both error checking and type-specific processing. I would not force scripts to have to try and parse stderr also because it is echoing per file problem reports there too, or in lieu of being part of the stdout report.
As it stands now, I see a non-zero exit status indicating something prevented file from trying to process an operand at all so the utility aborted,
and you basically have now:
if file ... >outfile ; then parse_outfile ; else handle_abort; fi;
as the nominal workflow. Adding this changes usage more to:
if file ... >outfile ; then parse_outfile ; elif [ $? = $EXIT_FILE_OP_ERR ] ; then parse_errors_in_outfile ; else handle_abort; fi;
which, being wordier, might be seen as more complex, not simpler.
|2017-02-15 01:48||mhjacobson||New Issue|
|2017-02-15 01:48||mhjacobson||Status||New => Under Review|
|2017-02-15 01:48||mhjacobson||Assigned To||=> ajosey|
|2017-02-15 01:48||mhjacobson||Name||=> Matt Jacobson|
|2017-02-15 01:48||mhjacobson||Section||=> file|
|2017-02-15 01:48||mhjacobson||Page Number||=> 0|
|2017-02-15 01:48||mhjacobson||Line Number||=> 0|
|2017-02-21 01:55||Vincent Lefevre||Note Added: 0003563|
|2017-02-21 12:06||joerg||Note Added: 0003564|
|2017-02-21 14:07||shware_systems||Note Added: 0003565|
|2017-02-21 14:19||shware_systems||Note Edited: 0003565|
|2017-02-22 01:16||Vincent Lefevre||Note Added: 0003566|
|2017-02-23 18:51||shware_systems||Note Added: 0003569|
|2017-02-23 18:55||shware_systems||Note Edited: 0003569|
|2017-02-23 19:05||shware_systems||Note Edited: 0003569|
|2017-02-27 09:50||geoffclare||Project||1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|