如何获取windows批处理的父文件夹答案

【问题标题】：How to get windows batch's parent folder如何获取windows批处理的父文件夹
【发布时间】：2013-05-13 11:48:06
【问题描述】：

我正在写一个批处理文件，我需要获取这个bat文件的父文件夹。有可能吗？注意我的意思是批处理文件的父文件夹不是调用该批处理的提示的当前目录。

谢谢

【问题讨论】：

【解决方案1】：

批处理的父文件夹位于变量%~dp0 中。示例：

@echo off&setlocal
for %%i in ("%~dp0.") do set "folder=%%~fi"
echo %folder%

【讨论】：

不行，可能我忘了说是windows的批处理
是的，我知道。我的回答是纯批次。用记事本把它放在一个文本文件中，命名为例如。 mybatch.bat 并从命令行启动它。如果从资源管理器启动，请在末尾添加pause。
不工作 test.bat，从命令行执行。它在文件夹c:\test123\test.bat 中，代码与上面完全相同。当我运行它时，我得到输出c:\
是的，没关系。 c:\test123\test.bat 的文件夹是 test123，父文件夹在你的情况下是 "c:\"
您需要删除 ("~dp0..") 中的两个点，因为它们会向上获得一个目录。问题是我如何找到批处理的父文件夹而不是partent的文件夹父文件夹...

【解决方案2】：

Endoro 的回答对我也不起作用，但确实如此。这就是我自己做的。

其中一个应该做正确的事

for %%I in ("%~dp0.") do for %%J in ("%%~dpI.") do set ParentFolderName=%%~nxJ
echo %ParentFolderName%

for %%I in ("%~dp0.") do for %%J in ("%%~dpI.") do set ParentFolderName=%%~dpnxJ
echo %ParentFolderName%

V2：

for %%I in ("%~dp0\.") do set ParentFolderName=%%~nxI
echo %ParentFolderName%

V1：

for %%I in (..) do set ParentFolderName=%%~nI%%~xI
echo %ParentFolderName%

参考：For | Microsoft Docs

【讨论】：

这是当前工作文件夹的父文件夹，而不是批处理文件的父文件夹（它们可以相同，但不能保证）。（顺便说一句：%%~nI%%~xI 可以缩短为%%~nxI）
但现在它几乎是原始答案，不同之处在于您只获得文件夹的名称而没有任何前置信息。对于C:\Projects\User1\batchFiles\myFile.bat，您的解决方案仅提取batchFiles
（“父文件夹”是什么显然有些混淆 - 据我了解，batchfiles 是“批处理文件的文件夹”，其父文件夹是 User1，但 OP 似乎有不同的定义）
@cpcoletta: %~dp0 已经包含了尾部反斜杠，所以 %~dp0\. 没有意义。
即使路径中的一个文件夹的名称有空格，这也有效。我发现的其他一些解决方案在这方面失败了。伙计，我真的讨厌 Windows。

【解决方案3】：

如果要批处理文件所在的文件夹，可以指定

SET folder=%~dp0

如另一个答案中所述。

如果你想要批处理文件的位置上面的文件夹，你可以分配

SET folder=%~dp0..\

但是，如果您打算向用户显示路径，则最后一个变量可能不够用。在这种情况下，也许它更可取

FOR %%A IN ("%~dp0.") DO SET folder=%%~dpA

例如，如果您在C:\Users\Public中有以下脚本

@ECHO OFF
ECHO %~dp0
ECHO %~dp0..\
FOR %%A IN ("%~dp0.") DO ECHO %%~dpA

输出将是

C:\Users\Public\
C:\Users\Public\..\
C:\Users\

【讨论】：

【解决方案4】：

所以这是一个糟糕的答案，但我现在使用它的次数比我承认的要多：

powershell -command "(get-item '%~dp0').name" > %temp%\temp_var.txt
set /p parent_folder= < %temp%\temp_var.txt
echo %parent_folder%
pause

由于 PowerShell 现在几乎在 Windows 中无处不在，我尽可能多地滥用它。

但是，它不好，因为它确实依赖于环境路径中存在的 PowerShell，并且它不依赖于在脚本写入和读取之间修改临时存储文件的其他脚本。 p>

【讨论】：