0001119: When the file named by the <file> operand does not exist, `file` should not exit with zero status

Notes
(0003563) Vincent Lefevre (reporter) 2017-02-21 01:55	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.

(0003564) joerg (reporter) 2017-02-21 12:06	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.

(0003565) shware_systems (reporter) 2017-02-21 14:07 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.

(0003566) Vincent Lefevre (reporter) 2017-02-22 01:16	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.

(0003569) shware_systems (reporter) 2017-02-23 18:51 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.

(0004062) Don Cragun (manager) 2018-07-26 16:26 edited on: 2018-07-26 16:28	This was discussed during the July 26, 2018 conference call. This change request is rejected... The standard clearly states that this is not an error (see page 2790, line 91651-3): If the file named by the file operand does not exist, cannot be read, or the type of the file named by the file operand cannot be determined, this shall not be considered an error that affects the exit status The file utility is unlike other file-handling utilities in that when a file does not exist, its non-existence is a piece of information about the file which file writes to standard output. The exit status of zero indicates that this information was successfully written to standard output. Other utilities report the non-existence to standard error and the exit status indicates that an error message was written to standard error.

Issue History
Date Modified	Username	Field	Change
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/18)/Issue7+TC2
2018-07-26 16:26	Don Cragun	Note Added: 0004062
2018-07-26 16:26	Don Cragun	Interp Status	=> ---
2018-07-26 16:26	Don Cragun	Status	Under Review => Closed
2018-07-26 16:26	Don Cragun	Resolution	Open => Rejected
2018-07-26 16:28	Don Cragun	Note Edited: 0004062
2018-07-26 16:28	Don Cragun	Note Edited: 0004062

Relationships

Aardvark Mark IV