» Командная строка, батники, сценарии (bat, cmd)

thejustsoul

Цитата:

и надо ли

Надо.

Цитата:

обращаться к переменной CHANGE как "%CHANGE%" или как "!CHANGE!"

Как !Change!. И дело не только в скобках, а и во включенном delayed expansion.

GCRaistlin

Цитата:

Немного - что?

Не того, ни этого ... см.далее


Цитата:

при включенном delayed expansion используете %-раскрытие, со всеми вытекающими.

Хмм...
1. Это запрещено?
2. Какие вытекающие? EnableDelayedExpansion, всего лишь разрешает применение "!" в качестве разделителя и соответственно расширение переменных в виде !var!, но это отнюдь не запрещает применение %-раскрытия... то бишь, при определенном использовании расширений переменных и наличии "!" в пути, есть вероятность "утери" в сценарии реальных папок и файлов
3. Кроме того, setlocal делает все переменные локальными...

Это всё к тому, что это:

Цитата:

Как !Change!.

не аксиома, хотя, чаще всего, предпочтительно именно такое использование.
Кстати, вроде бы, мы тут совсем недавно беседовали на тему последовательных раскрытий %% vs !!, в одной строке - помните результаты тестов?

Добавлено:
thejustsoul

Цитата:

Код: if exist CHANGE (
    for /F "delims=" %%i in (CHANGE) do set CHANGE=%%i
)

 тут (за скобками) обращаться к переменной CHANGE как "%CHANGE%" или как "!CHANGE!"  ?

Цитата:

1. Это запрещено?

Не запрещено, но если значение переменной может содержать "!", то, сами понимаете, %-раскрытие использовать не следует. Именно чтобы не было упомянутой "утери".


Цитата:

это ... не аксиома

Не аксиома, но ситуации, где предпочтительнее использовать call-раскрытие, весьма специфичны. В данном случае однозначно рекомендуется !-раскрытие. В т. ч. по соображениям производительности.

Добавлено:
YuS_two

Цитата:

Тут, за скобками, Вы получите значение переменной из последней итерации, в любом варианте. И в таком именно применении, вовсе нет необходимости включать отложенное расширение

Только не забывайте, что значение переменной будет взято из файла. Соответственно, может содержать любые символы. И при %-раскрытии (как и при call-раскрытии, кстати) парсеру от них может поплохеть.

GCRaistlin

Цитата:

если значение переменной может содержать "!", то, сами понимаете, %-раскрытие использовать не следует. Именно чтобы не было упомянутой "утери".

И всё таки, !-раскрытие, это не панацея, а в некоторых случаях и вовсе неприменимо ... говорю же, не того, ни этого
Чтобы не быть голословным, я расширил пример немного:

Код: @echo off
rem пример пути к файлу: c:\!!111ОдинОдинразраз\
set fil=file.txt
setlocal enabledelayedexpansion
if not defined pap (set /p pap="Введите абсолютный путь к файлу: ")
rem ===============================================================
if exist "%pap%%fil%" (
echo 1. Файл существует
echo 1. %pap%
call :test "1. %pap%"
) else (
echo 1. Индейская хижина
echo 1. %pap%
call :test "1. %pap%"
)
if exist "!pap!!fil!" (
echo 2. Файл существует
echo 2. !pap!
call :test "2. !pap!"
) else (
echo 2. Индейская хижина
echo 2. !pap!
call :test "2. !pap!"
)
pause&&exit
:test
echo "%~1"
exit /b

YuS_two

Цитата:

если отключить отложенное расширение, то первый вариант корректно работает во всех случаях... в отличие от второго, где вызов call ни в одном случае корректно работать не будет.

Потому что вызываемая подпрограмма некорректно написана: вы используете %-раскрытие при неизвестном состоянии delayed expansion. Явно отключите его в начале подпрограммы - и все будет работать.


Цитата:

