Checklist: POSIX-compliance

[sharkdp]

A lot of people complain that this project is called a "cat(1) clone" [1] [2] [3] [4].

While I disagree with some of these comments, I am wondering how far we actually are from a fully POSIX-compliant cat implementation - because we have already implemented quite a lot of the missing features.

The page about cat in the current POSIX standard seems to imply the following things:

• [x] "The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence."
• [ ] "The cat utility shall conform to XBD Utility Syntax Guidelines" => to be checked.
• [x] "The following option shall be supported: -u (Write bytes from the input file to the standard output without delay as each is read.)" => We follow GNU cat here and simply ignore this option (we do not buffer anyways).
• [x] "The following operand shall be supported: file (A pathname of an input file)"
• [x] "If no file operands are specified, the standard input shall be used."
• [x] "If a file is '-', the cat utility shall read from the standard input at that point in the sequence."
• [x] (continued) "The cat utility shall not close and reopen standard input when it is referenced in this way, but shall accept multiple occurrences of '-' as a file operand." => to be checked
• [x] "The standard input shall be used only if no file operands are specified, or if a file operand is -"
• [x] "The input files can be any file type."
• [x] "Environment variables" section => not sure how to interpret this. I think it is okay to ignore this point if we don't have internationalization support.
• [x] "The standard output shall contain the sequence of bytes read from the input files. Nothing else shall be written to the standard output." => This is a big one :smile:. We are definitely not compliant here if we are writing decorations and syntax highlighting to interactive terminals. However, we are fully compliant whenever we write to a non-interactive terminal (file, pipe, ..), so I feel confident in checking this off.
• [x] "The standard error shall be used only for diagnostic messages."
• [x] "The following exit values shall be returned: 0 (All input files were output successfully.), >0 (An error occurred.)"

Comments

• This is my interpretation of the document. Please let me know if you disagree with some of the conclusions / checkmarks.
• It is important to note that almost all of the command-line options that GNU cat provides (-n, -v, -T, etc.) are not part of the POSIX standard.

Links

• POSIX cat
• GNU coreutils cat
• FreeBSD's cat
• OpenBSD's cat
• Wikipedia on cat

[RivenSkaye]

For proper "drop-in" replacement, one should be able to ln -s /path/to/bat /usr/bin/cat without any existing stuff breaking significantly. Currently there's a few things missing that prevent replacing e.g. scripted usage.

• -b, --number-nonblank: number non-empty output lines only; overrides -n is currently unsupported
  • cat doesn't handle Windows line endings (CRLF, \r\n), but this seems like a cat issue as POSIX is in no way unclear about respecting system line ends.
• -E, --show-ends: display $ for line ends
• -T, --show-tabs: display TAB as ^I
• -s, --squeeze-blank: skip repeated empty lines
• -v, --show-nonprinting: uses ^ and M- notation, but does not print Linefeed and TAB
  • -e: -vE shorthand
  • -t: -vT shorthand
  • bat does support -A: -vET shorthand

As for the XBD Utility Syntax Guidelines I can find some non-compliant behavior for guidelines 3, 10, and 11

1. --list-themes, --diagnostic, and --acknowledgements are not treated as terminators for option reading
   • --list-themes --diagnostic --acknowledgements dumps diagnostic info and ignores the preceeding option
   • --acknowledgements --list-themes prints all themes and does not list acknowledgements
   • other orderings behave as they should, by virtue of order of processing.
2. Not all options are available as a single alphanumeric, though this seems to be the case with more coreutils, so I wouldn't get hung up on this

As for the "Environment variables" section, that refers to the XBD Environment Variables solely for internationalization. This is a missed opportunity in my opinion, as the same document includes things like $HOME and other common variables that may also influence where to search for config files. Coincidentally, this affects things like reading config in an MSYS2 environment which is now telling me that $HOME/.config/bat/config is being ignored entirely. I'll make a separate trackable issue for that.

Getting back to the 8.2 specification bit, these are used for printing messages (including errors) in the user's system locale. Not opting to utilize those should not be an issue as any system errors are propagated from the user-defined language the system already runs in, which is very rarely different from user preferences anyway.