Running `wc -L` on any file returns 0, no matter the contents of the file. If run instead with `wc -Ll`, both the number of lines and the length of the longest line are reported correctly. I found this on an old version of 12-CURRENT (from December), but I confirmed it still exists on r336739.
I believe I broke this in r326736. The fix is straightforward -- skip the fastpath if -L was requested.
Hm, but -L was already broken if -l was requested -- it counted bytes rather than characters.
Ah, ok. It worked before my change, with the caveat that its behavior changes depending on whether -m is also specified or not. This is not really documented in the manual page.
Please try this patch and confirm it fixes the issue for you: https://people.freebsd.org/~cem/pr230300.1.patch E.g., it seems to work for me (UTF-8): No -m (encoding oblivious): $ echo -e "鄕\nbb\nc" | $(make -V .OBJDIR)/wc.full -L 3 (3 bytes to encode "鄕".) With -m (encoding aware): $ echo -e "鄕\nbb\nc" | $(make -V .OBJDIR)/wc.full -Lm 7 2 (7 total characters; longest line was 2 ("bb").)
A commit references this bug: Author: cem Date: Thu Aug 2 23:45:15 UTC 2018 New revision: 337203 URL: https://svnweb.freebsd.org/changeset/base/337203 Log: wc(1): Fix 'wc -L' I inadvertently broke 'wc -L' in r326736. We must skip the fast path if -L was specified, in addition to the existing check for the -l option. Document long-standing -L behavior (count varies depending on whether wc(1) is run with the -m option or not) in wc.1. That behavior dates back to the introduction of the -L option, but was not documented. PR: 230300 Reported by: <amstrnad+bugzilla AT gmail.com> Sponsored by: Dell EMC Isilon Changes: head/usr.bin/wc/wc.1 head/usr.bin/wc/wc.c