Не очень-то они специфичны, см.выше.
"call :metka param" - достаточно часто применяется изнутри цикла...

Под call-раскрытием я подразумеваю синтаксис вроде "call echo %%var%%". Его использование оправдано при тройном раскрытии переменной, а также когда нужно отложенное раскрытие, но нельзя использовать !-раскрытие (например, если делаем замену и подстрока сама может содержать "!"). Прямо скажем, нетривиальные ситуации.


Цитата:

это уже не совсем моя "головная боль", как дающего рекомендации, ведь код составлял не я

Так рекомендация-то неверна: нельзя раскрывать через "%" переменную, потенциально содержащую хрен знает что. И конкретный код здесь ни при чем.

GCRaistlin

Цитата:

Потому что вызываемая подпрограмма некорректно написана: вы используете %-раскрытие при неизвестном состоянии delayed expansion. Явно отключите его в начале подпрограммы - и все будет работать.

Да ладно!? И что там некорректного?
Ну, а если серьезно, то вопрос-то был в !-раскрытии, пример был под него сделан... понятно, что при отключенном (это состояние по умолчанию) отложенном расширении, %-раскрытие будет работать, как впрочем и при включенном. Ещё раз: вопрос был в !-раскрытии...


Цитата:

Под call-раскрытием я подразумеваю синтаксис вроде "call echo %%var%%".

Call-раскрытие, это миф. Call просто осуществляет двойной проход, вот и всё, а двойное раскрытие - это уже следствие этого.


Цитата:

Его использование оправдано при тройном раскрытии переменной, а также когда нужно отложенное раскрытие, но нельзя использовать !-раскрытие (например, если делаем замену и подстрока сама может содержать "!")

А с чего у нас тут дискуссия развилась?

Цитата:

А если в переменной записан путь, который содержит восклицательные знаки?

Ок, если расширенный пример написать конкретнее:

Код: @echo off
rem пример пути к файлу: c:\!!111ОдинОдинразраз\
set fil=file.txt
setlocal enabledelayedexpansion
if not defined pap (set /p pap="Введите абсолютный путь к файлу: ")
rem ===============================================================
if exist "!pap!!fil!" (
call :test "2. !pap!"
)
pause&&exit
:test
echo "%~1"
exit /b

YuS_two

Цитата:

Call-раскрытие, это миф

Я просто подыскал этому синтаксису название покороче. Можно было назвать и "%%-раскрытием", но из-за того, что этим термином часто называют %-раскрытие, возможна путаница.

Цитата:

А если в переменной записан путь, который содержит восклицательные знаки?

В значении переменной может быть что угодно - это никак не мешает раскрывать ее по "!". А я говорил о наличии "!" в имени переменной. Вам часто приходится использовать такие переменные?

Цитата:

!-раскрытие, это не панацея

С данными мною выше оговорками - именно панацея. Более того: если нельзя гарантировать, что в значении переменной отсутствуют "запрещенные" символы (а в вашем примере это именно так), раскрывать ее следует только по "!".

Цитата:

Т.е. Вы предлагаете не давать никаких рекомендаций, пока вопрошающий не опишет полностью все условия?

Все дано в начальном коде вопрошающего: значение переменной Change получается из файла - значит, раскрываем ее только по "!".

Цитата:

нельзя - всего лишь, ничем не подтверждённый запрет.

Подтвержденный вашим же примером.

Цитата:

А интерпретатор консоли, вообще капризная и взбалмошная дама, которая падает в обморок на каждый чих

Абсолютно некорректная аналогия. В отличие от дамы, тонкие места интерпретатора известны и обходимы, причем, как правило, отнюдь не монструозными конструкциями. В основом - тем самым !-раскрытием, которое вы почему-то столь не любите.

Цитата:

Почему состояние не определено?

