The `wc` command calculates the word (or line, character, or byte) count of a file. For from just being a utility for word processing, though, `wc` is a useful tool for a variety of system tasks.

For basic usage, all you need is a file with some text in it. Here's my plan for a zombie apocalypse:

The default output of `wc` is the number of lines, words, and characters, followed by the file path you provided. (With only 188 lines of text in my plan, it's probably time to work on a Plan B.)

Counting items in a directory with wc {#_counting_items_in_a_directory_with_wc}

Many desktop file managers provide a running total of how many items are in a directory.

The Dolphin file manager displays an item count in the lower left corner of its window. [IMG]

The terminal doesn't do that. At least, not by default.

The `-1` (that's the number *one*, not a lower-case L) for `ls` forces `ls` to list files in a single column. Pipe that output to `wc` with its `--lines` option for a count of items:

There are a few caveats to keep in mind. I

alias

my `ls` command to include the `--almost-all` option, which omits the `.` and `..` entries from directory listings. I also have `ls` set to ignore files ending in `~` or `#`, both of which are common added extensions for backup files. Finally, I don't view hidden files by default. That means that my report on the contents of a directory isn't off by two (`.` and `..`) but doesn't include any backup files or hidden files. That's exactly the count I want, but keep those conditions in mind in case you want something different. The `wc` command is parsing the output of your `ls` command, so it believes you even when you "lie" to it.

Detecting hidden characters with wc {#_detecting_hidden_characters_with_wc}

I'm involved with some projects that use an XML toolchain, and sometimes I get bugs filed by users about a file that breaks the process for them. By the time the report gets to me, it's a verifiable mystery. Linters have been run, other people have inspected the file, but nobody can determine the issue. The `--char` option of `wc` shows something suspicious, though:

In most files, there are some non-visible characters. For instance, `wc` sees newlines as valid countable characters. However, 5 characters hardly accounts for the single newline at the end of `ab` (the correct count is 3.)

In practice, this is of limited use if you don't know *where* in a file to look. After all, a report that a file has 758 characters isn't much good without manually counting how many characters it looks like there are. However, if your toolchain provides an error for where it broke, then it's trivial to copy and paste a section from the document into a `wc` command.

In short, using `wc` has been an easy diagnostic step for users that has saved me from having to explain Emacs's `describe-char` to people who aren't used to the

magic of GNU Emacs

.

For the record, here's an example of the fix (the problem was a "soft hyphen" that wasn't visible in the users' text editors):

Get the size of a file {#_get_the_size_of_a_file}

There are lots of ways to get the size of a file. There's `du`, of course, and `ls` (although `ls -l` requires some parsing). Add `wc` to the list.

I haven't encountered a system yet that has `wc` and not `du`, but I *have* encounter implementations of `du` that don't provide the `--bytes` option. So far, the `wc` command has been consistent in its ability to count bytes (although in some implementations, there's only the `-c` short option.)

You can count on wc {#_you_can_count_on_wc}

The `wc` is a simple counter command. It doesn't have any special features and it's not a particularly great demo of what's great about Linux. However, it's a reliable and predictable command that does one thing and does it well. Put it to good use.

Proxied content from gemini://sdf.org/klaatu/geminifiles/wc-command.gmi (external content)

Gemini request details:

Original URL
gemini://sdf.org/klaatu/geminifiles/wc-command.gmi
Status code
Success
Meta
text/gemini
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.