I am trying to unzip a file on server 2012r2 through chef. I get an error back "illegal characters in path". When I manually type the commands in the file is extracted exactly as it should, but doing it through chef it just does not want to work for some reason.
powershell_script 'test' do
code <<-EOH [System.Reflection.Assembly]::LoadWithPartialName("System.IO.Compression.FileSystem") | Out-Null
[System.IO.Compression.ZipFile]::ExtractToDirectory('c:\tmp\hp401n.zip', 'c:\tmp')
EOH
end
You need to escape your backslashes because they are getting processed by Ruby too, c:\\tmp\\hp401n.zip and C:\\tmp. Otherwise you probably have literal tab characters (\t) in the path.
Related
I'm trying to set up conda for PowerShell but keep running into a strange error. I'm using miniconda3 (installed for all users) and PS version 7.3.1.
The conda executable is added to $Env:PATH and I'm able to run conda init powershell, which creates a profile.ps1 file in my PowerShell directory with the following contents:
#region conda initialize
Contents within this block are managed by 'conda init' !!
If (Test-Path "C:\ProgramData\miniconda3\Scripts\conda.exe") {
(& "C:\ProgramData\miniconda3\Scripts\conda.exe" "shell.powershell" "hook") | Out-String | ?{$_} | Invoke-Expression
}
#endregion
However, when restarting the terminal, I get this error:
$Env:CONDA_EXE: The term '$Env:CONDA_EXE' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
InvalidOperation: The expression after '&' in a pipeline element produced an object that was not valid. It must result in a command name,
a script block, or a CommandInfo object.
Invoke-Expression: Cannot bind argument to parameter 'Command' because it is null.
Notice the strange character in the beginning. I've seen a few discussions that have led me to believe that this might have something to do with the encoding of the profile.ps1 file or perhaps even the encoding of the output of conda.exe (if that makes any sense). I've tried changing the encoding of the profile file to UTF-8 (without BOM) and ANSI, as suggested in other threads (here and here), but this has not solved the problem.
Another thing that might be relevant to this is that when I run conda init powershell, the profile.ps1 file is actually created in a directory that's not the same as my "actual" user directory. This is because my Windows user name contains an accented character, so instead of C:\Users\AndrásAponyi\Documents\WindowsPowerShell\profile.ps1, the file gets written to C:\Users\Andr�sAponyi\Documents\WindowsPowerShell\profile.ps1 and I have to manually copy it to the correct location.
The same conda installation works perfectly fine with PowerShell version 5.1.
It seems that the issue is with the output of conda.exe that contains an unexpected character. This is causing the PowerShell profile to fail. There are a few things that you can try to resolve this issue:
Remove the existing profile.ps1 file
Create a new user profile without accented characters in the name or
rename the existing user profile to remove the accented characters
Re-run conda init powershell
Start a new PowerShell session and check if the issue has been
resolved
If the problem persists, you can try uninstalling and reinstalling Miniconda.
When I use a installation directory ending with backslash to install something in unattended mode on Windows system
example.exe -q --sys.installationDir="C:\Program Files\test\" ....
, nothing get installed without any prompt.
But when I remove the trailing backslash, it works correctly.
example.exe -q --sys.installationDir="C:\Program Files\test" ....
It's weird that the directory ending with backslash works well for GUI mode on windows system.
Is there any requirement that the installation directory can't end with backslash for unattended mode on Windows system?
Why are there different requirements for directory formats between unattended mode and GUI mode for windows system?
Do not quote like this:
param="value"
but like this:
"param=value"
Also, the command line option for setting the installation directory is "-dir":
example.exe -q - dir "C:\Program Files\test"
I have an app deployed on a server that runs a PowerShell command to launch headless Chrome and print a website as a PDF but it fails to generate the file.
I tried running the command directly from PowerShell. It seems that when I try to generate the file in C:/Program Files or a folder within it, it silently fails. But then to some folders, like Download or where the app is deployed, it generates it fine. And to even other locations, like C:, it shows that I am missing permissions.
Chrome is installed on the server. I also tried this on my local machine and I'm getting the same results.
This is the failing command I'm using to try and generate a pdf within Program Files folder:
Start-Process -FilePath "C:\Program Files\Google\Chrome\Application\chrome.exe" -ArgumentList "--headless","--print-to-pdf=C:\Program Files\pdfFromPowershell.pdf","--no-margins","--enable-logging","https://google.com"
Command succeeds if the target folder is pointed to Downloads.
Why can't I generate a PDF within C:/Program Files folder (and possibly others) and what can I do to fix this?
Edit: I am actually using the following syntax for the command:
$chrome='C:\Program Files\Google\Chrome\Application\chrome.exe'; & $chrome --headless --print-to-pdf-no-header --print-to-pdf='C:\Program Files\temp\pdfFromPowershell.pdf' --no-margins https://google.com
The issue comes from Chrome.exe not understanding PowerShell's way of quoting, where it just wants double quotes for the path:
Start-Process -FilePath "C:\Program Files\Google\Chrome\Application\chrome.exe" `
-ArgumentList "--headless",
"--print-to-pdf=""C:\Program Files\pdfFromPowershell.pdf""",
"--no-margins","--enable-logging","https://google.com"
The need for double double-quotes only comes when you're looking to escape the quotes within a pair of double quotes, whereas single quotes would work too. I know, confusing, so here's an example:
# escape the double quotes inside double quotes by doubling quotes inside.
"--print-to-pdf=""C:\Program Files\pdfFromPowershell.pdf"""
# using single quotes this should work as well, where only one pair is needed.
'--print-to-pdf="C:\Program Files\pdfFromPowershell.pdf"'
For windows 7/8/9/10/11 users native inbuilt MSEdge can do this very simply (no need to add another chromium or slow it down it is instant from a cmd line or shortcut)
For 32bit users run
"C:\Program Files\Microsoft\Edge\Application\msedge.exe" --headless --print-to-pdf="C:\whichever folder\PDFfromCMD.pdf" https://google.com
For 64bit users run
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --headless --print-to-pdf="C:\whichever folder\PDFfromCMD.pdf" https://google.com
Note --no-margin or --no-margins does nothing other than make the line longer, and older --export-tagged-pdf is no longer needed as its the current default, however you may wish to add --print-to-pdf-no-header or some other options to slow down premature building as its so fast the html may not have fully loaded so perhaps you may use --run-all-compositor-stages-before-draw
Microsoft docs will refer you to a list of switches for chrome which can be found at https://peter.sh/experiments/chromium-command-line-switches/
so run this way we can print and view this question (and answers) note I did not switch off headline(s) so have both a timestamp and full title, and in the footline(s) a hyperlink to this page and number of pages.
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --headless --print-to-pdf="%userprofile%\desktop\pdfFromcmd.pdf" --enable-logging https://stackoverflow.com/questions/72018079/why-cant-chromes-print-to-pdf-powershell-command-generate-a-pdf-to-some-fold && "%userprofile%\desktop\pdfFromcmd.pdf"
Basically I am just trying to create a batch file to copy one file from one location to another location in Windows XP like the code below but failed. May I know why?
copy C:/Directory_A/the_file D:/Directory_B
When I execute the batch file I see this in the output:
The syntax of the command is incorrect.
Try using backslashes
copy C:\Directory_A\the_file D:\Directory_B
I am running this command in powershell:
sqlplus system/passwd#mydb #my_sql
I have tried it with and without backticks and various other versions I found via Google. I keep getting an error when the command is passed off to sqlplus and have been unsucessful in finding the fix. Hopefully someone here can help out?
The error I get is:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SP2-0042: unknown command " ■#" - rest of line ignored.
So I am sucessfully connecting to the database but there is an extra character being passed to sqlplus in front of the '#'. " ■#" in notepad++ looks like " ¦#"
If you created your SQL command file using a redirect (> or >>) in powershell - like:
myProgram > mySQL.out
and then run it like:
&sqlplus mypw/myuser#mydb.xyz.com "#mySQL.out"
Powershell may have saved the output file in UTF-16 format, which Sqlplus does not like.
(You can confirm by creating the exact same file by hand and then comparing it - byte count will be off and in KDiff you'll get message to the effect that the text is equal, but the files are not binary equal).
To fix - you need to do two things: :
Add some blank lines to the top of your SQL commands - Powershell will still write a BOM (Byte Order Mark) there and it looks like it's pretty hard to get it to avoid that - but sqlplus will just go by it, albeit giving an error - but will move on to the rest of your code OK.
And then run this command in powershell before creating your file: $PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'
See Changing PowerShell's default output encoding to UTF-8
I received this error:
SP2-0042: unknown command " ■S" - rest of line ignored.
and this fixed that - or at least I was able to run it. You can also just cut and past it from one window into another using Notepad++ and that will solve the BOM and encoding issue.
Update Problem Solved. This turned out being "not seeing the trees through the forest". I have been using these sql scripts for several years without issue called from a bash script. When I tried converting the bash script to powershell and ran into issues I blamed it on powershell. However; it turned out there was something corrupt in the sql file itself. There were no obvious errors when looking at the file in notepad++ even with show all symbols clicked and it was ANSI format. I determined it was the sql file itself when I manually ran sqlplus from a cmd window I still had the same error I was getting with powershell. I rewrote the script and saved it and the problem was fixed. I should have manually ran the script on day one and I probably could have resolved sooner.
I had the same problem. My issue was caused because the script file was saved as unicode. I don't know if this will help you or not, but here is how I fixed it:
Edit the script with notepad. Click File -> Save As. Change type from Unicode (or whatever) to ANSI, and save.
A couple of suggestions
Try the invoke operator:
&sqlplus system/passwd#mydb #my_sql
Try start-process:
start-process -NoNewWindow -FilePath sqlplus -ArgumentList #"
system/passwd#mydb #my_sql
"#
I had typical problem. The message was:
unknown command "and" - rest of line ignored.
The reason was an empty string in code.
e.g.
select ...
from ...
where ...
[empty string]
and ... < here was an error message
use as following
sqlplus -s system/passwd#mydb "#my_sql";