Потому что при первом вызове оно выключено, а при втором - включено. Это и называется "неизвестно". И явно выключать его перед использованием %-раскрытия - это как окавычивать на всякий случай имена файлов. Или стирать за собой временные файлы. Или мыть руки перед едой. Ведь без всего этого во многих случаях можно обойтись, не правда ли?

GCRaistlin

Цитата:

В значении переменной может быть что угодно - это никак не мешает раскрывать ее по "!".

Это вполне может быть, но с выполнением определенных условий... опять же.

Цитата:

Вам часто приходится использовать такие переменные?

Вообще не приходится Хватает фантазии на сочинение чего-нибудь более приемлемого...

Цитата:

С данными мною выше оговорками - именно панацея.

Если бы это было так, то никакого %-раскрытия не понадобилось бы вовсе... ну на кой столько лишних проблем? И раннее связывание, и проблематичный ввод спецсимволов и прочее-прочее... зачем это всё, если существует !-раскрытие?
А, наверное, потому они необходимы, что нехороший микрософт забыл про %1, реализуя отложенное расширение? шутка

Цитата:

значение переменной Change получается из файла - значит, раскрываем ее только по "!".

Есть какие-то официальные рекомендации-источники? Вообще, при чтении различных источников, сложилось мнение, что изначально !-раскрытие добавлено для помощи обхода раннего связывания переменных, т.к. при первом чтении строки происходит раскрытие переменных и становится проблематично их использовать... а остальное - вторичные бонусы. Ну.да ладно, это не принципиально.

Цитата:

В основом - тем самым !-раскрытием, которое вы почему-то столь не любите.

Разве я где-то делал подобные заявления? Вовсе нет и с большой охотой использую. Но ведь, опять же, если бы !-раскрытие было бы панацеей, то зачем бы нужна была возможность %-раскрытия, в том числе и двойная...
Но да, чаще предпочитаю именно %. Да, кстати, вот порылся и нашел, отчасти ещё из-за этого предпочитаю %, хоть "!-раскрытие" двойное именно (не просто последовательное раскрытие двух переменных в строке, а именно двойное) и быстрее, чем %...
Всего лишь, пытался показать, что путей решения имеется числом более одного...


Цитата:

Потому что при первом вызове оно выключено, а при втором - включено. Это и называется "неизвестно".

Что-то я перестал понимать причину и следствие. На пальцах можно показать, что к чему?


Цитата:

В отличие от дамы, тонкие места интерпретатора известны и обходимы, причем, как правило, отнюдь не монструозными конструкциями.

Имхо, дискуссия переходит в область философского спора... пора её закруглить
Тем не менее, не станете же Вы спорить с тем, что в более совершенных языках некоторые вещи пишутся парой команд или строк, которые в cmd уже требуют "пары страниц кода"? В общем-то, это даже не мое личное мнение, вернее не только мое...

YuS_two

Цитата:

Это вполне может быть, но с выполнением определенных условий... опять же.

Нет, на сей раз - без всяких условий. Просто - что угодно, и всё.

Цитата:

Вообще не приходится

Что подтверждает мои слова - сфера применения call-раскрытия очень специфична, и при разборе простых случаев о возможности применения этого тормозного костыля можно не упоминать вовсе.

Цитата:

Если бы это было так

Вы, кажется, по-прежнему ставите это под сомнение? Можете опровергнуть мои слова на примере?

Цитата:

никакого %-раскрытия не понадобилось бы вовсе... ну на кой столько лишних проблем? И раннее связывание

Раннее связывание - это не проблема, а удобная фича, без которой иной раз не обойтись.

Цитата:

проблематичный ввод спецсимволов

Во многих случаях спецсимволам в переменных взяться неоткуда, и тогда удобнее пользоваться %-раскрытием. Опять же, у замены через !-раскрытие есть существенные ограничения по сравнению с %-раскрытием.

Цитата:

и прочее-прочее...

Что за "прочее"? Вроде нет больше ничего.

Цитата:

Есть какие-то официальные рекомендации-источники?

