I am trying to install Metricbeat on a Windows 10 machine so we can start monitoring it. When I open Powershell and run the following commands:
PS > .\metricbeat.exe modules list
I get the error
I copied that command as is from the Metricbeat documentation. I have seen videos on youtube of people running similar commands successfully. Please, why am I getting that error and what can I do to get my metricbeat.exe powershell commands to work?
You're copying the command TOO literally.
you've entered in the prompt PS > .\metricbeat.exe modules list
where you should have entered .\metricbeat.exe modules list
the latter executes modules list action against an application named "metricbeat.exe" located in .\ which indicates the current directory.
the former executes a redirection > of the output of an application named PS or get-process with input of .\metricbeat.exe modules and an argument of list.
wherever you copied this command from intended "PS >" to represent the beginning of the prompt and you don't need to include it.
Just like the error says... :P
Related
So I am attempting to install some files from Send Grid via Composer usind the CommandLine.
I am following a tutorial with the link here https://www.youtube.com/watch?v=fEobqi3N7zw
The guy in the video has no problem using Composer via the Command Line in the Windows Command Prompt, but when I input the command $ go_www, my PC whines and stamps it's feet, giving me the following line:
'$' is not recognized as an internal or external command,
operable program or batch file.
In a nutshell, why?
System Information:
Windows 10 64x
I have looked at other posts on here, to no avail, I have tried opening the Command Line too as System Administrator, but to avail. I have tried restarting the system, to no avail, I can confirmed I have composer installed into the correct directory, to no avail .
$ in a shell indicates the shell is not owned by a superuser, it is not part of the command. Try running go_www. Also, the video you linked seems to be using a bash shell, whereas you appear to be running a Windows command prompt from the error message you included in your question, which might be a problem too.
In any case, go_www is an alias the video author uses to quickly navigate to the folder of interest. Try manually navigating there using cd.
Everytime when I work with Perl (only through cmd) I put in C:\Perl520\Perl64\bin\perl.exe before my script Test.pl.
Now I want to run my script by only typing Test.pl. I have already looked through similiar questions like:
https://docs.sdl.com/791187/706364/sdl-contenta-5-7/associating--pl-files-with-strawberry-perl--windows-only-
How Do I Run a Perl Script from Cmd without typing "perl" in front of the script path?
I want to change this WITHOUT needing Admin Rights, as these are restricted on my computer.
I have even tried writing this in cmd:
assoc .pl=PerlScript
ftype PerlScript=C:\Perl520\Perl64\bin\perl.exe "%1" %*
Also here I keep getting the error message "Access is denied".
Is it possible to change the settings in another way?
EDIT: I managed to make it work through the first link. Yet I couldn't make it further after step 6 as once again I would need admin rights.
At least I am now able to run a script by just typing Test.pl.
But when using an input file :Test.pl C:\input.txt
I once again get an error message "Could not locate file!"
When writing it like this, it works as usual:
C:\Perl520\Perl64\bin\perl.exe Test.pl C:\input.txt
AFAIK, the file type association mechanism does require local admin rights. You can right-click on the script file and then pick perl.exe from the "Open With" menu, but that won't let you pass command line arguments to the string.
You might just want to run pl2bat on scripts you use often.
I'm trying to install IBM Cloud CLI but there is a problem faced me when I do this.
I added the Path to environment variables but it didn't work too !
This happens because the iex (shorthand for Invoke-Expression) command is a Powershell command, but it is entered to Command prompt. The latter is the old command shell that dates back to the MS-DOS days of the 80's.
One can tell the difference from the fact that the window title bar says Command Prompt, not Powershell. Often - not always! - a Powershell session has blue background and command has black.
To run Powershell commands, start a Powershell session either by typing powershell and pressing enter into a command session, or by opening Windows Start menu and typing powershell (followed by enter).
I am having trouble launching an executable that I have created from a shell script. I would like to automate testing by running the program many times with different command line options to verify it is working.
When I type echo $SHELL, /bin/sh is displayed.
The following is my shell script:
#!/bin/sh
clear
echo "Running first test."
./myProgram
exit 0
When I run the script (sh myScript.sh), with myProgram in the same directory, I see the following output:
Running first test.
: not foundsh: line 4:
When executing the program ./myProgram, it runs as expected with no command line options.
I have also tried:
myProgram
./myProgram &
myProgram &
based on answers to somewhat similar questions, but they all result in the above error message.
Your newlines are goofed. Use dos2unix to fix.
why don't you try using the full path?
e.g., if myProgram is in /home/user1/bin, you can try /home/user1/bin/myProgram instead of ./myProgram. This should work.
You can also add the path to path variable, $PATH and directly call myProgram from anywhere.
Run "export PATH=$PATH:/home/user1/bin" on your terminal without the quotes. Note that this affects only your current termial session. If you want to permanently add the path, update your .bashrc file in your home directory with the following line:
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