Проблема: неожиданное поведение (одиночный дубликат) в цикле FOR.
Я пытаюсь сделать простой интерфейс batch-vbscript для монтирования и демонтажа томов, среди других задач ("Voltask"). Центральная часть функции - уникальная идентификация каждого тома, чего я пытаюсь достичь, анализируя вывод из MOUNTVOL:
\\?\Volume{d35e9775-0176-11d6-a06d-806e6f6e6963}\ H:\ \\?\Volume{d35e9776-0176-11d6-a06d-806e6f6e6963}\ F:\ \\?\Volume{6537febd-01bc-11d6-adb5-806e6f6e6963}\ *** NO MOUNT POINTS *** \\?\Volume{3fb54500-a257-11e4-8d8d-806e6f6e6963}\ *** NO MOUNT POINTS *** \\?\Volume{6537febe-01bc-11d6-adb5-806e6f6e6963}\ C:\ \\?\Volume{6537fec3-01bc-11d6-adb5-806e6f6e6963}\ A:\ \\?\Volume{6537fec1-01bc-11d6-adb5-806e6f6e6963}\ D:\ \\?\Volume{6537fec2-01bc-11d6-adb5-806e6f6e6963}\ E:\
Первый анализ дает некоторым подпрограммам то, что им нужно, и делает данные в целом более удобными для обработки. Каждая соответствующая строка из MOUNTVOL хранится в отдельном номере переменной.
@ECHO OFF & SETLOCAL enabledelayedexpansion & SET count=0
REM Basic parse
FOR /F "usebackq" %%5 IN (`
MOUNTVOL ^| FINDSTR /c:\ /c:*
`) DO (
SET /a count+=1
SET !count!=%%5
)
Следующий шаг - взять этот простой вывод и сделать шаг ближе к объединению соответствующих букв и имен: 1 2 3 4 5 -> 11 12 21 22 31 ... Таким образом, первое число всегда будет представлять один том, а второе - тип данных, соответствующий этому объему, 1 = имя, 2 = буква.
Я пытаюсь добиться этого путем анализа ранее полученных данных с помощью:
FOR /L %%G IN (1,1,%count%) DO (
SET /a ODD=%%G %%2
IF !ODD! EQU 1 (
SET A=%%G
SET /a A-=!C!
SET /a C+=1
SET B=1
)
REM Intentionally not using "ELSE"
IF !ODD! EQU 0 (
SET A=%%G
SET /a A-=!C!
SET /a B+=1
)
SET !A!!B!=!%%G!
ECHO !A!!B! Has Data !%%G!
)
Просто чтобы прояснить арифметику: отсчеты приводят к тому, что A увеличивается с каждым вторым прогоном, а B изменяется от 1 до 2.
Результирующий вывод как показано:
11 Has Data \\?\Volume{d35e9775-0176-11d6-a06d-806e6f6e6963}\
12 Has Data H:\
21 Has Data \\?\Volume{d35e9776-0176-11d6-a06d-806e6f6e6963}\
22 Has Data F:\
31 Has Data \\?\Volume{6537febd-01bc-11d6-adb5-806e6f6e6963}\
32 Has Data ***
41 Has Data \\?\Volume{3fb54500-a257-11e4-8d8d-806e6f6e6963}\
42 Has Data ***
51 Has Data \\?\Volume{6537febe-01bc-11d6-adb5-806e6f6e6963}\
52 Has Data C:\
61 Has Data \\?\Volume{d35e9775-0176-11d6-a06d-806e6f6e6963}\
62 Has Data H:\
71 Has Data \\?\Volume{6537fec1-01bc-11d6-adb5-806e6f6e6963}\
72 Has Data D:\
81 Has Data \\?\Volume{6537fec2-01bc-11d6-adb5-806e6f6e6963}\
82 Has Data E:\
61 и 62 являются дубликатами 11 и 12. Это было бы просто совпадением, поскольку значения% G в этой точной точке также равны 11 и 12. Это привело меня к выводу, что ... я просто не вижу этого.
Является !%%Г! как-то меня неправильно истолковали или я ошибся с подсчетами? Я так долго бился головой об экран, что буду очень признателен за любые советы!
РЕДАКТИРОВАТЬ: После тщательного перерыва я понял, что после %% G проходит 10, конфликты обязательно произойдут как!%%Г! интерпретируется как!11! а также !12 !, которые относятся как к переменным первого, так и второго анализа. Это приводит к дубликатам. Однако остается дилемма: как этого избежать?
Установка другого уровня локализации решит проблему за счет создания других; не представляется приемлемым вариантом. Я мог бы использовать буквы вместо чисел в качестве переменных, но это нарушило бы арифметику. * В настоящее время исследуем использование shift для замены set /a count+= 1 эквивалентом букв, но пока безрезультатно.