Можно подумать, официальность что-то добавляет истинности утверждения. Если вы с ним не согласны - попробуйте опровергнуть. Если не получается - может, с ним просто стоит согласиться?

Цитата:

при чтении различных источников, сложилось мнение, изначально !-раскрытие добавлено для помощи обхода раннего связывания переменных... а остальное - вторичные бонусы

Это исключительно проблема источников, которые упускают из виду важный аспект. Вообще, для проверки любого скрипта "на вшивость" есть простой тест: подсунуть ему в качестве параметра

Код:
)"&

GCRaistlin

Цитата:

Нет, на сей раз - без всяких условий. Просто - что угодно, и всё.

Увы, это не так... глобальные и локальные переменные несколько отличаются друг от друга. Просто хотелось увидеть возможность передачи значений от одного другому... естественно, с помощью !-раскрытия. Это не утверждение, а вопрос...

Цитата:

при разборе простых случаев о возможности применения этого тормозного костыля можно не упоминать вовсе.

Спорное утверждение, как раз таки относительно простых случаев, не требующих высокой производительности.

Цитата:

Опять же, у замены через !-раскрытие есть существенные ограничения по сравнению с %-раскрытием.

Так, стоп, я ничего не понимаю уже... то !-раскрытие - панацея, то есть у него ограничения... надо где-то уже поискать истину в золотой середине, имхо.

Цитата:

Можете опровергнуть мои слова на примере?

Я больше вопросы пытаюсь задавать и стараюсь поменьше сыпать утверждениями, в виду малого количества знаний в предмете обсуждаемого вопроса. А сомнению я подвергаю всё, для чего не увидел доказательств. Истинность утверждения должна быть подтверждена более весомыми доказательствами, чем простецкими "нельзя" и "можно"... ну, это по моему личному имхо, естественно.

Цитата:

Можно подумать, официальность что-то добавляет истинности утверждения.

Официальное руководство в применении - хоть какое-никакое, но доказательство. Но пока не попадалось, увы.

Цитата:

Если вылетит - значит, защита от дурака ни к черту.

А для чего существует экранирование? И для чего создано различное использование из командной строки и из пакетного сценария? Вот, нет четкого понимания и всё тут... и руководств никаких, кроме эмпирического опыта...

Цитата:

Подпрограмма у вас вызывается дважды. В первый раз - при выключенном delayed expansion, во второй - при включенном.

Так, стоп... а можно процитировать, где включено и где выключено? Т.е о какой подпрограмме речь? Особенно, в первоначальном варианте.
Если не ошибаюсь,у меня там четвертой строкой:

Код: setlocal enabledelayedexpansion

YuS_two

Цитата:

глобальные и локальные переменные несколько отличаются друг от друга. Просто хотелось увидеть возможность передачи значений от одного другому...

Код:
setlocal enabledelayedexpansion
set /p "String=Enter a string: "
for /f "delims=" %%A in ("!String!") do (
endlocal
set String=%%A
)
set String

GCRaistlin

Цитата:

То есть если некое утверждение никак не получается опровергнуть, какие эксперименты ни приводи, - это еще ничего не значит. А вот если то же самое будет написано в некоем "официальном руководстве" - это да... Смешно немножко.

Нет, не так. Теперь уже Вы преувеличиваете... видимо, для того чтобы стало смешно немножко?
Все мои попытки "опровержения" - всего лишь вариант поиска истины. Хотите процитирую Ваши утверждения, из-за которых, собственно и появляется желание найти "официальное руководство":

Цитата:

Как !Change!. Можете также почитать справку к SET.

Цитата:

Никакой проблемы нет. !-раскрытие происходит один раз. Вот если имя переменной содержит их, тогда да...

Цитата:

Немного - что? В первом случае вы при включенном delayed expansion используете %-раскрытие, со всеми вытекающими. При !-раскрытии все хорошо.

