После многих лет использования pushd/popd в командных файлах Windows, с удивлением обнаружил, что pushd сохраняет текущий каталог лишь в том случае, когда ей задан параметр-путь. Если параметр не задан — выводит стек сохраненных путей.

В документации (встроенная справка и TechNet) об этом ни слова.

То есть,

pushd dir
popd

предшествующий текущий каталог восстанавливает, а

pushd
cd dir
popd

— не восстанавливает.

Проверял в XP SP3 и Win7 SP1 x64 — одинаково. Что интересно, по этому вопросу почти ничего не гуглится.

Если нужно разнести во времени сохранение текущего каталога и его смену, придется извращаться так:

pushd "%CD%"
...
cd dir
...
popd

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>После многих лет использования pushd/popd в командных файлах Windows, с удивлением обнаружил, что pushd сохраняет текущий каталог лишь в том случае, когда ей задан параметр-путь. Если параметр не задан — выводит стек сохраненных путей.
ЕМ>В документации (встроенная справка и TechNet) об этом ни слова.
Это ещё что. Когда что нить в скрипте крэшанётся, popd вообще не выполниться.

Здравствуйте, Vain, Вы писали:

V>Когда что нить в скрипте крэшанётся, popd вообще не выполниться.

Это вполне логично — например, созданные переменные среды тоже не уничтожаются, иначе было бы странно.

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Когда что нить в скрипте крэшанётся, popd вообще не выполниться.
ЕМ>Это вполне логично — например, созданные переменные среды тоже не уничтожаются, иначе было бы странно.
Это ломает скрипты верхнего уровня и все которые после будут вызываться. Консоль приходится перезапускать.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>После многих лет использования pushd/popd в командных файлах Windows, с удивлением обнаружил, что pushd сохраняет текущий каталог лишь в том случае, когда ей задан параметр-путь. Если параметр не задан — выводит стек сохраненных путей.
...
ЕМ>

ЕМ>pushd "%CD%"
ЕМ>...
ЕМ>cd dir
ЕМ>...
ЕМ>popd
ЕМ>

Почему не так

pushd .
popd

Что смущает у мелкомягких всё странно. Переменные в цикле for никогда не смущали?
или такие конструкции

echo+
echo|set /p=12345
echo|set /p=67890
echo+

Здравствуйте, Vain, Вы писали:

V>Это ломает скрипты верхнего уровня и все которые после будут вызываться.

Не понимаю, почему Вас это удивляет. Если в обычном процессе любой из потоков напорется на необработанное исключение — будет снят весь процесс, и никому еще не пришло в голову сказать, что это неправильно.

Если предполагается обработка таких ситуаций — сохранять каталоги нужно в вызывающем скрипте, а не в вызываемом.

Здравствуйте, kov_serg, Вы писали:

_>Почему не так
_>

_>pushd .
_>

Если оно всегда разворачивает путь в полный — годится и так.

_>Переменные в цикле for никогда не смущали?

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

_>или такие конструкции

_>

_>echo|set /p=12345
_>echo|set /p=67890
_>

Хм, какой в них смысл?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если предполагается обработка таких ситуаций — сохранять каталоги нужно в вызывающем скрипте, а не в вызываемом.
Вызывающий скрипт может ничего не знать про вызываемый.

Здравствуйте, Vain, Вы писали:

V>Вызывающий скрипт может ничего не знать про вызываемый.

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

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Вызывающий скрипт может ничего не знать про вызываемый.
ЕМ>Если он хочет вызывать неотлаженный и/или заведомо кривой скрипт — пусть либо берет на себя обработку возможных ошибок, либо соглашается с их возможными последствиями.
Он не может этого сделать, нет соответствующего функционала. И скрипт здесь не причём. К примеру, с таким же успехом я не могу знать, что в потрахах у скрипта vcvarsall.bat, который из студии, да и не должен знать. Я просто его вызываю с определёнными параметрами и на этом всё. И подобных скриптов чуть меньше чем полностью.

Здравствуйте, Vain, Вы писали:

V>Он не может этого сделать, нет соответствующего функционала.

Какого функционала нет? Перед вызовом скрипта сделать тот же pushd, после возврата оттуда — popd. Или вызывать скрипт через cmd /c.

V>И скрипт здесь не причём. К примеру, с таким же успехом я не могу знать, что в потрахах у скрипта vcvarsall.bat, который из студии, да и не должен знать.

Верно. Но, если вызываемый скрипт работает неправильно, у Вас есть три варианта:

— Дождаться исправления авторами
— Исправить самому
— Не использовать неправильный скрипт

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

Вообще, это Ваша личная позиция, или ее разделяет кто-то еще?

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Он не может этого сделать, нет соответствующего функционала.
ЕМ>Какого функционала нет?
Ну, к примеру, команды trap которая позволяет выполнить что-то по какому-нить сигналу, к примеру, по ctrl-c стереть временные файлы или восстановить текущий каталог.

ЕМ>Перед вызовом скрипта сделать тот же pushd, после возврата оттуда — popd.
Ну так popd может не отработать и оставшаяся часть скрипта или инструкций из другого скрипта, но в том же процессе, начнёт работать со случайной директорией. Да и сама консоль окажется в какой-то случайной директории, когда скрипт выйдет.

ЕМ>Или вызывать скрипт через cmd /c
Это не удобно, никто так, просто не делает.

