Summary: | wc -L always returns 0 | ||
---|---|---|---|
Product: | Base System | Reporter: | amstrnad+bugzilla |
Component: | bin | Assignee: | Conrad Meyer <cem> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | ||
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
amstrnad+bugzilla
2018-08-02 19:27:05 UTC
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 |