это изначальные Ваши ответы, причем идущие подряд. Поясню: не вижу здесь ни результатов экспериментов, ни вообще, что-либо заслуживающее доверия "на слово", ибо утверждения базирующиеся только на личном опыте и озвученные без каких-либо примеров, никак не могут являться доказательствами. Поэтому и ведется поиск официальных источников, особенно после подобных утверждений. Так что, смеяться можно конечно, но это никак не увеличит весомость всякого рода заявлений.


Цитата:

Я объяснил, почему "нельзя".

Это только потом стали появляться объяснения с примерами, когда моё природное занудство заставило Вас их сделать.
Надо быть последовательным.


Цитата:

Оно не "создано для чего-то", а обусловлено внутренней логикой интерпретатора.

Т.е. программисты из микрософта, живут и работают по принципу Портоса "я дерусь, потому что дерусь"? Ну, конечно в переводе относительно программирования...
Нет, не думаю. То, что "обусловлено внутренней логикой интерпретатора", именно создавалось для чего-то и предполагалось, что будет использовано так или иначе. Разве нет? Причинно-следственные связи ведь должны существовать, имхо, они ведь не совсем дебилы там...


Цитата:

вы точно знаете, что delayed expansion включен, и ленитесь его отключить перед %-раскрытием. Ну что тут сказать - ССЗБ.

Никакой я не буратино и тем более не лентяй , просто это лишний пример про "платочек на каждый чих" и ведь если код достаточно сложный, то необходимо помнить все эти платочки (то логика у интерпретатора разная в зависимости от ситуации, то синтаксис не позволяет использовать спецсимволы, то экранировать особенные символы надо так, а другие иначе, то различный errorlevel на одну команду, в зависимости от .bat или .cmd и т.д., и т.п.) и применять там где возникает в них потребность, а где они мешают, их надо убирать-выключать и т.д. ... и всё это, вместо того, чтобы просто написать программу для какой-либо задачи, причем без лишних "тараканов" в голове.
Кстати, про экранирование, вот пример веселого синтаксиса от микрософта:

Цитата:

Код: for /f "delims=" %%a in ('^<"file.txt" find ^^"^%%f^%%"') do echo %%a

GCRaistlin
Возвращаясь к написанному ранее:

Цитата:

Ну, про "пару страниц" вы явно загнули.

Появилась мысль замерить пропорции на живых примерах. Как Вы думаете, вот такая простая консольная программка (игра крестики-нолики, отсутствие вирусов гарантирую, а также работу, как минимум, на XP и выше, на более ранних не проверял), сколько займет строк кода в cmd-реализации? Если оценить сразу сложно, могу исходники выдать... чтобы было проще сравнивать.

Цитата:

У скриптов cmd.exe главное преимущество - то, что они работают из коробки и одинаково во всех ОС начиная с NT, а их интерпретатор имеет смешной размер. Какой "более совершенный" язык может таким похвастаться? Никакой. И не сможет никогда.

Имхо, главное преимущество в открытости - всегда можно посмотреть, а не format ли c: там прописан. Ну и возможность подкорректировать, если вдруг что-то не устраивает.
А смешной размер - нынче в преимуществах не ходит.

YuS_two

Цитата:

это изначальные Ваши ответы, причем идущие подряд. Поясню: не вижу здесь ни результатов экспериментов, ни вообще, что-либо заслуживающее доверия "на слово"

Первый ответ - это ответ вопрошающему; он требовал только совета, а не его обоснования. Второй - уж вы, я думаю, в состоянии проверить его истинность:

Код:
set var=!windir!
setlocal enabledelayedexpansion
echo !var!

GCRaistlin

Цитата:

Вы ведь разницу в работе FOR имели в виду?

Да нет, я имел в виду, что в синтаксисе вообще нет упорядоченности... ну, да, это можно называть особенностью языка, но речь-то о том, что эта особенность странная и хаотичная.


Цитата:

