82

I have the following three constructs in a bash script:

NUMOFLINES=$(wc -l $JAVA_TAGS_FILE)
echo $NUMOFLINES" lines"

echo $(wc -l $JAVA_TAGS_FILE)" lines"

echo "$(wc -l $JAVA_TAGS_FILE) lines"

And they both produce identical output when the script is run:

121711 /home/slash/.java_base.tag lines
121711 /home/slash/.java_base.tag lines
121711 /home/slash/.java_base.tag lines

I.e. the name of the file is also echoed (which I don't want to). Why do these scriplets fail and how should I output a clean:

121711 lines

?

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
Marcus Junius Brutus
  • 26,087
  • 41
  • 189
  • 331

6 Answers6

160

An Example Using Your Own Data

You can avoid having your filename embedded in the NUMOFLINES variable by using redirection from JAVA_TAGS_FILE, rather than passing the filename as an argument to wc. For example:

NUMOFLINES=$(wc -l < "$JAVA_TAGS_FILE")

Explanation: Use Pipes or Redirection to Avoid Filenames in Output

The wc utility will not print the name of the file in its output if input is taken from a pipe or redirection operator. Consider these various examples:

# wc shows filename when the file is an argument
$ wc -l /etc/passwd
41 /etc/passwd

# filename is ignored when piped in on standard input
$ cat /etc/passwd | wc -l
41

# unusual redirection, but wc still ignores the filename
$ < /etc/passwd wc -l
41

# typical redirection, taking standard input from a file
$ wc -l < /etc/passwd
41

As you can see, the only time wc will print the filename is when its passed as an argument, rather than as data on standard input. In some cases, you may want the filename to be printed, so it's useful to understand when it will be displayed.

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
  • 2
    beware that this approach will not include the last line if the last line does not terminate by end of line character. See my fix below. – ling Oct 18 '15 at 05:33
15

wc can't get the filename if you don't give it one.

wc -l < "$JAVA_TAGS_FILE"
Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • 2
    Well, then don't. Just pass the file to `wc`'s stdin as shown in the answer. So `cat "$JAVA_TAGS_FILE" | wc -l` or, equivalently, `wc -l < "$JAVA_TAGS_FILE"`. This way, `wc` only gets raw data, not the filename. – Witiko Jul 04 '13 at 14:23
12

You can also use awk:

awk 'END {print NR,"lines"}' filename

Or

awk 'END {print NR}' filename

Javier López
  • 823
  • 8
  • 14
6

(apply on Mac, and probably other Unixes)

Actually there is a problem with the wc approach: it does not count the last line if it does not terminate with the end of line symbol.

Use this instead

nbLines=$(cat -n file.txt | tail -n 1 | cut -f1 | xargs)

or even better (thanks gniourf_gniourf):

nblines=$(grep -c '' file.txt)

Note: The awk approach by chilicuil also works.

ling
  • 9,545
  • 4
  • 52
  • 49
  • 3
    Very convoluted method! Maybe you'll want `nblines=$(grep -c '' file)` instead (which is the canonical way of counting incomplete lines in this case). Note though that according to POSIX, you're counting the [incomplete lines](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195) (and not the [lines](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206)). You're in fact dealing with a binary file and not a [text file](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397). – gniourf_gniourf Oct 18 '15 at 06:33
  • @gniourf_gniourf Thanks, I didn't know about that, it works great and is even more concise. – ling Oct 19 '15 at 07:39
  • it maybe better solution `nblines=$(($(cat "file.txt" | wc -l) + 1))` – Andrey Izman Sep 09 '16 at 23:52
3

It's a very simple:

NUMOFLINES=$(cat $JAVA_TAGS_FILE | wc -l )

or

NUMOFLINES=$(wc -l $JAVA_TAGS_FILE | awk '{print $1}')
Slava Semushin
  • 14,904
  • 7
  • 53
  • 69
-3

I normally use the 'back tick' feature of bash

export NUM_LINES=`wc -l filename`

Note the 'tick' is the 'back tick' e.g. ` not the normal single quote

fejese
  • 4,601
  • 4
  • 29
  • 36
  • 5
    That's just a different notation, and doesn't solve the issue of the file name being part of the result. – Izzy Jan 01 '15 at 19:57