текущий рабочий каталог в VBScript вызывается перетащить и операции перетаскивания

Question

Когда я пытался получить повышенные права для моего пакетного сценария, когда я нашел два связанных SO вопросы

• How to request Administrator access inside a batch file
• How can I auto-elevate my batch file, so that it requests from UAC administrator rights if required?

... что привело к частично отработавшимся ответам. По какой-то причине у меня возникли проблемы с передачей командной строки для аргументов пути к файлу, содержащих пробелы в сценарии VBS, поэтому я попытался разбить решение на 3 части и сосредоточиться на внутреннем (VBS) шаге, а затем добавить последний шаг, вызвав из этой VBS, которая не может быть найдена, несмотря на то, что в той же папке, что и скрипт VBS. Я обнаружил, что перетащить & капля не «так просто» и что при использовании .vbs это не так, а .bat или .exe как цели падения.

Вот мой актуальный вопрос:

Если я перетащить файл и поместите его на исполняемый файл (EXE) или пакетный файл (BAT, CMD), Текущий рабочий каталог определяется источником перемещенного элемента , Его каталог задается как рабочий каталог для программы или скрипта, который ее обрабатывает.

Если я отброшу файл на скрипт VBS, это будет другим. В Windows 8.1 x64 я наблюдаю это как C:\Windows\System32, даже если аргумент находится в той же папке, что и VBS.

я могу просто использовать пакетный файл (как реле drag'n'drop) как этого

my.vbs %* 

, чтобы получить «нормальный» .bat поведения (источник падения диктует УХО), но я также хочу, чтобы понять, Это.

Это ошибка или функция? Является ли он совместимым во всех версиях Windows?

---

редактировать: добавил фон (сверху) для вопроса, показывающего, как я туда попал (+ незначительные исправления)

Answer 1

После некоторого мониторинга API, это то, что я вижу

При удалении файла через .exe файл explorer.exe использует CreateProcess функцию API, чтобы начать процесс, передавая исполняемый в lpApplicationName и исполняемые и уронил файл как lpCommandLine. lpCurrentDirectory устанавливается в вызове функции процессом вызывающего абонента в папку, содержащую отброшенный файл ^[1].

При удалении файла через .cmd файл explorer.exe также использует CreateProcess API, но в этом случае lpApplicationName является null и lplCommandLine содержит пакетный файл и сброшенный файл. lpCurrentDirectory также установлен в родительскую папку упавшего файла ^[1].

При удалении файла через .vbs файл, ShellExecuteEx используется и lpDirectory поле SHELLEXECUTEINFO структуры null, поэтому процесс создан наследует текущий активный каталог родительского процесса. По умолчанию текущий активный каталог процесса explorer.exe равен %systemroot%\system32, но можно запустить экземпляр explorer с другим текущим активным каталогом, который будет наследоваться при таких операциях сбрасывания.

^[1] Если мы опускаем более одного файла, путь к файлу передается в качестве первого аргумента используется

примечание только для информации: чтобы проверить активный каталог наследует процесс с последующим был:

• Открыть cmd экземпляр и изменить текущую активную директорию на c:\temp
• убить всех explorer.exe экземпляров
• От cmd запрос экземпляра explorer.exe. Этот экземпляр explorer имеет активный каталог в окне cmd в качестве его текущего активного каталога.

Answer 2

c:\windows\system32\CScript.exe или c:\windows\system32\Wscript.exe являются программы, которые работают VBScript. Как видите, они находятся в system32.

Windows, использует ShellExecuteEx для запуска программ - см это правила в MSDN:
ShellExecuteEx function (Windows)

ShellExecuteEx использует CreateProcess (CreateProcessEx) на самом деле запустить программу. CreateProcess function (Windows)

Редактировать

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

Основная цель CMD - совместимость MS Dos 5 при ее улучшении, она будет правильно запускать большинство пакетных файлов DOS. Он был написан инженерами IBM, работающими над OS/2 NOT Windows.

Edit 2

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

Как программист, вы не делаете предположений. Самый простой способ не принимать предположения - это указать полные пути к тому, что вы хотите. Ваш пакетный файл не должен заботиться о том, что представляет собой текущий каталог. EG В CMD существует текущая директория на диске для совместимости с MSDos 5 (и программы в консоли имеют тенденцию делиться ими, но не обязательно). В Windows есть один текущий каталог для каждой программы. За последние годы изменился текущий каталог по умолчанию.

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

Answer 3

Свойство Arguments имеет полные пути ко всем пунктам, сброшенными на сценарии, так что вы можете определить каталог каждые упал предмет, как это:

Set fso = CreateObject("Scripting.FileSystemObject") 
For Each item In WScript.Arguments 
    WScript.Echo fso.GetParentFolderName(item) 
Next 

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

Set fso = CreateObject("Scripting.FileSystemObject") 
Set sh = CreateObject("WScript.Shell") 
For Each item In WScript.Arguments 
    sh.CurrentDirectory = fso.GetParentFolderName(item) 
    'working directory is now the parent folder of the current item 

    '... 
Next 

Если вам нужен рабочий каталог будет родительский каталог VBScript файл, который вы можете получить, что из ScriptFullName собственности:

Set fso = CreateObject("Scripting.FileSystemObject") 
WScript.Echo fso.GetParentFolderName(WScript.ScriptFullName) 

Answer 4

Если я подстановок типы файлов в ОС Windows реестра, я вижу следующее в своих Shell\Open\Command значений:

• batfile: "%1" %*
• cmdfile: "%1" %*
• EXEFILE: "%1" %*
• VBSFile: "%SystemRoot%\System32\WScript.exe" "%1" %*

Это позволяет предположить, что bat, cmd, exe являются рассматриваться как исполняемый сами по себе, может быть, по историческим причинам, в то время как VBS является считается обычным сценарием , который является исполняемым только потому, что его расширение зарегистрировано с помощью некоторого исполняемого файла, который должен быть вызван для его интерпретации. В значительной степени то же, что и Python или Perl.

[Update] Действительно, я доказал, что сценарий Python показывает точно такое же поведение, как мой VBS скрипт: вызов его из командной строки, обеспечивая аргументы сохраняет УХО, сбросив файл на нем вызывает УХО быть C:\Windows\System32. Поэтому мой вопрос кажется неправильным, но, наконец, это помогло людям указать мне правильное направление для дальнейших исследований ...