vbscript中的当前工作目录被拖动&下降操作 [英] current working directory in a vbscript invoked by a drag & drop operation

问题描述

当我试图获得我的批处理脚本的高级权限时，当我发现两个相关的SO问题时，

• 如何在批处理文件中请求管理员访问


• 如何自动提升我的批处理文件，以便在需要的时候向UAC管理员提出请求？

...导致部分答案有效。由于某些原因，我在命令行传递中遇到包含VBS脚本中的空格的文件路径参数的问题，所以我试图将解决方案分成3部分，并集中在内部（VBS）步骤上，然后通过调用尽管与VBS脚本相同的文件夹中，仍然无法找到该VBS的批处理。我发现拖把使用 .vbs 而不是 .bat 和 $ c>或 .exe 作为放置目标。

这是我的实际问题：

如果我拖动一个文件并将其放在可执行文件（exe）或批处理文件（bat，cmd）上，则当前工作目录由拖动的项目的源决定。它的目录被设置为处理它的程序或脚本的工作目录。

如果我将文件放到VBS脚本上，它是不同的。在Windows 8.1 x64上，我观察到它是 C：\Windows\System32 即使参数位于与VBS相同的文件夹中。

我可以简单地使用这样的批处理文件（如拖放中继）

  my.vbs％* 
  

获取正常 .bat 行为（放弃源决定CWD），但我也想了解它。

是错误还是功能？在所有Windows版本中是否一致？

---

编辑：添加了背景（顶部）显示我如何到达的问题（+小修正）

解决方案

经过一些API监控，这是我看到的/ p>

当您将文件放在 .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] 如果我们删除多个文件，则使用作为第一个参数传递的文件的路径

note 只是为了信息：测试活动目录继承的过程是：

• 打开一个 cmd 实例，将当前活动目录更改为 c：\temp


• 全部删除 explorer.exe 实例


• 从 cmd 实例调用 explorer.exe 。 explorer 实例将 cmd 窗口中的活动目录作为其当前活动目录。

When I was trying to get elevated rights for my batch script, when I found two related SO questions

• 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?

...that led to answers that worked partially. For some reason, I had issues with command line passing for file path arguments containing spaces within the VBS script, so I tried to break the solution into 3 parts and concentrated on the inner (VBS) step, then adding the last step by calling a batch from that VBS which could not be found, despite in the same folder as the VBS script. I found that drag & drop isn't "that easy" and that it's different when using .vbs instead of .bat or .exe as drop targets.

Here is my actual question:

If I drag a file and drop it onto an executable (exe) or batch file (bat, cmd), The current working directory is determined by the source of the dragged item. Its directory is set as the working directory for the program or script that processes it.

If I drop a file onto a VBS script, it's different. On Windows 8.1 x64 I observe it to be C:\Windows\System32 even if the argument resides in the same folder as the VBS.

I can simply use a batch file (as drag'n'drop relay) like this

my.vbs %*

to get "the normal" .bat behaviour (drop source dictates CWD), but I also want to understand it.

Is it a bug or a feature? Is it consistent over all Windows versions?

---

edit: added the background (on top) for the question showing how I got there (+minor corrections)

解决方案

After some API monitoring, this is what I see

When you drop a file over a .exe file the explorer.exe uses CreateProcess API function to start the process, passing the executable as lpApplicationName, and the executable and dropped file as lpCommandLine. The lpCurrentDirectory is set in the function call by the caller process to the folder containing the dropped file^[1].

When you drop a file over a .cmd file the explorer.exe also uses CreateProcess API, but in this case the lpApplicationName is null and the lplCommandLine contains the batch file and the dropped file. lpCurrentDirectory is also set to the parent folder of the dropped file^[1].

When you drop a file over a .vbs file, ShellExecuteEx is used and the lpDirectory field of the SHELLEXECUTEINFO structure is null, so, the process created inherits the current active directory of the parent process. By default the current active directory of the explorer.exe process is %systemroot%\system32, but it is possible to start a explorer instance with a different current active directory that will be inherited in this kind of drop operations.

^[1] If we drop more than one file, the path of the file passed as first argument is used

note just for information: to test the active directory inherit the process followed was:

• Open a cmd instance and change the current active directory to c:\temp
• Kill all explorer.exe instances
• From the cmd instance call explorer.exe. This explorer instance has the active directory in the cmd window as its current active directory.

这篇关于vbscript中的当前工作目录被拖动&下降操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！