V>>И скрипт здесь не причём. К примеру, с таким же успехом я не могу знать, что в потрахах у скрипта vcvarsall.bat, который из студии, да и не должен знать.
ЕМ>Верно. Но, если вызываемый скрипт работает неправильно, у Вас есть три варианта:
Он работает не правильно не потому-что он неправильный, а потому-что его интерпретатор — убогий, не позволяет сделать лучше.

ЕМ>- Исправить самому
Не можешь ты тут все исправить, это уже не зависит от скрипта.

ЕМ>Вы же, получается, продолжаете использовать неправильные скрипты, не принимая мер к их исправлению, и при этом ожидаете от интерпретатора, что он будет заниматься тем, чем должен заниматься программист.
Он и не занимается, он настолько недоделан, что его уже никто не поддерживает

ЕМ>Вообще, это Ваша личная позиция, или ее разделяет кто-то еще?
Это мой личный опыт программирования на батниках и, да, я знаю о чём говорю

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, kov_serg, Вы писали:

_>>Почему не так
_>>

_>>pushd .
_>>

ЕМ>Если оно всегда разворачивает путь в полный — годится и так.

_>>Переменные в цикле for никогда не смущали?

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

_>>или такие конструкции

_>>

_>>echo|set /p=12345
_>>echo|set /p=67890
_>>

ЕМ>Хм, какой в них смысл?
вывод текста без перевода строки

Здравствуйте, Vain, Вы писали:

V>Ну, к примеру, команды trap которая позволяет выполнить что-то по какому-нить сигналу, к примеру, по ctrl-c стереть временные файлы или восстановить текущий каталог.

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

V>Ну так popd может не отработать и оставшаяся часть скрипта или инструкций из другого скрипта, но в том же процессе, начнёт работать со случайной директорией. Да и сама консоль окажется в какой-то случайной директории, когда скрипт выйдет.

Ничего не понял. Каким образом может не отработать popd, если он находится в вызывающем скрипте, а падает вызываемый? Или Вы хотите, чтобы интерпретатор чистил еще и при нажатии Ctrl-C? Вы на этих скриптах поэмы пишете?

ЕМ>>Или вызывать скрипт через cmd /c
V>Это не удобно, никто так, просто не делает.

Ну, это кому ехать, а кому и шашечки.

V>Он работает не правильно не потому-что он неправильный, а потому-что его интерпретатор — убогий, не позволяет сделать лучше.

Интерпретатор убогий, тут спора нет. Более сложный интерпретатор в Windows банально не нужен.

V>Не можешь ты тут все исправить, это уже не зависит от скрипта.

Что в скриптах может не зависеть от скриптов? Я Вас не понимаю от слова "совсем".

V>Он и не занимается, он настолько недоделан, что его уже никто не поддерживает

Кто и как его мог бы "поддерживать"?

V>Это мой личный опыт программирования на батниках и, да, я знаю о чём говорю

Подозреваю, что Вы пытаетесь их использовать не по назначению.

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Ну, к примеру, команды trap которая позволяет выполнить что-то по какому-нить сигналу, к примеру, по ctrl-c стереть временные файлы или восстановить текущий каталог.
ЕМ>В Windows напрочь отсутствует практика сколько-нибудь широкого распространения скриптов
Да ну? На каждом углу только и вижу эти батники. Даже чтобы cmake и boost build вызвать батники пишут.

ЕМ>а на месте, для себя, каждый всегда может подобрать удобный интерпретатор.
И, внимание, это не избавляет от написания батников!

ЕМ>Столь развесистый скриптовый язык во встроенной форме был бы востребован единицами из десятков-сотен тысяч, кому охота заморачиваться?
Пользователи unix shell смотрят на тебя с недоумением.

V>>Ну так popd может не отработать и оставшаяся часть скрипта или инструкций из другого скрипта, но в том же процессе, начнёт работать со случайной директорией. Да и сама консоль окажется в какой-то случайной директории, когда скрипт выйдет.
ЕМ>Ничего не понял. Каким образом может не отработать popd, если он находится в вызывающем скрипте, а падает вызываемый? Или Вы хотите, чтобы интерпретатор чистил еще и при нажатии Ctrl-C? Вы на этих скриптах поэмы пишете?
pushd/popd в вызываемом скрипте, между ними, к примеру, происходит ошибка и ты вываливаешься в консоль с другой текущей директорий

ЕМ>>>Или вызывать скрипт через cmd /c
V>>Это не удобно, никто так, просто не делает.
ЕМ>Ну, это кому ехать, а кому и шашечки.
Так и едут, вызывая скрипт естественным образом — по его имени

V>>Он работает не правильно не потому-что он неправильный, а потому-что его интерпретатор — убогий, не позволяет сделать лучше.
ЕМ>Интерпретатор убогий, тут спора нет. Более сложный интерпретатор в Windows банально не нужен.
И опять, unix shell юзеры смотрят на тебя с недоумением.

V>>Не можешь ты тут все исправить, это уже не зависит от скрипта.
ЕМ>Что в скриптах может не зависеть от скриптов? Я Вас не понимаю от слова "совсем".
К примеру, отсутствие обработки ошибок — уже не зависит

V>>Он и не занимается, он настолько недоделан, что его уже никто не поддерживает
ЕМ>Кто и как его мог бы "поддерживать"?
Тот индус, который его когда-то в 95-ю винду сунул?

V>>Это мой личный опыт программирования на батниках и, да, я знаю о чём говорю
ЕМ>Подозреваю, что Вы пытаетесь их использовать не по назначению.
Я как минимум пытался их использовать по-разному и уже знаю результат

Ваши речи очень похожи на заклинания.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ваши речи очень похожи на заклинания.
Для неопытных товарищей это естественно.