GNU bug report logs - #61300
wc -c doesn't advance stdin position when it's a regular file

Previous Next

Full log

Message #14 received at 61300 <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane <at> chazelas.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 61300 <at> debbugs.gnu.org
Subject: Re: bug#61300: wc -c doesn't advance stdin position when it's a
 regular file
Date: Mon, 06 Feb 2023 06:27:02 +0000

On 2023-02-05 20:59, Paul Eggert wrote:
> On 2023-02-05 11:59, Pádraig Brady wrote:
[...]
> Let's leave that as-is, please. If 'wc' can output the correct value
> without reading its input, POSIX does not require 'wc' to do the read,
> and it seems perverse to modify 'wc' to go to the effort to refuse to
> tell the user useful information that the user requested and that 'wc'
> knows.
[...]

But while I would agree it's very unlikely to ever be hit in practice,
as I can't think of any reason why one would call wc with its input not
input for reading, wc is meant to report how many bytes it has read, not
the size of its input (though POSIX seems ambiguous on that).

See also (with Pádraig's patch applied):

$ { echo test > file; wc -c; echo test2 >&0; cat file; } 0> file
5
test
test2

wc has lseek()ed to the end of the file even though it was opened in 
write-only mode. Compare with:

$ { echo test > file; wc -lc; echo test2 >&0; cat file; } 0> file
wc: 'standard input': Bad file descriptor
0 0
test2

-- 
Stephane

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.