5

I was trying to get only the number of words in a file using wc. wc -w file.txt gives me that plus the file name. I don't want the file name. So, I saw that wc -w < file.txt works.

I don't understand how this command works. I cannot even add a comment below the answer where I saw this command.

Why does it not print filename in the case of wc -w < file.txt?

Community
  • 1
  • 1
Steam
  • 9,368
  • 27
  • 83
  • 122

3 Answers3

5

wc -w will output the word count and file name for each of its arguments. So the command wc -w myfile.txt will give you something like:

42 myfile.txt

However, where wc doesn't know the filename, it simply outputs the count. You can hide the file name from it by using input redirection as wc is one of those commands that will read standard input if you don't explicitly name a file. This can be done with:

wc -w <myfile.txt

or:

cat myfile.txt | wc -w

although the latter is inefficient in this case and better where the input is more complex than just the contents of some file.

The reason that wc doesn't know the file name in wc -w <myfile.txt is because the shell opens the file and attaches it to the standard input of the wc process. The shell also never passes the <myfile.txt along to the wc program's command line arguments. Many programs like wc have code along the lines of:

FILE * infile;
if (argc == 0)
    infile = stdin;
else
    infile = fopen (argv[1]], "r");

to select either standard input or open a known file name. In the former case, no name is available to the program.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • Please see my edit. Sorry that I did not explain my problem clearly. I don't understand why wc does not know the filename. It is being told to read from file using < file.txt, right ? – Steam Aug 05 '13 at 22:05
  • @blasto no, the `<` tells _your shell_ to connect stdin to the file **before starting `wc`**; `wc` doesn't know where its stdin is coming from, because that was done by the shell beforehand. – Charles Duffy Aug 05 '13 at 22:09
  • The shell does not "open the file and send the contents". The shell arranges it so that the file *is* the stdin of the process. "sends the contents" implies a data copy that does not happen. – William Pursell Aug 06 '13 at 02:22
4

This works because when you use < the shell is sourcing the contents of "file.txt" to the standard input of wc.

Also, note that wc -l will give you the number of lines in file.txt. If you really want the number of words irrespective on which line they are, you should use wc -w instead.

When you used wc -w file.txt it gave you the number of words inside "file.txt" and the filename because wc accepts many files as possible inputs, so it outputs the filename after the word count for you to know that file has those many words. For example, suppose you have these two files with their respective contents:

twoword.txt: foo bar

threeword.txt: foo bar test

then wc -w twoword.txt threeword.txt would give you:

2 twoword.txt
3 threeword.txt
5 total

thus showing how many words are there in each file then summing up them for total.

Claudio
  • 2,191
  • 24
  • 49
  • 1
    Sorry to be a nitpick, but you're not telling `wc` anything, you're telling the shell to take the contents of `file.txt` and shove it in stdin (i.e. file descriptor `0`) of `wc`. – mvds Aug 05 '13 at 22:03
  • Please see my edit. Sorry that I did not explain my problem clearly. – Steam Aug 05 '13 at 22:03
  • @mvds - that is what i was looking for. I don't know these internals of unix. I only try to make scripts to do tasks. Consider putting your comment as an answer. – Steam Aug 05 '13 at 22:06
  • @blasto have a look at the other answers, they address exactly this topic. – mvds Aug 05 '13 at 22:08
  • Yeah @mvds, technically you are correct. I'll edit that part. – Claudio Aug 05 '13 at 22:11
  • 1
    @mvds Not quite. The shell is not 'shov[ing]' data to stdin. The shell is `dup`ing fd 0 of the child so that the file *is* stdin. There is no additional data copy or movement of the data in the file. The shell does not "pipe" the data to stdin. The shell makes it so that stdin of the process *is* the file. – William Pursell Aug 06 '13 at 02:19
  • @WilliamPursell I'd say it would `dup2` the fd? Anyway, I suspect this is implementation defined, as long as the child process reads the file data from fd 0 one way or another? – mvds Aug 06 '13 at 09:23
3

In your example, when the shell creates a process for wc, it opens file.txt with the file descriptor 0 for stdin. Read up on what stdin, stout and stderr are here: Confused about stdin, stdout, and stderr

The man page for wc defines the behavior with no file parameter.

wc is reading the contents of file.txt from stdin and printing the number of words. It doesn't print the file name because it doesn't know what the file name is when it reads from stdin.

seanmk
  • 1,934
  • 15
  • 28
  • The contents of `file.txt` are not "sent to stdin". The file *is* stdin of the process. "Sent to" implies a data copy that does not happen. – William Pursell Aug 06 '13 at 02:20