Действительно ли двойной амперсанд (&&) необходим для windows пакетных сценариев, ярлыков и других неживых методов cmd? - PullRequest
1 голос
/ 21 февраля 2020

Этот вопрос основан на ответе @ ZaLiTHkA о принятом ответе на последовательно запущенные команды cmd, показанном ниже.

Просто для ясности: вы должны отметить один символ & здесь явно для живой командной строки. Когда команды запускаются путем передачи строки, которая должна быть выполнена в виде скрипта (ярлыки, командные файлы и т. Д. c ..), требуется двойное значение && - ZaLiTHkA 3 апреля 14 в 20: 28

Действительно ли && действительно необходимо для запуска команд сценария (т. Е. Ярлыков или пакетных файлов)? Я обнаружил, что все еще могу выполнить простую команду, такую ​​как: cmd /k echo foo & echo bar в окне запуска и без проблем выполнить ярлык той же цели / команды. Буду признателен за любые разъяснения или документацию, в которых прямо говорится , почему и , если && на самом деле является рекомендуемым методом для пакетных сценариев, поскольку кажется, что один &, похоже, тоже работает.

Примечание. Это не вопрос различия между определениями && и &, но почему && требуется, как указано в очень заметном комментарии @ ZaLiTHkA.

1 Ответ

3 голосов
/ 21 февраля 2020

Просто для ясности: вы должны заметить, что одиночный & символ здесь явно для командной строки в реальном времени. Когда команды выполняются путем передачи строки, которая должна быть выполнена в виде скрипта (ярлыки, командные файлы и т. Д. c ..), тогда требуется двойной &&. - ZaLiTHkA 3 апреля '14 в 20: 28

Комментарий - это чепуха!

Как уже объяснялся ответ, есть семантическая разница между & и &&.

Это зависит только от намерения, какое из них следует использовать.

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

. В случае cd C:\myDir\ && del *.* целесообразно использовать &&, чтобы предотвратить нежелательное удаление где-либо, когда cd не удается.

Я тоже это комментирую .

...