file [-dh] [-M file] [-m file] file... file -i [-h] file...
If file does not exist, cannot be read, or its file status could not be determined, the output shall indicate that the file was processed, but that its type could not be determined.
If file is a symbolic link, by default the link shall be resolved and file shall test the type of file referenced by the symbolic link.
The following options shall be supported by the implementation:
If the -m option is specified without specifying the -d option or the -M option, position-sensitive default system tests shall be applied after the position-sensitive tests specified by the -m option. If the -M option is specified with the -d option, the -m option, or both, or the -m option is specified with the -d option, the concatenation of the position-sensitive tests specified by these options shall be applied in the order specified by the appearance of these options. If a -M or -m file option-argument is -, the results are unspecified.
"%s: %s\n", <file>, <type>
The values for <type> are unspecified, except that in the POSIX
locale, if
file
is identified as one of the types listed in the following table,
<type> shall contain (but is not limited to) the corresponding
string, unless the file is identified by a position-sensitive test
specified by a
-M
or
-m
option. Each
<space>
shown in the strings shall be exactly one
<space>.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In the POSIX locale, if file is identified as a symbolic link (see the -h option), the following alternative output format shall be used:
"%s: %s %s\n", <file>, <type>, <contents of link>"
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.
Each line shall be composed of the following four <tab>-separated fields. (Implementations may allow any combination of one or more white-space characters other than <newline> to act as field separators.)
If the offset begins with the character '>', the test contained in the line shall not be applied to the file unless the test on the last line for which the offset did not begin with a '>' was successful. By default, the offset shall be interpreted as an unsigned decimal number. With a leading 0x or 0X, the offset shall be interpreted as a hexadecimal number; otherwise, with a leading 0, the offset shall be interpreted as an octal number.
The type string shall be interpreted as the bytes from the file starting at the specified offset and including the same number of bytes specified by the value field. If insufficient bytes remain in the file past the offset to match the value field, the test shall fail.
The type specification characters d and u can be followed by an optional unsigned decimal integer that specifies the number of bytes represented by the type. The type specification characters d and u can be followed by an optional C, S, I, or L, indicating that the value is of type char, short, int, or long, respectively.
The default number of bytes represented by the type specifiers d, f, and u shall correspond to their respective C-language types as follows. If the system claims conformance to the C-Language Development Utilities option, those specifiers shall correspond to the default sizes used in the c99 utility. Otherwise, the default sizes shall be implementation-defined.
For the type specifier characters d and u, the default number of bytes shall correspond to the size of a basic integer type of the implementation. For these specifier characters, the implementation shall support values of the optional number of bytes to be converted corresponding to the number of bytes in the C-language types char, short, int, or long. These numbers can also be specified by an application as the characters C, S, I, and L, respectively. The byte order used when interpreting numeric values is implementation-defined, but shall correspond to the order in which a constant of the corresponding type is stored in memory on the system.
All type specifiers, except for s, can be followed by a mask specifier of the form &number. The mask value shall be AND'ed with the value of the input file before the comparison with the value field of the line is made. By default, the mask shall be interpreted as an unsigned decimal number. With a leading 0x or 0X, the mask shall be interpreted as an unsigned hexadecimal number; otherwise, with a leading 0, the mask shall be interpreted as an unsigned octal number.
The strings byte, short, long, and string shall also be supported as type fields, being interpreted as dC, dS, dL, and s, respectively.
If the specifier from the type field is s or string, then interpret the value as a string. Otherwise, interpret it as a number. If the value is a string, then the test shall succeed only when a string value exactly matches the bytes from the file.
If the value is a string, it can contain the following sequences:
By default, any value that is not a string shall be interpreted as a signed decimal number. Any such value, with a leading 0x or 0X, shall be interpreted as an unsigned hexadecimal number; otherwise, with a leading zero, the value shall be interpreted as an unsigned octal number.
If the value is not a string, it can be preceded by a character indicating the comparison to be performed. Permissible characters and the comparisons they specify are as follows:
The following sections are informative.
Note that the table indicates that the output contains the stated string. Systems may add text before or after the string. For executables, as an example, the machine architecture and various facts about how the file was link-edited may be included. Note also that on systems that recognize shell script files starting with "#!" as executable files, these may be identified as executable binary files rather than as shell scripts.
file -- "$1" | grep -q ':.*executable' &&
printf "%s is executable.\n$1"
Historical versions of the file utility attempt to identify the following types of files: symbolic link, directory, character special, block special, socket, tar archive, cpio archive, SCCS archive, archive library, empty, compress output, pack output, binary data, C source, FORTRAN source, assembler source, nroff/troff/eqn/tbl source troff output, shell script, C shell script, English text, ASCII text, various executables, APL workspace, compiled terminfo entries, and CURSES screen images. Only those types that are reasonably well specified in POSIX or are directly related to POSIX utilities are listed in the table.
Historical systems have used a ``magic file'' named /etc/magic to help identify file types. Because it is generally useful for users and scripts to be able to identify special file types, the -m flag and a portable format for user-created magic files has been specified. No requirement is made that an implementation of file use this method of identifying files, only that users be permitted to add their own classifying tests.
In addition, three options have been added to historical practice. The -d flag has been added to permit users to cause their tests to follow any default system tests. The -i flag has been added to permit users to test portably for regular files in shell scripts. The -M flag has been added to permit users to ignore any default system tests.
The POSIX.1-2008 description of default system tests and the interaction between the -d, -M, and -m options did not clearly indicate that there were two types of ``default system tests''. The ``position-sensitive tests'' determine file types by looking for certain string or binary values at specific offsets in the file being examined. These position-sensitive tests were implemented in historical systems using the magic file described above. Some of these tests are now built into the file utility itself on some implementations so the output can provide more detail than can be provided by magic files. For example, a magic file can easily identify a core file on most implementations, but cannot name the program file that dropped the core. A magic file could produce output such as:
/home/dwc/core: ELF 32-bit MSB core file SPARC Version 1
but by building the test into the file utility, you could get output such as:
/home/dwc/core: ELF 32-bit MSB core file SPARC Version 1, from 'testprog'
These extended built-in tests are still to be treated as position-sensitive default system tests even if they are not listed in /etc/magic or any other magic file.
The context-sensitive default system tests were always built into the file utility. These tests looked for language constructs in text files trying to identify shell scripts, C, FORTRAN, and other computer language source files, and even plain text files. With the addition of the -m and -M options the distinction between position-sensitive and context-sensitive default system tests became important because the order of testing is important. The context-sensitive system default tests should never be applied before any position-sensitive tests even if the -d option is specified before a -m option or -M option due to the high probability that the context-sensitive system default tests will incorrectly identify arbitrary text files as text files before position-sensitive tests specified by the -m or -M option would be applied to give a more accurate identification.
Leaving the meaning of -M - and -m - unspecified allows an existing prototype of these options to continue to work in a backwards-compatible manner. (In that implementation, -M - was roughly equivalent to -d in POSIX.1-2008.)
The historical -c option was omitted as not particularly useful to users or portable shell scripts. In addition, a reasonable implementation of the file utility would report any errors found each time the magic file is read.
The historical format of the magic file was the same as that specified by the Rationale in the ISO POSIX-2:1993 standard for the offset, value, and message fields; however, it used less precise type fields than the format specified by the current normative text. The new type field values are a superset of the historical ones.
The following is an example magic file:
0 short 070707 cpio archive 0 short 0143561 Byte-swapped cpio archive 0 string 070707 ASCII cpio archive 0 long 0177555 Very old archive 0 short 0177545 Old archive 0 short 017437 Old packed data 0 string \037\036 Packed data 0 string \377\037 Compacted data 0 string \037\235 Compressed data >2 byte&0x80 >0 Block compressed >2 byte&0x1f x %d bits 0 string \032\001 Compiled Terminfo Entry 0 short 0433 Curses screen image 0 short 0434 Curses screen image 0 string <ar> System V Release 1 archive 0 string !<arch>\n__.SYMDEF Archive random library 0 string !<arch> Archive 0 string ARF_BEGARF PHIGS clear text archive 0 long 0x137A2950 Scalable OpenFont binary 0 long 0x137A2951 Encrypted scalable OpenFont binary
The use of a basic integer data type is intended to allow the implementation to choose a word size commonly used by applications on that architecture.
Earlier versions of this standard allowed for implementations with bytes other than eight bits, but this has been modified in this version.
The Base Definitions volume of POSIX.1-2017, Table 5-1, Escape Sequences and Associated Actions, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .