I am running into a bit of a problem when attempting to use Powershell with NRPE. Now I ran this command,
command[alias_check_commerce_log]=cmd /c echo C:\Program Files\nrpe\plugins\file_checker.ps1; exit($LastExitCode) | powershell.exe -command -
in cmd and it went through without a hitch. Just when I call it via Icinga, for some odd reason, it spits out 'powershell.exeA' is not recognized as an internal or external command. Now I know the A is not supposed to be sitting with powershell.exe, so how would I keep this from happening? Keep in mind that the command is the same in the config as posted here. Checked all text in hopes of it just being a simple Typo. I just can't seem to wrap my head around this one and figure out how to keep this from happening. Any and all help is appreciated, thank you.
Probably file encoding. You likely copy/pasted the command line from a web site or something, and there is a special character after .exe.
Open the file where that command is defined in an editor that supports different encodings and hopefully one that can show whitespace and "special" characters, and inspect the file.
Or Start over and manually type the commands.
Related
I am experiencing a rather puzzling error while trying to perform a diff on two files using Visual Studio Code from the command line. I have a text file in the cloud where I save some work related notes. I need to resolve conflicts with other clients editing the file. Usually this only happens during a loss of connection though somehow I find myself having to resolve a lot of them so between this and other uses of diff I will use the usual syntax. It looks something like this:
code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"
My filename happens to have a '&' in it and this command launches the usual 2-way diff in VS Code and reads through the first file name with no problem but doesn't read past the second '&' and the resulting diff tab in VS Code looks something like:
R&D (cloud conflict 2-25-23).txt <-> R
Where the right side "R" doesn't exist. So it would seem '&' needs to be processed literally.
No problem, let's see if backslash \ is an accepted escape parameter...
code --diff "R\&D (cloud conflict 2-5-23).txt" "R\&D.txt"
Nope. Same problem. 🤔 In fact this outputs something even stranger:
Code diff tab:
&D (cloud conflict 2-25-23).txt <-> R
with shell output:
'D.txt' is not recognized as an internal or external command, operable program or batch file.
I also tried the carrot symbol '^' as an escape parameter to a similar effect. I just includes it in the first file and the editor still thinks the second file name is just "R".
The help file for the VS Code command line integration didn't have a lot to say about the --diff parameter other than a short description and I was hoping to get something about processing strings literally or escape characters. Perhaps another parameter that I need or maybe this has more to do with the shell in general.
I find it really strange that it can read the first full file name but breaks at the second '&'. Weirder still that if a supposed escape character is included in the second file name, it will omit that as well. 😵
For now all I can do is rename the file which is a bummer. 🤷♂️ I have VS Code version 1.75.0 on Windows 10 Home latest version/build and I'm using PowerShell version 5.1.19041.2364.
Edit: The issue definitely appears to be PowerShell related as it turns out. I was finally able to run this command successfully in a regular command prompt. (Simply typing "cmd" and Enter into the PowerShell window before running the diff command). Unfortunately, I happen to be running this command as part of PowerShell script. I may have to figure out how to run a CMD command from inside my PowerShell script if that is at all possible. I'm not sure. 🤔 If not, I need to figure out what exactly PowerShell is doing to my command when it reaches the '&' character.
tl;dr
You need a workaround:
cmd /c 'code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"'
Alternatively, using --%, the stop-parsing token:
code --diff "R&D (cloud conflict 2-5-23).txt" --% "R&D.txt"
Note: --% comes with fundamental limitations, notably the inability to reference PowerShell variables - see this answer.
Background information:
The root cause is that code is implemented as a batch file (code.cmd) and that cmd.exe, the interpreter that executes batch file inappropriately parses its list of arguments as if they had been submitted from INSIDE a cmd.exe session.
PowerShell, which - of necessity - has to rebuild the process command line behind the scenes on Windows after having performed argument parsing based on its rules, and - justifiably - places "R&D.txt" as verbatim R&D.txt on the process command line, given that the argument value contains no spaces.
The result is that cmd.exe interprets the unquoted R&D.txt argument on its command line as containing metacharacter &, which is its command-sequencing operator, causing the call to break.
Given that cmd.exe, the legacy Windows shell, is unlikely to receive fixes, the actively maintained PowerShell (Core) 7+ edition could as a courtesy compensate for cmd.exe's inappropriate behavior.
Doing so has been proposed in GitHub issue #15143, but, alas, it looks like these accommodations will not be implemented.
I've added an option to copy a proper UNC path to the context menu of all directories via PowerShell.
Edit:
I didn't mention that I'm actually using two different keys: One to copy the UNC of the current directory, and one to copy it from a different directory. I didn't think it would make a difference, but it does.
End Edit
Currently, the key value is as follows:
powershell.exe -WindowStyle Hidden -Command . <path I have to censor>\Save-To-Clipboard.ps1 \"%L%\"
Expected behaviour:
The PowerShell script is run quietly.
Actual behaviour:
A PowerShell Window pops up and closes itself.
The same thing happens with cmd.
I've tried using a VBS wrapper as well, but it needs the current path as an argument, which I can't figure out how to do. Simply putting it after the filename as you would in the command line results in the error:
This file does not have an app associated with it for performing this
action. Please install an app or, if one is already installed, create
an association in the Default Apps settings page.
Key value here:
<path I have to censor>\ClunkyWrapper.vbs \"%L%\"
Admittedly, this is my first time running a command from a registry key, and I can't seem to find any resources about this topic. (I might just not know what exactly to google for.) So I would be thankful for more general information on how to run commands from registry keys as well.
Okay, I found a way.
First of all, apparently whether you need to use %L% or %V% depends on the key. I can't tell you why, unfortunately.
That solves the error message of the VBA script, but it still wouldn't run like this.
So I then used wscript.exe, and it finally worked.
wscript.exe <secret path>\ClunkyWrapper.vbs "%V%"
I've got a bat script that does a few cmds and also runs a stack of powershell scripts. Sometimes it errors out on the second or third command because it's cutting off a few characters. It's also done this on xcopy commands following a powershell script and vice versa. So here is an example:
Bat file:
xcopy "\\server\####\####\######" "C:\######" /S/I/E/Y
powershell "C:\SetupVM.ps1"
output:
\\server\Hard Disks\******.vhdx
\\server\Virtual Machines\*******.XML
2 File(s) copied
C:\Users\*****>rshell "C:\SetupVM.ps1"
'rshell' is not recognized as an internal or external command,
operable program or batch file.
Has anyone seen this before? Any ideas on how to avoid it?
Try opening your batch file in Notepad, and then 'Save As...' and be sure to select the ANSI encoding. Then don't touch it in your other editor :D.
It seems related to this issue.
I ran into this trying to write a batch file in Atom, and I think it was automatically encoding it to UTF-8. Opening in Notepad and re-saving it using ANSI encoding solved it for me.
A complicating issue for me was that my script was switching back and forth between git branches during my batch file, and if the batch file was different between the branches it would start to execute only partial lines as the computer would try to pick up the next piece of the batch, and it was causing the same issue.
From what I can see, the command line does not recognize the 'rshell' command.
Check your enviroment variables or start the command from where 'rshell'.com/.exe is located.
Other than this there is not much to say without seeing the content of the powershell script...
I got some strange behaviour when executing a powershell script.
When I run my script using the ISE it works just fine.
When I open Powershell.exe and run my script it works just fine.
When I open cmd, and start my script using powershell.exe -noexit
./myscript.ps1, myscript works just fine.
When I double-click myscript however, powershell opens for some milliseconds, I see that it shows some error (red font) and the powershell window closes. I'm unable to track down the error causing this problem since the powershell windows closes to fast.
I even tried one single big try-catch block around my hole script, catching any [Exception] and writing it down to a log file. However: the log file is not generated (catch is not called).
How can I track that issue? What could possibly be causing the trouble?
Please note that my execution-policy is set to unrestricted.
Before trying the suggestion invoke this to see your current settings (if you want restore them later):
cmd /c FType Microsoft.PowerShellScript.1
Then invoke this (note that you will change how your scripts are invoked "from explorer" by this):
cmd /c #"
FType Microsoft.PowerShellScript.1=$PSHOME\powershell.exe -NoExit . "'%1'" %*
"#
Then double-click the script, it should not exit, -NoExit does the trick. See your error messages and solve the problems.
But now all your scripts invoked "from explorer" keep their console opened. You may then
remove -NoExit from the above command and run it again or restore your
original settings.
Some details and one good way to invoke scripts in PS v2 is here.
Unfortunately it is broken in PS v3 - submitted issue.
by default, for security reason when you double clic on a .ps1 file the action is : Edit file, not Run file .
to execute your script : right-click on it and choose run with powershell
I also wasn’t able to run a script by double clicking it although running it manually worked without a problem. I have found out that the problem was in the path. When I ran a script from a path that contained spaces, such as:
C:\Users\john doe\Documents\Sample.ps1
The scipt failed to run. Moving the script to:
C:\Scripts\Sample.ps1
Which has no spaces, solved the problem.
This is most likely an issue with your local Execution Policy.
By default, Powershell is configured to NOT run scripts that are unsigned (even local ones). If you've not signed your scripts, then changing your default double-click 'action' in Windows will have no effect - Powershell will open, read the execution policy, check the script's signature, and finding none, will abort with an error.
In Powershell:
Help about_execution_policies
gives you all the gory details, as well as ways to allow unsigned scripts to run (within reason - you'd probably not want to run remote ones, only ones you've saved onto the system).
EDIT: I see at the tail end of your question that you've set Execution Policy to 'unrestricted' which SHOULD allow the script to run. However, this might be useful info for others running into execution policy issues.
If you would catch the error you will most likely see this
The file cannot be loaded. The file is not
digitally signed. The script will not execute on the system. Please
see "Get-Help about_signing" for more details.
Because you are able to run it from the shell you started yourself, and not with the right mouse button click "Run With PowerShell", I bet you have x64 system. Manually you are starting the one version of PowerShell where execution policy is configured, while with the right click the other version of the PowerShell is started.
Try to start both version x64 and x86 version and check for security policies in each
Get-ExecutionPolicy
I was in exactly the same situation as described in the question : my script worked everywhere except when double-clicking.* When I double-clicked a powershell windows would open but then it will close after a second or so. My execution-policy is also set to unrestricted.
I tried the selected answer concerning FType Microsoft.PowerShellScript.1 but it didn't change anything.
The only solution I found was a work around: create a bat file which start the powershell.
Create a file, copy this and modify the path : powershell.exe -File "C:\Users\user\script\myscript.ps1"
Save it as a .bat
Double-click the bat
I also used .ahk to start my powershell with a shorcut and it didn't work when pointing directly to the powershell. I had to point to the .bat
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";