Paul Eggert <[EMAIL PROTECTED]> wrote:
> Anyway, I noticed on glitch in the merged version; here's a patch.
>
> 2003-07-20 Paul Eggert <[EMAIL PROTECTED]>
>
> * src/wc.c (get_input_fstatus): Fix typo: `stat' was being
> invoked with a null pointer when there were no file arguments.
Jim Meyering <[EMAIL PROTECTED]> writes:
> Not that it matters, but in some unusual cases,
> the new widths are worse than the old:
>
> $ dd bs=1 seek=1G of=b < /dev/null 2> /dev/null
> $ ./wc -lw b
>0 0 b
> $ wc -lw b
> 0 0 b
Yes, that's true. The only
Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> However, I agree with you that the leading spaces are annoying; this
> has bitten me as well, in other examples. I looked into this, and it
> turns out that the coreutils documentation is incorrect about what
> POSIX requires for 'wc'. When this misund
Daniel Russell <[EMAIL PROTECTED]> writes:
> [ `cat autolist-next.num` -gt `wc -l autolist.txt` ]
That's easy enough to fix by using `wc -l
wc count field widths now are heuristically adjusted depending
on the input size, if known. If only one count is printed, it
is gu
Daniel Russell <[EMAIL PROTECTED]> wrote:
> Using wc in scripts is annoying because of the fact that this:
>
> wc -l/m/c FILENAME
>
> prints this:
>
> NUMBER FILENAME
Removing the filename is easy enough:
wc -l < FILENAME
paul
___
Bug-coreut
Using wc in scripts is annoying because of the fact that this:
wc -l/m/c FILENAME
prints this:
NUMBER FILENAME
And there appears to be no options to turn this behavior off. Of course,
I would like to use wc a lot in scripts, without having to pipe into it.
I would like to have no lead