Так вот, в скрипте FOR явно перечитывается дважды, а FOR-переменные раскрываются при втором проходе (что подтверждается их нечувствительностью к спецсимволам) - поэтому для них и требуется удвоение "%". Почему так реализовано - наверняка, не копаясь внутри cmd.exe, говорить сложно, но, полагаю, из соображений лаконичности/производительности кода интерпретатора - досовского command.com, из которого эта логика, по соображениям совместимости, и перекочевала в cmd.exe. Обычная история.

Эта обычная история открывается просто, один cmd-джедай с киберфорума подсказал:
Команда, результат вывода которой разбирается в цикле, всегда выполняется в новом процессе интерпретатора, отсюда и двойное раскрытие.
Как доказательство, можно запустить такую конструкцию:

Код: @echo off
set x=Windows
for /f "delims=" %%a in ('dir "c:\" ^|find "%%x%%"^& wmic process where name^='cmd.exe' get commandline/value') do echo.%%a
pause

YuS_two

Цитата:

Будем осуществлять?

Задачка интересная, конечно, только где время найти... Кстати, компьютер у вас играет не идеально: в ситуации, когда он начинает, а человек ходит в 1, можно свести партию в ничью. А если ходить в 7 - уже гарантированно проигрываешь. Хотя какая, казалось бы, разница?

GCRaistlin

Цитата:

Кстати, компьютер у вас играет не идеально: в ситуации, когда он начинает, а человек ходит в 1, можно свести партию в ничью. А если ходить в 7 - уже гарантированно проигрываешь.

Да, уровень ИИ там ниже плинтуса, это скорее просто демо-пример из книжки, немного адаптированный к русской локали. А алгоритмы там не мои вовсе.
Кстати, там есть ходы, которые 100% приводят к выигрышу человека... Всё это можно конечно улучшать и усложнять, но не было такой цели особо...

Возможно ли в batch многоходовочное использование условий как на баше, в случае elif ? Т.е. ступенчатая проверка на соответствие условию, т.е. не совпало с а, пробуем b, не совпало с b, пробуем c ... Если совпало, выполняем команду, пропускаем последующие условия (нижнего уровня) и продолжаем скрипт дальше.

Пока я знаю только такую вариацию if на bat в win - if %b%==%a% start2.bat, но это одноходовка, есть ли описанный в начале поста вариант ?

Baltazar500
Цитата:

if %b%==%a% start2.bat

Цитата:

if %b%==%a% start2.bat else if %c%==%d% start3.bat

В своем батнике, в самом начале, использую команду:

Код: MODE CON COLS=90 LINES=38

boss911

Цитата:

да и еще окно заползает под панель задач

Этого быть не должно - если число LINES больше высоты экрана, увеличивается только размер буфера. См. http://stackoverflow.com/questions/4692673/how-to-change-screen-buffer-size-in-windows-command-prompt-from-batch-script

GCRaistlin

Цитата:

Этого быть не должно - если число LINES больше высоты экрана, увеличивается только размер буфера.

Если количество строк больше экрана, появляется буфер в окне, это да. Но консольное окно, после запуска батника, всегда имеет разное положение, в моем случае (количество строк больше экрана), окно всегда запускается с отступом от левого и верхнего края, нижняя часть окна заползает под панель задач и эта часть равна размеру отступа от верхнего края экрана, то есть окно каждый раз надо подымать выше, чтобы оно вписалась по высоте (от верхней точки экрана и до панели задач). Такое поведение на ХР, как там на других ОС, не знаю, не проверял. Как не крути, но я не хочу размер высоты окна на всю высоту экрана.

Нашел полурешние: вывод выхлопа в MORE -

Код: MODE CON COLS=90 LINES=38
command | MORE

Pasha_ZZZ, премного благодарен

boss911

Цитата:

Можно ли всю метку перенаправить в MORE?

