join [-a file_number|-v file_number] [-e string] [-o list] [-t char] [-1 field] [-2 field] file1 file2
The join field is a field in each file on which the files are compared. The join utility shall write one line in the output for each pair of lines in file1 and file2 that have join fields that collate equally. The output line by default shall consist of the join field, then the remaining fields from file1, then the remaining fields from file2. This format can be changed by using the -o option (see below). The -a option can be used to add unmatched lines to the output. The -v option can be used to output only unmatched lines.
The files file1 and file2 shall be ordered in the collating sequence of sort -b on the fields on which they shall be joined, by default the first in each line. All selected output shall be written in the same collating sequence.
The default input field separators shall be <blank> characters. In this case, multiple separators shall count as one field separator, and leading separators shall be ignored. The default output field separator shall be a <space>.
The field separator and collating sequence can be changed by using the -t option (see below).
If the same key appears more than once in either file, all combinations of the set of remaining fields in file1 and the set of remaining fields in file2 are output in the order of the lines encountered.
The following options shall be supported:
The elements of list shall be either <comma>-separated or <blank>-separated, as specified in Guideline 8 of the Base Definitions volume of POSIX.1-2017, Section 12.2, Utility Syntax Guidelines. The fields specified by list shall be written for all selected output lines. Fields selected by list that do not appear in the input shall be treated as empty output fields. (See the -e option.) Only specifically requested fields shall be written. The application shall ensure that list is a single command line argument.
"%s%s%s\n", <join field>, <other file1 fields>, <other file2 fields>
If the join field is not the first field in a file, the <other file fields> for that file shall be:
<fields preceding join field>, <fields following join field>
When the -o option is specified, the output format shall be:
"%s\n", <concatenation of fields>
where the concatenation of fields is described by the -o option, above.
For either format, each field (except the last) shall be written with its trailing separator character. If the separator is the default (<blank> characters), a single <space> shall be written after each field (except the last).
If the collating sequence of the current locale does not have a total ordering of all characters (see the Base Definitions volume of POSIX.1-2017, Section 7.3.2, LC_COLLATE), join treats fields that collate equally but are not identical as being the same. If this behavior is not desired, it can be avoided by forcing the use of the POSIX locale (although this means re-sorting the input files into the POSIX locale collating sequence.)
When using join to process pathnames, it is recommended that LC_ALL, or at least LC_CTYPE and LC_COLLATE, are set to POSIX or C in the environment, since pathnames can contain byte sequences that do not form valid characters in some locales, in which case the utility's behavior would be undefined. In the POSIX locale each byte is a valid single-byte character, and therefore this problem is avoided.
!Name Phone Number Don +1 123-456-7890 Hal +1 234-567-8901 Yasushi +2 345-678-9012
and file fax:
!Name Fax Number Don +1 123-456-7899 Keith +1 456-789-0122 Yasushi +2 345-678-9011
(where the large expanses of white space are meant to each represent a single <tab>), the command:
join -t "<tab>" -a 1 -a 2 -e '(unknown)' -o 0,1.2,2.2 phone fax
(where <tab> is a literal <tab> character) would produce:
!Name Phone Number Fax Number Don +1 123-456-7890 +1 123-456-7899 Hal +1 234-567-8901 (unknown) Keith (unknown) +1 456-789-0122 Yasushi +2 345-678-9012 +2 345-678-9011
Multiple instances of the same key will produce combinatorial results. The following:
fa: a x a y a z fb: a p
a x p a y p a z p
And the following:
fa: a b c a d e fb: a w x a y z a o p
a b c w x a b c y z a b c o p a d e w x a d e y z a d e o p
The 0 field in the -o list was adopted from the Tenth Edition version of join to satisfy international objections that the join in the base documents for IEEE Std 1003.2-1992 did not support the ``full join'' or ``outer join'' described in relational database literature. Although it has been possible to include a join field in the output (by default, or by field number using -o), the join field could not be included for an unpaired line selected by -a. The -o 0 field essentially selects the union of the join fields.
This sort of outer join was not possible with the join commands in the base documents for IEEE Std 1003.2-1992. The -o 0 field was chosen because it is an upwards-compatible change for applications. An alternative was considered: have the join field represent the union of the fields in the files (where they are identical for matched lines, and one or both are null for unmatched lines). This was not adopted because it would break some historical applications.
The ability to specify file2 as - is not historical practice; it was added for completeness.
The -v option is not historical practice, but was considered necessary because it permitted the writing of only those lines that do not match on the join field, as opposed to the -a option, which prints both lines that do and do not match. This additional facility is parallel with the -v option of grep.
Some historical implementations have been encountered where a blank line in one of the input files was considered to be the end of the file; the description in this volume of POSIX.1-2017 does not cite this as an allowable case.
Earlier versions of this standard allowed -j, -j1, -j2 options, and a form of the -o option that allowed the list option-argument to be multiple arguments. These forms are no longer specified by POSIX.1-2008 but may be present in some implementations.
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 .