CMD/BAT: поиск в txt файле повторяшихся строк

orchara, пора Вам уже научиться правильно оформлять темы.

Добавьте префикс языка («CMD/BAT: ») в заголовок темы. Оформите код тэгом «code».

Rom5, дождёмся реакции автора на замечание.

"Вырезание" строки действительно реализовывать не сильно удобно - надо перезаписывать весь файл с пропуском строки с ранее определенным номером (например, предварительно в цикле наращивать в некой переменной номер текущей строки). Возможно, что можно обойтись и без "вырезания".

Кстати, для поиска дублей "в тексте ниже" - можно попробовать читать содержимое этого же файла еще одним вложенным циклом "FOR /F" с указанием параметра пропуска определенного количества строк с начала файла (skip=n).

Но мне кажется проще попробовать сделать так:
- после создания Вашего 1.txt, в котором у Вас по файлам только имя+расширения, отсортировать его содержимое в другой текстовый файл командой:

sort 1.txt /o 1_sort.txt

таким образом в 1_sort.txt все дублирующиеся имена будут располагать "одним пакетом";

- для избавления от уникальных имен организовать цикл чтения этого 1_sort.txt, в котором запоминать значение текущей строки (для сравнения) и вести накопление количества повторений значений строк (имен файлов), если при смене имени на новое по прежнему значению было подсчитано более одного повтора - значит в прежнем имени были дубли.

Для вывода дублей с полными путем, можно сделать так:
- в самом первом Вашем цикле выводить данные и с указанием пути текущего файла в еще один файл (1p.txt) :

echo.> 1.txt
echo.> 1p.txt
for /r . %%i in (*.*) do (
    echo %%~ni%%~xi >> 1.txt
    echo %%~pi%%~ni%%~xi >> 1p.txt
)

А для вывода по имени файла его дублей с путями воспользоваться командой поиска вхождений этого имени в наш 1p.txt:

find /I "\имя_и_расширение_дублирующегося_файла" 1p.txt >> dub_p.txt

Подумалось, что будет удобнее использовать не "find", а "findstr". В общем стоит глянуть подсказку "findstr /?" и поискать примеры использования регулярных выражений.

Разве автору достаточно сравнить имена файлов? Мне думается, что ему требуется сравнивать именно сами файлы и выводить дубли, если такие имеются. Хотя этот способ не сработает, если есть две одинаковые композиции (ведь сравнение изначально планировалось для mp3 файлов), но с разными тегами, то они распознаются как разные файлы.

Если откинуть первоначальное требование автора - поиск повторяющихся строк в файле, а сразу подступиться к поиску файлов с одинаковыми именами, то решение "в лоб":

@echo off
set SEARCHMASK=*.*
set SEARCHPATH=%CD%
set WORKPATH=%TEMP%\%RANDOM%_%RANDOM%
md %WORKPATH%\dup
md %WORKPATH%\nondup
for /f "tokens=* delims=:" %%A in ('dir /b /s /on /a %SEARCHPATH%\%SEARCHMASK%') do (
echo "%%A" >> %WORKPATH%\%%~nxA
)
for /f "tokens=* delims=:" %%A in ('dir /b /on /a-d %WORKPATH%') do (
(type %WORKPATH%\%%A | findstr /N "." | findstr /b "2:">nul) && (move %WORKPATH%\%%A %WORKPATH%\dup\%%A 2>&1 >nul) || (move %WORKPATH%\%%A %WORKPATH%\nondup\%%A 2>&1 >nul)
)
echo "Files with duplicate names:"
for /f "tokens=* delims=:" %%A in ('dir /b /on /a-d %WORKPATH%\dup') do (
echo %%A
type %WORKPATH%\dup\%%A
)
ping -n 4 127.0.0.1 >nul
rd /s/q %WORKPATH%

Из недостатков - защиты "от дурака" нет, файлы дожны быть, связка из type, двух findstr и move работает крайне (!) медленно. После запуска смело идите пить чай, разговаривать с девушками и заниматься другими не менее полезными и приятными вещами, правда это - уже оффтоп.
PS.
Писалось и проверялось на Win 7 Pro, на XP и 2k конструкция вида:

(type %WORKPATH%\%%A | findstr /N "." | findstr /b "2:">nul) && (move %WORKPATH%\%%A %WORKPATH%\dup\%%A 2>&1 >nul) || (move %WORKPATH%\%%A %WORKPATH%\nondup\%%A 2>&1 >nul)

может работать не так как надо.

Rumata изящнее, но не без недостатков. Обратите внимание на "выброс" в "dupfiles.txt", сказывается использование more:

^^ по хелпу ясно, что more покажет строку N и (как минимум!) два десятка следущих, в итоге мы получаем опять борбу с дубликатами, уже в результирующем списке дублей.
Как бороться? Навскидку приходит решение через findstr (вместо more) - в итоге ещё один вложенный цикл и пару findstr в придачу. Работать будет, но "аццки" медленно, главные "тормоза" здесь циклы.
Или, ежели есть простой вариант реализации head, можно оставить с more.