Код:
@echo off
if _%Redir% == _ (
set Redir=1
cmd /c call %0 | more
exit /b
)
dir %SystemRoot% /s

boss911

Цитата:

Но консольное окно, после запуска батника, всегда имеет разное положение, в моем случае (количество строк больше экрана), окно всегда запускается с отступом от левого и верхнего края, нижняя часть окна заползает под панель задач и эта часть равна размеру отступа от верхнего края экрана, то есть окно каждый раз надо подымать выше, чтобы оно вписалась по высоте (от верхней точки экрана и до панели задач). Такое поведение на ХР, как там на других ОС, не знаю, не проверял. Как не крути, но я не хочу размер высоты окна на всю высоту экрана.

Запускается оно с отступом и в разных положениях потому, что включен автоматический выбор положения окна.
Вызываем консольное окно, выставляем положение по верхнему краю как требуется, далее клик в левом вернем углу на окне: Свойства->Расположение -> здесь настраиваем по своему вкусу размеры и буфер, отключаем автоматический выбор положения окна и кликаем "OK". Получаем модальное окно с вопросом на применение свойств к текущему окну, либо ко всем окнам, выбираем "для других окон с тем же именем". Далее уже запускаем сценарии с измененными параметрами колонок и строк, окно будет оставаться там, где ему предписано...

YuS_two

Цитата:

клик в левом вернем углу на окне: Свойства

Мне нужно настроить окно только для текущего батника и чтобы эти настройки окна работали на всех компах, то, что вы предлагаете, это только для текущей машины и для всех либо конкретного окна. Можно, конечно, править глобальные настройки окна CMD в реестре, потом возвращать их из бекапа, но такой костыль мне не по душе.

---

GCRaistlin

[more=Примерная конструкция моего батника]
Код: @Echo off
MODE CON COLS=90 LINES=38
SETLOCAL EnableDelayedExpansion

commands

if _%Redir% == _ (
set Redir=1
cmd /c call %0 | more
)

CALL:Choice

commands

CALL:Other

PAUSE
EXIT

:Choice
ECHO Massage...
dir %SystemRoot% /s
ECHO Massage...
GOTO:EOF

Цитата:

Мне нужно настроить окно только для текущего батника и чтобы эти настройки окна работали на всех компах

boss911
Совет от создателей "Unknown Artist - Track 1.mp3" и "Новая папка (2)":
Задайте заголовок у окна своего батника и установите настройки только для него.

[more] [/more]

hErAux

Цитата:

Задайте заголовок у окна свое батника и установите настройки только для него.

И как настройки "только для него" будет работать на других машинах?

boss911
Вам нужно вместо вызова подпрограммы запускать вторую копию батника из самого себя. И каким-то образом давать этой второй копии понять, что нужно сразу перейти в подпрограмму. Это можно делать параметром или установкой переменной. Мой простейший пример - это демонстрация общего принципа.

GCRaistlin

Цитата:

Задачка интересная, конечно

Интересная, но ничего общего с назначением cmd не имеющая. На самом деле, cmd - достаточно удачный именно для своего назначения язык, несмотря на полнейшую "неформатность" и разные затруднения в "программировании" (которые, как правило, имеют решение - в частности проблема символов ! ^ % & | в именах обрабатываемых файлов на практике всегда решается). Очень важны, например, быстрая загрузка новой копии, минимальный расход памяти на одну копию.

Даже перед bash у cmd есть ряд преимуществ: возможность менять файл скрипта во время исполнения (организация вручную пополняемых очередей исполнения, вроде разных загрузок или кодирования видео), очень компактная форма доступа к частям имени файла (%~nx1 и т.п.), goto с метками-переменными многое позволяет записывать гораздо короче и т.п.

boss911

Цитата:

Но консольное окно, после запуска батника, всегда имеет разное положение

Можно менять положение и размер окна в процессе работы, только нужна небольшая утилитка

cmdow.exe @ /MOV 20 20 /SIZ 1000 1000