如何设置PowerShell的默认目录?


Answers:


61

您可以指定启动PowerShell时要打开的目录:

powershell.exe -NoExit -command "& {Set-Location $env:systemroot}"

只需在您的快捷方式中使用它即可。

或使用配置文件设置开始目录。


5
对于PS Core:pwsh.exe -WorkingDirectory C:\YourLocation\Goes\Here
Sergey Zykov,

“ C:\ Program Files \ PowerShell \ 6 \ pwsh.exe” -WorkingDirectory D:\ test
cem kaan

179

如下创建PowerShell配置文件

  1. 以管理员身份运行PowerShell并执行以下命令:

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

    这将允许PowerShell运行本地脚本以及从Internet下载的已签名的脚本。在文档中阅读有关此命令的更多信息。

  2. 在您的Documents文件夹中,找到一个名称WindowsPowerShell为经典PowerShell或PowerShell更新的PowerShell Core 的文件夹。如果不存在,那没关系;只需创建它。

  3. profile.ps1WindowsPowerShell文件夹中创建一个新文件(或PowerShell用于PowerShell Core)。
  4. 打开profile.ps1并添加以下命令来设置默认工作目录:

    Set-Location C:\my\default\working\directory
  5. 打开一个新的PowerShell窗口...更改应已生效。


1
我尝试了此操作,但得到“由于运行脚本被禁用,无法加载profile.ps1”。有启用安全脚本的“安全”方法吗?
John Little

3
运行以下命令:“ Set-ExecutionPolicy -ExecutionPolicy RemoteSigned”您可以在此处阅读有关信息:technet.microsoft.com/zh-cn/library/ee176961.aspx 除非从受信任的脚本中下载这些脚本,否则它不允许运行。资源。
学士

7
这是一种非常糟糕的方法,因为如果您有一个生成脚本(例如Visual Studio生成脚本),并且想要运行ps命令,那么该命令的工作目录将被设置为该位置,因此基本上使用powershell破坏所有脚本,例如powershell -File "myscript.ps1"
Santhos

2
如果那是一个不好的选择,是否有更好/更安全的方法呢?
亚当_G

4
让我纠正自己。在编写Powershell脚本(例如用于构建)时,请始终使用-NoProfile选项,例如powershel -NoProfile -File "myscript.ps1"
Santhos

33

我在Windows Server 2016中尝试了以上答案,但未成功。

但是我发现这种方法(对于Windows 10应该是相同的)适用于我。

  1. 启动PowerShell会话
  2. 在任务栏中,右键单击并固定在此处以保持链接
  3. 再次右键单击任务栏中的图标,然后右键单击Windows PowerShell并选择“ 属性”。
  4. 在“ 开始于:”输入字段中输入首选目录,然后按OK。
  5. 从任务栏图标开始

做完了!

在同一个“ 属性”对话框中,您还可以更改许多其他设置,例如字体,颜色,大小,并在“ 快捷方式”选项卡上通过按钮进行更改Advanced。您可以选择是否以管理员权限运行该PowerShell会话。


5
当您签Run as administrator.lnk高级菜单时,更改工作目录似乎不起作用。解决方案似乎在这里stackoverflow.com/questions/31622469/…–
Santhos

太奇怪了,因为它在这里有效。刚刚测试了更改目录Run as aministrator和来回更改复选框。
neongrau

很有魅力。谢谢。
亚西·谢赫

12

设置默认目录的一种简便方法是:

  1. 右键单击Windows PowerShell图标,然后固定到“开始”
  2. 右键单击“开始”中的Windows PowerShell图标,然后再次右键单击Windows PowerShell,然后选择“属性”(不是“以管理员身份运行”而不是Windows PowerShell ISE

    在此处输入图片说明

    1. 在“ 快捷方式”选项卡->“开始于”字段中,更改为您要PowerShell启动的位置。

    在此处输入图片说明


哦,谢谢,我喜欢这个答案。帮助我了解为什么以及哪个目录被设置为“默认”。我认为此解决方案还可以稍微减少加载配置文件的开销时间成本(不确定是否正确,但感觉像这样)。
詹宁斯

4

Set-Location到您的个人资料将无条件改变当前的工作目录,这可能有关于工作目录不必要的后果脚本,您通过“使用PowerShell运行”执行。

另一种解决方案是将.lnk文件的工作目录更改为通常在中找到的PowerShell %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell。右键单击链接,然后将工作目录从更改%HOMEDRIVE%%HOMEPATH%为所需的目录。


1
当您签Run as administrator.lnk高级菜单时,更改工作目录似乎不起作用。解决方案似乎在这里stackoverflow.com/questions/31622469/…–
Santhos

这是最好的解决方案(至少对我而言)。
安德斯·阿皮

这就是为什么脚本应使用以下-NoProfile选项的原因 powershell -NoProfile -File "myscript.ps1"
Santhos '17

4

在PowerShell中键入以下内容:

New-Item -path $profile -type file force

它在PowerShell文件夹中创建一个.ps1文件。打开它,并将其编辑为:

Set-location C:\files

完成了

请参考此链接。它工作正常。

更改PowerShell启动目录


3

您可以在PowerShell配置文件中编写一个简单的函数,以Set-Location在必要时快速更改工作目录,而不必像先前的答案中提到的那样无条件地更改工作目录。

检查Jeremy Danyow的答案以创建/修改PowerShell配置文件。

将功能添加到您的PowerShell配置文件:

function goto_this {set-location 'your\path\to\some\dir'}
function goto_that {set-location 'your\path to some\dir with space'}

只需更改指向的函数名称和目录即可。如果路径中包含空格,则必须在路径上使用引号。我尝试保留前缀,goto_因为它有助于记住函数的名称。

您可以开始键入,goto_然后按TAB键以循环浏览所有已添加的功能(请记住在添加/修改功能后启动新的PowerShell窗口)。


1

仅使用命令行,如果文件已经存在,它将添加到该文件:

$(if (-Not (Test-Path ~\Documents\WindowsPowerShell\)){ mkdir ~\Documents\WindowsPowerShell\}) ; echo "Set-Location c:\THELOCATIONYOUWANT" >> ~\Documents\WindowsPowerShell\profile.ps1

1

这样,“工作目录”和PowerShell的“位置”似乎有些混乱。这里大多数人正在做的事情是说更改PowerShell的“位置”。实际上,“工作目录”是不同的。这是一篇解释它的文章

对于那些不想阅读该文章的人:打开PowerShell,并使用其他人说的做的Set-Location "C:\some\directory"。请注意,您的“工作目录”仍然是打开PowerShell的位置。无论是"~""%SYSTEMROOT%\system32"取决于如果你跑了作为管理员或没有。要检查工作目录,请使用[Environment]::CurrentDirectory

注意:在本文中,作者说要使用此命令检查“工作目录”:

\[Environment\]::CurrentDirectory

我不确定这是否适用于旧版PowerShell,但必须使用PowerShell 5(及更高版本)[Environment]::CurrentDirectory


0

将其作为Profile.ps1的第一行,PowerShell Core(pwsh)将在您当前正在使用的目录中打开:

设置位置(get-location).path



0

此解决方案将当前工作文件夹设置为脚本所在的位置。确保放置在脚本的开头,或者至少在尝试使用依赖于位置路径的命令之前。

Set-Location (Split-Path $MyInvocation.MyCommand.Path)
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.