Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter mhjacobson View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Matt Jacobson
User Reference
Section file
Page Number 0
Line Number 0
Interp Status ---
Final Accepted Text
Summary 0001119: When the file named by the <file> operand does not exist, `file` should not exit with zero status
Description $ 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.
Attached Files

- Relationships

-  Notes
Vincent Lefevre (reporter)
2017-02-21 01:55

A change could break existing scripts. [^] uses an option -E to regard filesystem errors (such as file not found) as usual errors.
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.
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.

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.
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.

- 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)/Issue7+TC2

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker