Ошибка в используемых средствах.
Сделай так:

wc -l 100.txt; head -n `egrep -c "*" 100.txt` 1000.txt > new.txt; wc -l new.txt;

Сам же видишь, что твоя команда `wc -l 100.txt` выводит не одно число, а ещё и имя файла.

проблема-то...
wc -l tags | sed 's/ .*//'

да ладно! найти во всём файле все любые строки и вывести их число...
Кроме того:
1. egrep устарела, и её уже много лет НЕ рекомендуют использовать. Все, кроме некоторых слоупуков.
2. я не смог распарсить ваш хитрый регексп "*". даже если и есть такое расширение, то в общем случае это как минимум нестандартно, а скорее всего - ошибка. Ибо звёздочка это квантификатор количества, и сама по себе смысла НЕ имеет. Это как деление на ноль.

А это - пожалуйста:

sed '$=;d'

я и не использую, во избежание проблем. И другим не советую. И советовать не советую тоже.

ъ
твоя сегодня распарсила. Это не говорит о том, что не твоя и/или не сегодня распарсит. Любой быдлокод тоже прекрасно работает... На машине быдлокодера при тестовом прогоне. Часто он работает и в продакшене. Это хорошо?

проблема быдлокода в том, что он проходит тестирование. Если калькулятор при попытке деления на ноль выдаёт "бесконечность", то это калькулятор от микрософт. Возможно в десктопе среднестатистического МД это допустимо, но в продакшене быть такого не должно (но таки есть, спасибо советчикам).

cat + sed никто не предлагал. В данном случае вся нагрузка ложится на первую команду, которая и считает строки. Но wc -l только считает строки, а grep -E '*' ещё и ищет ошибочный регэксп в строке. Очевидно это дольше. Можешь сам проверить на большом файле (возможно получится одинаково, если бутылочное горло будет на io HDD).
sed в моём примере всего-лишь исправляет вывод одной строки, и временем её работы можно пренебречь.

ЗЫЖ и да, баш тут вообще не причём.