Как бонус - сравнение скорости моего и вашего вариантов(findup и findup_2, соответственно), тестовая директория, 245 файлов, 5 уровней вложенности, 15 "дублей" (Win 7 pro, core 2 e5300):

PS H:\repository\releng\3rdparty> foreach ($n in 'findup.cmd', 'findup_2.cmd' ) {(Measure-Command {cmd.exe /r $n}).TotalMilliseconds}
44798,1988
31492,5062

Хотя из-за "разности" итогового списка - сравнивать не совсем корректно, но лаконизм на лицо, порядка 33-35 %.

Возможно это не правильная локализация, и часть фразы

должна была бы читаться

UNDYING. Честно говоря затрудняюсь ответить без примеров. Уж простите за большую порцию оффтопа. Я считаю, что программисты, авторы программ для работы с текстом были мудры, и создали свои программы так, чтобы они правильно считали нумерацию строк текстового файла, начинающуюся с единицы.

Примеры вывода пронумерованных строк исходного файла (unix, cygwin)

seq 11 15 | awk '{ print NR, $0; }'
seq 11 15 | perl -ple '$_ = "$. $_"'
seq 11 15 | sed =

more (unix) - опция +n утверждает "выводить, начиная со строки номер n" (поэтому +0 и +1 эквиваленты)

seq 11 15 | more +0
seq 11 15 | more +1
seq 11 15 | more +2

more (dos) - опция +n утверждает "пропустить n строк" (поэтому +0 выводит с начала файла, +1 пропускает одну строку и печатает, начиная со строки 2. И т.д.)

( for /l %l in ( 11, 1, 15 ) do @echo %l ) | more +0
( for /l %l in ( 11, 1, 15 ) do @echo %l ) | more +1
( for /l %l in ( 11, 1, 15 ) do @echo %l ) | more +2

====

Считаю, что в данном случае рэдмондские волшебники выбрали путь наименьшего сопротивления и считают строки с нуля, что в корне неверно - с нуля можно считать внутренние объекты программы (элемент массива, позиция в строке, позиция в файле и т.д.), но отображаемые объекты (в данном случае строки файла) должны нумероваться натуральными числами.

Не понимаю Вас. Покажите короткий и понятный пример, раскрывающий эту особенность.

Ошибка в моем алгоритме есть. Вернее несовершенство его. Для каждого следующего имени находит дубликаты. Это лишнее. Вот например для списка
10\readme.txt
11\readme.txt
12\readme.txt

на просто вывести этот список. Мой алгоритм пишет
11\readme.txt
12\readme.txt
10\readme.txt

12\readme.txt
11\readme.txt

Это верно, но информация избыточна.

Поправил - сам ошибался (в дискуссиях рождается правда).

Да, согласен. Но представим ситуацию в идеале:

for /f %%a in ('наш_скрипт.cmd C:\Music\*.mp3') do (ren "%%a" "%%~dpa%time%%%~xa")
for /f %%a in ('dir /b/s/a-d/on *.mp3') do (copy "%%a" "%cd%\%%~nxa")

a. ищем дубликаты (для mp3, напимер) и при наличии оных, переименовываем (например, в соотвествии с датой создания или содержимым).
b. копируем все файлы (mp3) (например, на флешку)
на пункте a "спотыкаемся" из-за избыточного вывода.

Очень круто, только косметические изменения, и оно некорректно обрабатывает файлы с "!" в имени:

uniq требует ещё доработки - бывает, "спотыкается" (ищу закономерности) на строках вида:

X:\REPORT.HTML\BACKUP\2011_03_03_13_35_21_250.HTM

Работает очень быстро, хороший код.

Если в ущерб скорости(работает очень медленно), но без создания файлов, то:

@echo off
setlocal enabledelayedexpansion
if "%*" == "" (set mask="*.*") else (set mask="%~1")
(for /f "usebackq tokens=*" %%a in (`
    dir /a-d /b /s %mask%
`) do (
       (dir /a-d /b /s %mask% | find /i /v "%%~a") | (
       (findstr /l /e /c:"\\%%~nxa" 2>&1 1>nul
       ) &&echo.%%~a)))
exit /b 0 & endlocal

Недостаток тот же.

Через создание кучи временных файлов:

@echo off
if "%*" == "" (set mask="*.*") else (set mask="%~1")
set wpath=%temp%\%random%_%random%
md %wpath%\dup
for /f "tokens=* delims=:" %%a in ('dir /b/s/a-d %mask%') do (
    if exist "%wpath%\%%~nxa" (if not exist "%wpath%\dup\%%~nxa" (
        fsutil hardlink create "%wpath%\dup\%%~nxa" "%wpath%\%%~nxa" 2>&1 >nul
    ))
    echo %%a>>"%wpath%\%%~nxa"
)
2>nul type %wpath%\dup\*
2>&1 >nul rd /s/q %wpath%
exit /b 0

Работает шустро и "поддерживает" "!" в именах файлов.
По идее, "спотыкнётся" на символах "%","&" в именах, надо проверить, и для работы требует прав администратора.