I am calling PowerShell from within a Java application (through the Windows command prompt) to read various file attributes.
For example,
powershell (Get-Item 'C:\Users\erlpm\Desktop\Temp\s p a c e s.txt').creationTime
I am enclosing the file path in single quotes, because it may contain spaces.
It worked fine, until I encountered a file path containing square brackets, which seem to be interpreted as a wildcard character. I managed to solve it by adding the -literalPath parameter:
powershell (Get-Item -literalpath 'C:\Users\erlpm\Desktop\Temp\brackets[].txt').creationTime
So far, so good... But file paths may also contain single quotes, dollar signs, ampersands, etc., and all these characters seem to have a specific function in PowerShell for which the -literalPath parameter does not seem to work.
I tried enclosing the path with double quotes or escaping with the `character, but that did not solve my problem either :-(
Any suggestions on how to pass a file path to PowerShell which may contain spaces, single quotes, square brackets, ampersands, dollar signs, etc.?
Someone here already showed me how to get it working from within PowerShell, but somehow the answer has been removed(?).
Anyway, I did create a file called $ & ' [].txt.
This works form within PowerShell (needed to escape the &):
Get-Item -LiteralPath "C:\Users\erlpm\Desktop\Temp\`$ & ' [].txt"
Directory: C:\Users\erlpm\Desktop\Temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2012-08-23 14:22 0 $ & ' [].txt
But when I execute the same PowerShell command through the Windows command prompt, ...
powershell Get-Item -LiteralPath "C:\Users\erlpm\Desktop\Temp\`$ & ' [].txt"
... I get this error:
Ampersand not allowed. The & operator is reserved for future use; use "&" to pass ampersand as a string.
At line:1 char:55 \
Get-Item -LiteralPath C:\Users\erlpm\Desktop\Temp`$ & <<<< ' [].txt \
CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException \
FullyQualifiedErrorId : AmpersandNotAllowed
Using the -command parameter and putting the PowerShell command between {} gives exactly the same error message ...
powershell -command {Get-Item -LiteralPath "C:\Users\erlpm\Desktop\Temp\`$ & ' [].txt"}
This is really a question about cmd.exe string escaping, then. Combining cmd and PowerShell string escaping is a total nightmare. After quite a few attempts, I got your specific example to work:
powershell.exe -nologo -noprofile -command ^&{ dir -LiteralPath ^"""".\`$ & ' [].txt"" }
Directory: C:\Users\latkin
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 8/23/2012 8:46 AM 0 $ & ' [].txt
Totally intuitive, right?
You can spend 15 minutes wrestling with escape sequences every time, or you can try some other approaches.
Put the file name in a text file, and read it out of there.
powershell.exe -command "&{dir -literal (gc .\filename.txt) }"
or
Use a script
powershell.exe -file .\ProcessFiles.ps1 # In processfiles.ps1 you are in fully powershell environment, so escaping is easier
or
Use -EncodedCommand
See powershell.exe -? (last item shown) or http://dmitrysotnikov.wordpress.com/2011/07/06/passing-parameters-to-encodedcommand/
If you can write the path to a temporary .txt file, the following works OK:
(Get-Item -literalpath (gc 'C:\Temp\path.txt')).creationTime
The file # C:\Temp\path.txt contains the path with special characters in it, other than this I think you would have to escape each special character on a per path basis.
In addition to the hack above, it appears PowerShell V3 may help out here with the addition of a new 'magic parameter' language feature. Specifically, see the section headed 'Easier Reuse of Command Lines From Cmd.exe' here and because I hate link-rot, here it is, shamelessly reproduced below:
Easier Reuse of Command Lines From Cmd.exe
The web is full of command lines written for Cmd.exe. These commands
lines work often enough in PowerShell, but when they include certain
characters, e.g. a semicolon (;) a dollar sign ($), or curly braces,
you have to make some changes, probably adding some quotes. This
seemed to be the source of many minor headaches.
To help address this scenario, we added a new way to “escape” the
parsing of command lines. If you use a magic parameter --%, we stop
our normal parsing of your command line and switch to something much
simpler. We don’t match quotes. We don’t stop at semicolon. We
don’t expand PowerShell variables. We do expand environment variables
if you use Cmd.exe syntax (e.g. %TEMP%). Other than that, the
arguments up to the end of the line (or pipe, if you are piping) are
passed as is. Here is an example:
echoargs.exe --% %USERNAME%,this=$something{weird}
Arg 0 is <jason,this=$something{weird}>
This thread is 5 years old so maybe times have changed, but the current answer that worked for me was to use the backtick (`) symbol to escape the special character.
In my case, it was a dollar sign in a directory path that was failing. By putting a backtick before the dollar sign, everything worked.
Before:
$dir = "C:\folder$name\dir" # failed
After:
$dir = "C:\folder`$name\dir" # succeeded
Related
This is a deceptively complex issue, but I'll do my best to explain the problem.
I have a simple wrapper script as follows called VSYSCopyPathToClipboard.ps1:
param (
[Parameter(Mandatory,Position = 0)]
[String[]]
$Path,
[Parameter(Mandatory=$false)]
[Switch]
$FilenamesOnly,
[Parameter(Mandatory=$false)]
[Switch]
$Quotes
)
if($FilenamesOnly){
Copy-PathToClipboard -Path $Path -FilenamesOnly
}else{
Copy-PathToClipboard -Path $Path
}
Copy-PathToClipboard is just a function I have available that copies paths/filenames to the clipboard. It's irrelevant to the issue, just assume it does what it says.
The way the wrapper is called is through the Windows right click context menu. This involves creating a key here: HKEY_CLASSES_ROOT\AllFilesystemObjects\shell\.
Mine looks like this:
The command is as follows:
"C:\Tools\scripts\BIN\SingleInstanceAccumulator.exe" -q:' "-c:pwsh -noprofile -windowstyle hidden -Command "C:\Tools\scripts\VSYSCopyPathToClipboard.ps1" -Path $files" "%1"
And similarly for the "Copy as Filename":
"C:\Tools\scripts\BIN\SingleInstanceAccumulator.exe" -q:' "-c:pwsh -noprofile -windowstyle hidden -Command "C:\Tools\scripts\VSYSCopyPathToClipboard.ps1" -FilenamesOnly -Path $files" "%1"
I am using a tool here called SingleInstanceAccumulator. This allows me to pass multiple selected files to a single instance of PowerShell. If I didn't use this program and ran my command with multiple files selected it would launch multiple instances of PowerShell for each file selected. It's the next best thing to creating your own shell extension and implementing IPC etc.
This has been working great until today when I encountered a file with a single quote in its filename (I.E.testing'video.mov) and the entire script failed. It's failing because the delimiter I'm using with SingleInstanceAccumulator is also a single quote and PowerShell sees no matching quote... thus errors out.
I could fix this if my variables were static by just doubling up the offending single quote, but since my parameters are files I have no opportunity to escape the single quote beyond renaming the file itself ... which is a non-solution.
So now I have no clue how to handle this.
My first try at solving the problem was as such:
Create a batch file and redirect my registry command to it.
Change the SingleInstanceAccumulator delimiter to '/' (All files will be separated by a forward slash.)
Replace the offending single quote to two single quotes.
Replace the '/' delimiters with single quotes.
Finally pass the whole argument list back to Powershell.
This image demonstrates how the above process looks:
This is the batch file's code:
#echo off
setlocal EnableDelayedExpansion
:: This script is needed to escape filenames that have
:: a single quote ('). It's replaced with double single
:: quotes so the filenames don't choke powershell
:: echo %cmdcmdline%
set "fullpath=%*"
echo Before
echo !fullpath!
echo ""
echo After
set fullpath=%fullpath:'=''%
set fullpath=%fullpath:/='%
echo !fullpath!
:: pwsh.exe -noprofile -windowstyle hidden -command "%~dpn0.ps1 -Path !fullpath!
pause
Once I got that wired up I started celebrating ... until I hit a file with an ampersand (&) or an exclamation point (!). Everything fell apart again. I did a whole bunch of google-fu with regards to escaping the & and ! characters but nothing suggested worked at all for me.
If I pass 'C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\testing&video.mov' into my batch file, I get 'C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\testing back.
It truncates the string at the exact position of the ampersand.
I feel like there has to be a way to solve this, and that I'm missing something stupid. If I echo %cmdcmdline% it shows the full commandline with the &, so it's available somehow with that variable.
In conclusion: I'm sorry for the novel of a post. There is a lot of nuance in what I'm trying to accomplish that needs to be explained. My questions are as follows:
Can I accomplish this with Powershell only and somehow pre-escape single quotes?
Can I accomplish this with a batch file, and somehow pre-escape & and ! (and any other special characters that would cause failure)?
Any help at all would be hugely appreciated.
Edit1:
So in the most hideous and hackish way possible, I managed to solve my problem. But since it's so horrible and I feel horrible for doing it I am still looking for a proper solution.
Basically, to recap, when I do either of these variable assignments:
set "args=%*"
set "args=!%*!"
echo !args!
& and ! characters still break things, and I don't get a full enumeration of my files. Files with & get truncated, etc.
But I noticed when I do:
set "args=!cmdcmdline!"
echo !args!
I get the full commandline call with all special characters retained:
C:\WINDOWS\system32\cmd.exe /c ""C:\Tools\scripts\VSYSCopyPathToClipboardTest.bat" /C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\KylieCan't.mov/,/C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\The !Rodinians - Future Forest !Fantasy - FFF Trailer.mov/,/C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\Yelle - Je Veu&x Te Voir.mov/,/C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\Erik&Truffaz.mov/,/C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\my_file'name.mov/,/C:\Users\futur\Desktop\Testing\Video Files\MOV Batch\testing&video.mov/"
So what I did was simply strip out the initial C:\WINDOWS\system32\cmd.exe /c ""C:\Tools\scripts\VSYSCopyPathToClipboardTest.bat" part of the string:
#echo off
setlocal enableDelayedExpansion
set "args=!cmdcmdline!"
set args=!args:C:\WINDOWS\system32\cmd.exe=!
set args=!args: /c ""C:\Tools\scripts\VSYSCopyPathToClipboard.bat" =!
set args=!args:'=''!
set args=!args:/='!
set args=!args:~0,-1!
echo !args!
pwsh.exe -noprofile -noexit -command "%~dpn0.ps1 -Path !args!
And... it works flawlessly. It handles any crazy character I throw at it without needing to escape anything. I know It's totally the most degenerate garbage way of approaching this, but not finding a solution anywhere leads me to desperate measures. :)
I am probably going to make the string removal a bit more universal since it literally breaks if I change the filename.
I am still VERY much open to other solutions should anyone know of a way to accomplish the same thing in a more elegant way.
A fully robust solution based on PowerShell's -Command (-c) CLI parameter that can handle ' characters in paths as well as $ and ` ones requires a fairly elaborate workaround, unfortunately:[1]
Use an aux. cmd.exe call that echoes the $files macro as-is and pipe that to pwsh.exe; make SingleInstanceAccumulator.exe double-quote the individual paths (as it does by default), but use no delimiter (d:"") in order to effectively output a string in the form "<path 1>""<path 2>""...
Make pwsh.exe reference the piped input via the automatic $input variable and split it into an array of individual paths by " (removing empty elements that are a side effect of splitting with -ne ''). The necessity for providing the paths via the pipeline (stdin) is discussed in more detail in this related answer.
The resulting array can safely be passed to your scripts.
Also, enclose the entire -Command (-c) argument passed to pwsh.exe in \"...\" inside the "-c:..." argument.
Note: You may get away without doing this; however, this would result in whitespace normalization, which (however unlikely) would alter a file named, say, foo bar.txt to foo bar.txt (the run of multiple spaces was normalized to a single space).
Escaping " characters as \" is necessary for PowerShell's -Command (-c) CLI parameter to treat them verbatim, as part of the PowerShell code to execute that is seen after initial command-line parsing, during which any unescaped " characters are stripped.
Therefore, the first command stored in the registry should be (adapt the second one analogously; note that there must be no space between the echo $files and the subsequent |):
"C:\Tools\scripts\BIN\SingleInstanceAccumulator.exe" -d:"" "-c:cmd /c echo $files| pwsh.exe -noprofile -c \"& 'C:\Tools\scripts\VSYSCopyPathToClipboard.ps1' -Path ($input -split '\\\"' -ne '')\"" "%1"
Note:
If you modified your scripts to accept the paths as individual arguments rather than as an array, a much simpler solution via the -File CLI parameter (rather than -Command (-c)) is possible. This could be as simple as decorating the $Path parameter declaration with [Parameter(ValueFromRemainingArguments)] and then invoking the script without naming the target parameter explicitly (-Path):
"C:\Tools\scripts\BIN\SingleInstanceAccumulator.exe" -d:" " "-c:pwsh.exe -noprofile -File \"C:\Tools\scripts\VSYSCopyPathToClipboard.ps1\" $files" "%1"
Note the use of -d:" " to make SingleInstanceAccumulator.exe space-separate the (double-quoted by default) paths. Since -File passes the pass-through arguments verbatim, there is no concern about what characters the paths are composed of.
Self-contained PowerShell sample code:
The following code defines a Copy Paths to Clipboard shortcut-menu command for all file-system objects (except drives):
No separate .ps1 script is involved; instead, the code passed to -Command / -c directly performs the desired operation (copying the paths passed to the clipboard).
The following helps with troubleshooting:
The full command line with which PowerShell was invoked ([Environment]::CommandLine) is printed, as is the list of paths passed ($file)
-windowstyle hidden is omitted to keep the console window in which the PowerShell commands visible and -noexit is added so as to keep the window open after the command has finished executing.
Prerequisites:
Download and build the SingleInstanceAccumulator project using Visual Studio (using the .NET SDK is possible, but requires extra work).
Place the resulting SingleInstanceAccumulator.exe file in one of the directories listed in your $env:Path environment variable. Alternatively, specify the full path to the executable below.
Note:
reg.exe uses \ as its escape character, which means that \ characters that should become part of the string stored in the registry must be escaped, as \\.
The sad reality as of PowerShell 7.2 is that an extra, manual layer of \-escaping of embedded " characters is required in arguments passed to external programs. This may get fixed in a future version, which may require opt-in. See this answer for details. The code below does this by way of a -replace '"', '\"' operation, which can easily be removed if it should no longer be necessary in a future PowerShell version.
# RUN WITH ELEVATION (AS ADMIN).
# Determine the full path of SingleInstanceAccumulator.exe:
# Note: If it isn't in $env:PATH, specify its full path instead.
$singleInstanceAccumulatorExe = (Get-Command -ErrorAction Stop SingleInstanceAccumulator.exe).Path
# The name of the shortcut-menu command to create for all file-system objects.
$menuCommandName = 'Copy Paths To Clipboard'
# Create the menu command registry key.
$null = reg.exe add "HKEY_CLASSES_ROOT\AllFilesystemObjects\shell\$menuCommandName" /f /v "MultiSelectModel" /d "Player"
if ($LASTEXITCODE) { throw }
# Define the command line for it.
# To use *Windows PowerShell* instead, replace "pwsh.exe" with "powershell.exe"
# SEE NOTES ABOVE.
$null = reg.exe add "HKEY_CLASSES_ROOT\AllFilesystemObjects\shell\$menuCommandName\command" /f /ve /t REG_EXPAND_SZ /d (#"
"$singleInstanceAccumulatorExe" -d:"" "-c:cmd /c echo `$files| pwsh.exe -noexit -noprofile -c \\"[Environment]::CommandLine; `$paths = `$input -split [char] 34 -ne ''; `$paths; Set-Clipboard `$paths\\"" "%1"
"# -replace '"', '\"')
if ($LASTEXITCODE) { throw }
Write-Verbose -Verbose "Shortcut menu command '$menuCommandName' successfully set up."
Now you can right-click on multiple files/folders in File Explorer and select Copy Paths to Clipboard in order to copy the full paths of all selected items to the clipboard in a single operation.
[1] An alternative is to use the -f option instead, which causes SingleInstanceAccumulator.exe to write all file paths line by line to an auxiliary text file, and then expands $files to that file's full path. However, this requires the target scripts to be designed accordingly, and it is their responsibility to clean up the auxiliary text file.
Been fighting with Powershell to do what I need it to do. It might be a simple solution but I've not found it.
If this question is a duplicate, I do apologize, but I couldn't find the answer I was looking for.
TL;DR at the bottom.
So, to the issue I have.
I'm trying to add a PS script to context menu via regedit that deletes a folder + files within, it works great on folders without any spaces in it but when I try to delete a folder with spaces (like "New Folder") it throws an error and closes.
(Tried looking for a pause / sleep command with Remove-Item but no luck, except for long scripts with error handling etc.)
I suspect the error is similar to
Remove-Item : A positional parameter cannot be found that accepts argument 'Folder'.
At line:1 char:12
+ Remove-item <<<< New Folder
+ CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
And the code I'm currently using is
cmd /c PowerShell Remove-Item "%1" -recurse -force
I've tried different variations for it to work without luck.
I.E replacing "%1" with "pathAsString", added another "% 1", added wildcard "* *", removed the flags.
Some different variations on the code I've tried:
cmd /c PowerShell Remove-Item \"%1\" -recurse -force
cmd /c PowerShell Remove-Item & "{"%1" -recurse -force"}"
TL;DR
cmd /c PowerShell Remove-Item "%1" -recurse -force ignores folders with white spaces, tried various things.
Usage in Context Menu (via Regedit).
Might be a solution that's obvious but I don't see it.
The following worked for me:
cmd /c PowerShell -command "& {Remove-Item -path '%1' -recurse -force -confirm:$false}"
When using cmd.exe, there is no such thing as a script block. This means the value passed to -command will always be a string. I added the single quotes ('') around %1 to keep your double quotes ("") with your argument. Apparently, this method will fail if you have a single quote (') in your file path. Also the call operator & is not required even though the online documentation says it is.
See PowerShell.exe Command-Line Help for more information on how to use PowerShell.exe.
See About Quoting Rules for more information on how PowerShell single and double quotation marks work.
One of your attempts:
cmd /c PowerShell Remove-Item \"%1\" -recurse -force
actually does work, albeit only if those paths that have embedded spaces don't contain multiple adjacent spaces (see the bottom section for why your first attempt with "%1" instead of \"%1\" didn't work).
To make the command robust (and also more efficient), use the following variation, which does not involve cmd.exe (because it isn't necessary), and the command to pass to PowerShell is enclosed in "..." as a whole with embedded " escaped as \" (as in your attempt):
powershell.exe -noprofile -command "Remove-Item -LiteralPath \"%1\" -Recurse -Force"
PowerShell CLI options used:
-noprofile suppresses loading of the current user's profile ($PROFILE), which would only unnecessarily slow down the command (or, worse, could change its behavior).
-command tells PowerShell that the remaining arguments are a PowerShell command (a piece of source code, as distinct from -file, which is used to invoke a script)
While you don't strictly need to specify -command in Windows PowerShell, because it is implied, that is no longer the case in PowerShell Core, which defaults to -file.
The Remove-Item command passed to PowerShell:
Enclosing the entire PowerShell command in "..." ensures that whitespace inside the command is preserved as-is, which matters with paths that happen to contain runs of multiple spaces, e.g. "c:\Users\jdoe\Invoices<space><space>2018"
\" is how PowerShell requires nested (embedded) " chars. with to be escaped when called from the command line with -command - see below for an explanation.
-LiteralPath ensures that Remove-Item interprets the path literally rather than as a wildcard pattern (as would happen by default, with the implied -Path parameter); while not very likely, paths such as c:\tmp\folder[] would break the command if taken as a wildcard.
Caveats:
Due to (ultimately) using double quotes ("...") to enclose the path (the directory path that File Explorer expands %1 to), it becomes an expandable string, i.e., it is subject to string interpolation, which means that folder paths that contain $ characters (e.g., c:\tmp\$foo) could be misinterpreted.
You can suppress this interpolation by replacing \"%1\" with '%1', i.e., by using a single-quoted string (which PowerShell always treats literally), but the problem is that you then won't be able to use the command on folders whose paths happen to have ' chars. in them (e.g., c:\tmp\o'reilly)
Why just "%1" isn't enough:
cmd /c PowerShell Remove-Item "%1" -recurse -force, your (first) command line (which you're using as a command definition for File Explorer's context menus), is processed as follows:
File Explorer replaces %1 with the absolute path of the file for folder that was right-clicked, as-is - whether or not the path has embedded spaces; e.g.:
c:\Users\jdoe\Invoices 2018.
The resulting command line is then executed; e.g.:
cmd /c PowerShell Remove-Item "c:\Users\jdoe\Invoices 2018" -recurse -force
cmd /c is incidental here (and not needed): It essentially just relays the command line to PowerShell (via its executable, powershell.exe); e.g.:
powershell.exe Remove-Item "c:\Users\jdoe\Invoices 2018" -recurse -force
PowerShell first processes the individual arguments - Remove-Item, "c:\Users\jdoe\Invoices 2018", -recurse, -force by removing enclosing double quotes.
Since the -command option is implied, the quote-stripped arguments are re-joined with a space as the separator and then interpreted as a snippet of PowerShell source code; e.g.:
Remove-Item c:\Users\jdoe\Invoices 2018 -recurse -force
As you can see, the removal of the double quotes resulted in a broken PowerShell command, because the path with spaces now lacks quoting so that c:\Users\jdoe\Invoices 2018 is no longer recognized as a single argument and is instead interpreted as 2 arguments, prefix c:\Users\jdoe\Invoices followed by 2018 as its own, syntactically extraneous argument.
While using \"%1\" instead of "%1" alone would prevent the up-front quote stripping - by telling PowerShell that the " chars. are to be retained during initial argument parsing - additionally enclosing the entire PowerShell command in "..." is necessary to correctly preserve file paths with multiple adjacent spaces (even though such paths may be the result of a typo during folder creation):
Without overall enclosing "...", a \"-quoted path such as C:\Users\jdoe\Invoices<space><space>2018 would result in the following 2 arguments:
\"C:\Users\jdoe\Invoices
2018\"
When PowerShell later re-joins the individual arguments with a single space between them (after having recognized \" as an escaped " to be retained), before interpreting the resulting string as PowerShell code, it sees "C:\Users\jdoe\Invoices<space>2018", i.e., only a single space.
With overall enclosing "...", the entire PowerShell command is parsed as a single argument, with interior whitespace preserved as-is, which avoids the problem.
PS C:\> cd Program Files
When I give this command, I don't know why, but it is not accepting Program Files. The same command is working perfectly fine in cmd.
This is the error it shows:
Set-Location : A positional parameter cannot be found that accepts argument 'Files'.
At line:1 char:1
+ cd Program Files
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-Location], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
tl;dr
Since your directory name contains spaces, you must quote it, e.g.:
# Note: In PowerShell, 'cd' is an alias of 'Set-Location'
cd 'Program Files'
As stated in Maximilian Burszley's helpful answer, Program Files is parsed as two arguments, because spaces are used to separate command-line arguments.
Your attempt to use cd Program Files may be inspired by cmd.exe (the legacy Command Prompt), where this syntax indeed works; however, even there it conceptually violates the usual rules of argument parsing.
Therefore, you need to use a form of quoting in order to pass a value that contains spaces as a single argument.
You have several options to implement this quoting:
Use '...' around values that are literals, i.e., that should be used verbatim; a '...' string is called a verbatim (single-quoted) string.
Use "..." around values in which you want to embed variable references (e.g., $HOME) or subexpressions (e.g., $(Get-Date); that is, "..." strings perform string interpolation, and they're called expandable (double-quoted) strings.
Use ` to quote (escape) a single character; `, the so-called backtick, is PowerShell's general escape character.
Therefore, you could use any of the following:
cd 'Program Files'
cd "Program Files" # as there are no $-prefixed tokens, same as 'Program Files'
cd Program` Files # `-escape just the space char.
Also, you can use tab-completion to expand the (space-less) prefix of a space-containing path to its full form with quoting applied implicitly.
E.g., if you're in C:\ and you type:
cd Program<tab>
PowerShell automatically completes the command to:
cd '.\Program Files\'
Note how the Program Files (along with .\ to refer to the current dir. and a trailing \ to indicate a dir.) was automatically single-quoted.
Using wildcard expressions as arguments:
As noted, in PowerShell cd is a built-in alias of the Set-Location cmdlet.
Passing a path positionally - e.g. Set-Location 'C:\Program Files' - implicitly binds it to the -Path parameter; that is it, is equivalent to Set-Location -Path 'C:\Program Files'
-Path interprets its argument as a wildcard expression, so that you can do something like Set-Location C:\Win* in order to change to C:\Windows (assuming that the wildcard expression matches only one directory).
The tricky thing is that - unlike in cmd.exe - it isn't just * and ? that have special meaning in PowerShell wildcard expressions, but [ and ] as well (for character-set and character-range expressions such as [abc] and [a-c]), so that Set-Location Foo[1] will not work for changing to a directory literally named Foo[1].
In that case, you must use the -LiteralPath parameter -
Set-Location -LiteralPath Foo[1] - to ensure that the path is interpreted literally (verbatim).
cd C:\Program` Files\
` just escape the space in folder name.
The reason is invalid syntax. Each argument to a powershell command is separated by space, so what you're actually doing is something similar to:
Set-Location -Path Program -Arg2 Files
But Set-Location (aliased: cd) does not have any positional arguments for a second position, so it can't bind it to any parameters and use it in the command, hence the terminating error.
If you want a simpler cd alias, you could do something like this (in your $profile):
function ChangeDirectory {
param(
[Parameter(
Position = 0,
Mandatory,
ValueFromRemainingArguments
)]
[string[]] $Path
)
Set-Location -Path ($Path -join ' ')
}
Set-Alias -Name cd -Value ChangeDirectory
Do note, however, that if you're not specifying a relative path (.\), it will use the root path of your current drive (most likely, C:\). This can be tuned in the function to test for both locations (relative and drive-rooted), but logic for figuring out which one to use if they both exist would be tricky (or can always default to relative).
Use quotes (double or single) to go to the folder or path contains white spaces or special symbols.
Forexample:-
cd "C:\Users\LAPTOP0534\OneDrive - My Content (Active Directory)"
OR
cd 'OneDrive - My Content (Active Directory)\My Folder'
For your case it will be PS C:\> cd "Program Files"
Just run your command prompt as administrator .
See the picture attached.
It will run easily
This is because of the space between the sentences. Enter code here You complete the tab.
Replace PS F: > cd new folder with PS F: > cd "new folder" in the PowerShell. Or look at F: > cd './new folder'. I'm a beginner and you should try this.
I'm trying to run a PowerShell script from Windows cmd.exe. The input to the PowerShell script is a string, which contains newline characters using PowerShell backtick escaping - i.e:
`r`n
For demonstration purposes, the input string is then written to the console, and also dumped to a file.
The issue I have is that when the script is run from cmd.exe using the syntax
powershell.exe script.ps1 "TEST`r`nTEST"
The newline characters in the string are not treated as newline, and are included literally in both the console output and the output text file.
TEST`r`nTEST
However, if I run this from a PowerShell environment, I get the expected result (i.e. the newline characters are parsed correctly, and a newline is inserted in the appropriate location).
TEST
TEST
Similarly, if I pass in \r\n instead of the escaped newline characters through Windows cmd.exe, and do a .replace in the PowerShell script
$date = $data.replace("\r\n","`r`n")
I get the expected output:
TEST
TEST
Is anyone able to shed some light on why this happens?
The test script is as follows:
param([string]$data) # data to send
Write-Host $data
[IO.File]::WriteAllText('d:\temp.txt', $data)
return 0
And the file is called from the command line as:
powershell.exe script.ps1 "TEST`r`nTEST"
The script is running on Windows Server 2012 R2, using PowerShell v4.0
tl;dr
Use -Command and pass the entire PowerShell command as a single string; e.g.:
C:\> powershell -NoProfile -Command "script.ps1 \"TEST`r`nTEST\""
TEST
TEST
Note how the internal " instances are escaped as \", which PowerShell requires when called from the outside (alternatively, for full robustness, use "^"" (sic) in Windows PowerShell and "" in PowerShell (Core) v6+).
In your specific case,
powershell -NoProfile -Command script.ps1 "TEST`r`nTEST" would have worked too, but generally that only works as intended if the string has no embedded spaces.
Given that -Command is the default up to PSv5.1, your command - as currently posted - should work as-is.
As of PowerShell v5.1, arguments passed to powershell.exe from the outside:
ARE subject to interpretation by PowerShell, including string interpolation, by default and when you use -Command (i.e., specifying neither -File nor -Command currently defaults to -Command).
Caveat: The default behavior will change in v6: -File will be the default then - see the relevant change on GitHub.
are NOT subject to interpretation if you use -File to invoke a script - (after potential interpretation by cmd.exe) PowerShell treats all arguments as literal strings.
Caveat: This behavior is currently being discussed with respect to v6, given that it is overtly problematic in at least one case: trying to pass Boolean values.
Optional reading: Why you should pass the entire PowerShell command as a single argument when using -Command:
When you use -Command with multiple arguments, PowerShell essentially assembles them into a single command line behind the scenes before executing it.
Any "..."-quoting around the individual arguments is lost in the process, which can have unexpected results; e.g.:
C:\> powershell -NoProfile -Command "& { $args.count }" "line 1`r`nline 2"
3 # !! "line 1`r`nline 2" was broken into 3 arguments
Given that the outer "..." quoting was removed in the process of parsing the command line, the actual command line that PowerShell ended up executing was:
C:\ PS> & { $args.Count } line 1`r`nline 2
3
To illustrate why, let's look at an equivalent command that uses explicit quoting:
C:\ PS> & { $args.Count } "line" "1`r`nline" "2"
In other words: After the enclosing " were removed, the resulting token was broken into multiple arguments by spaces, as usual.
The parameter will need to be reinterpreted as a PowerShell string. Will this get you down the road?
The reason your -replace did not work is that the original string actually contains a backtick. It needs to be escaped in the search string.
C:\src\t>type p1.ps1
Param([string]$s)
Write-Host $s
$p = Invoke-Expression `"$s`"
Write-Host $p
$p2 = $s -replace "``r``n","`r`n"
Write-Host $p2
C:\src\t>powershell -noprofile -file .\p1.ps1 "TEST`r`nTEST"
TEST`r`nTEST
TEST
TEST
TEST
TEST
Carriage return and Linefeed are bytes with values 13 and 10, you can't write them, you can't see them.
As a convenience, when writing PowerShell code, the language will let you write:
"`r`n"
in a double quoted string, and when processing PowerShell source code (and at no other time), it will read those and replace them with bytes value 13 and 10.
It is this line of code in the PowerShell tokenizer which does it.
There is nothing special about backtick-n to the cmd.exe interpreter, and nothing special about having it in a string - you can put it there in a single quoted string
'`n'
or replacing it in a string - except that you have to note when the replacement happens. e.g. in your comment:
For example, if you pass in 'r'n and then replace 'r'n with 'r'n, the 'r'n is still output literally
Because your code
-replace "`r`n"
becomes
-replace "[char]13[char]10"
and your string passed in from outside contains
`r`n
and they don't match. Backtick-n in a string isn't magic, strings are not all interpreted by the PowerShell engine as PowerShell code, nor are parameters, or anything. And it's only in that context - when you write your -replace code, that is when the swap for actual newline characters happens.
Using Powershell v2 called from a batch file, I want to replace each CRLF in a file with just an LF. If a file only has LF without any CR, then I want all the LF to be left alone.
I do not want a terminating CRLF in the resultant file, if possible.
I found this question here on Stack Overflow, that seems to be a close match, but it does not specify a Powershell version requirement, nor does it specify the other criteria above. Hence this question.
The accepted answer for that question recommends this code:
$in = "C:\Users\abc\Desktop\File\abc.txt"
$out = "C:\Users\abc\Desktop\File\abc-out.txt"
(Get-Content $in) -join "`n" > $out
I slightly modified it, and adjusted it to work from within a batch file, to read:
powershell -Command "(Get-Content file1.txt) -join '`n' > file2.txt"
Unfortunately, this does not work. All LF's are converted to the string `n.
How can I get this to work?
Those before me are right you should use "`n"
When using PowerShell I recommend executing it the following switches:
-noninteractive indicate you do not want to interact with the powershell
-NoProfile - speeds up the things considerably (skips loading profile)
-ExecutionPolicy Bypass - bypasses security issues if you are on companies environment
Edit:
Sorry about the mistake you mentioned. I now have PowerShell 2.0 testing facility.
The fixed your example (the mistake was that you have to escape the double quotes due to the powershell.exe interpreting them). This approach does not work completely as it leaves CRLF at the end of the file:
powershell.exe -noninteractive -NoProfile -ExecutionPolicy Bypass -Command "& {(Get-Content file_crlf.txt) -join \"`n\" > file_lfonly.txt};"
However, the completely correct solution needs different approach (via IO.file class):
powershell.exe -noninteractive -NoProfile -ExecutionPolicy Bypass -Command "& {[IO.File]::WriteAllText('file_lfonly.txt', ([IO.File]::ReadAllText('file_crlf.txt') -replace \"`r`n\", \"`n\"))};"
This completely converts your CRLF to LF. Just small piece of warning it converts to ASCII not Unicode (out of scope of this question).
All examples are now tested on PowerShell v2.0.50727.
A couple of things:
Single quotes ' are literal - use double quotes " so that PowerShell knows you mean new line
If you need to escape double quotes within double quotes, use "" or `"
Edit:
Your original post worked for me, so looks like this is related to PowerShell 5 v 2, and I am unable to test the solution. Instead of escape characters, here is a solution using scriptblock:
powershell -Command {(Get-Content file1.txt) -join "`n" > file2.txt}
It's worth noting that this is trivial in Notepad++ and can be done for multiple files at once: