Press the shortcut key 'Ctrl+F5' in VSCode to run the Pester test file with the suffix '.tests.ps1'.
In 'about_Parsing.Tests.ps1' After you press "Ctrl+F5", the console will directly appear:d:\GitRepository\PowerShell\example\pester\about_Parsing\about_Parsing.Tests.ps1
The test is then run directly.
How to run tests in such a convenient way and use various invoke-pester parameters, such as -output detailed?
If you go to the Settings of VSCode and search for Pester, you should find a setting called:
PowerShell > Pester: Output Verbosity
You can set this to "detailed".
The setting also indicates that if you're using Pester v5 or newer you can also set this via the $PesterPreference variable which it uses by default. You could set this variable in your script or PowerShell profile.
$PesterPreference = [PesterConfiguration]::Default
$PesterPreference.Output.Verbosity = 'Detailed'
Related
I see this unnecessary file path information whenever I execute a program in the terminal section.
Is there a way to hide that file path?
This is not so much VSCode terminal related, rather it is more shell related (see What's the difference between Terminal, Console, Shell, and Command Line). Your VScode's terminal is running a shell internally, but a terminal is not much more than a display window that calls a shell's functions. So, in order to edit the prompt (which comes from the shell), we have to edit your shell config.
From your screenshot, it looks like the particular shell you're running is Powershell. Powershell has its own prompt that it generates each time before you run a command. It does so by calling the prompt() function (you can read more about it at Microsoft Docs).
Therefore, if you just want an empty prompt, then all you have to do is create an empty prompt function and add it to your powershell profile.
From your terminal, open your powershell profile file using VSCode (or any text editor)
# $profile is a variable in powershell
# that holds path of the powershell config
code $profile
Then add an empty prompt function into the profile
function prompt { }
Save the file and reopen another powershell instance in your VSCode terminal, and now it should look like this
PS>
If you're interested in further customizing this prompt, I would highly recommend looking into starship, a cross-platform shell prompt that can be used inside powershell. By default it's an even simpler arrow
❯
It only displays the most relevant paths, and can be customized to a much greater extent than the powershell prompt.
I am trying to configure dymola.mos file, here is an example of changing directory, but when I activate Dymola, it seems the working directory doesn't change at all, even though the log shows Dymola run the script.
My question is:
How could I make the cd command work in the dymola.mos file?
I assume you have activated the option Save startup directory. You can check this with the flag Advanced.StartupDirectory, which will be either 1 or 2. You can simply turn that off or follow the steps below.
From your command log we see that:
Dymola first executes the script <install-path/insert/dymola.mos
Then it restores the settings stored in setup.dymx
Hence the settings in setup.dymx override your working directory.
Instead of using <install-path/insert/dymola.mos you should use a custom .mos script, which is passed as first argument to dymola.exe on startup. This will always be executed last.
Example for Windows
Create the file startup.mos somewhere, e.g. in C:\dymola\startup.mos
Create a shortcut to Dymola.exe, (for Dymola 2021x: C:\Program Files\Dymola 2021x\bin64\Dymola.exe)
Add the .mos script as argument in the Target field in the properties of the shortcut. The result will be:
"C:\Program Files\Dymola 2021x\bin64\Dymola.exe" "C:\dymola\startup.mos"
In our Katalon Studio project we have a test case.
We like that test case to accept a parameter from the command line when running the test suite.
For example, we like to run the same test case one time with parameter=A and another with parameter=B.
This will enable our Jenkins to run different tests without the need to duplicate test cases again and again.
Is there a way to do it?
Actually, you can't specify your parameters in the command line. But it seems to be in demand by the community (Katalon - How to pass user defined parameters from command line)
Solution :
You can define your parameters in profiles. Each profile can contains the same parameters with different values, and can be chosen during the Test Suite execution.
You can choose the profile you need manually or by passing it in command line. To do it you only have to use the -executionProfile option:
katalon -noSplash -runMode=console -consoleLog -noExit -projectPath="C:\MY_PATH" -retry=0 -testSuitePath="Test Suites/MY_TEST_SUITES" -executionProfile="Profile_A"
Finally, don't forget to convert your step input Variables into Global Variables where you need in your Test Case. You can do that manually or by script :
import internal.GlobalVariable as GlobalVariable
GlobalVariable.my_variable
docs: Katalon Docs - Execution Profile (v5.4+)
Hoping it will help you.
Like post above but in more way of showing where to look for the answers.
After You open Your Project, look for Profile :
Need to add to your script(it should be added be default be still remember if you will get error about missing keyword)
You are ready to make your "Build CMD"
From version 5.10, it is possible to override profile variables from the command line.
So, if you have a GlobalVariable.parameter=A as the default, you can add
-g_parameter=B
to the command line command to switch it to B.
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've just recently completed my first nightly build script (first significant anything script, really) in powershell. I seem to have things working well, if not yet robustly (I haven't handled significant error-checking yet), but I found myself falling into an idiom around the Invoke-Expression cmdlet, and I'm wondering if I'm using it properly.
Specifically, I use a series of variables to build up command-lines that I will use to build the solution, then run the solution's unit tests. e.g., something like:
$tmpDir = "C:\Users\<myuser>\Development\Autobuild"
$solutionPath=$tmpDir+"\MyProj\MyProj.sln"
$devenv="C:\Program Files (x86)\Microsoft Visual Studio 10.0\common7\ide\devenv"
$releaseProfile="Release"
$releaseCommandLine="`"$devenv`" `"$solutionPath`" /build `"$releaseProfile`""
This works well enough, $releaseCommandLine contains the command line that I want to execute when I'm done. I then execute it via this line:
$output = Invoke-Expression "& $releaseCommandLine"
Is this the proper way to execute a manually-built command line from a powershell script? I thought initially that Invoke-Command would do it, but I must have been doing something wrong because I couldn't get that working at all for half an hour, and I got this working almost immediately.
I've followed this same pattern a few other times in this same script. Is this a best-practice?
Looks fine to me. Only thing I'd change is to use more Powershell features in place of fragile assumptions. E.g.:
use Join-Path instead of string concatenation
use the Env:\ provider to look up the %programfiles(x86)% dir (or better yet, use the HKML:\ provider to find the path - it's in SOFTWARE\Microsoft\VisualStudio\\InstallDir)
when I have to write a string that contains literal doublequotes and variable expansion, I usually fall back to the syntax below. Personal preference, obviously.
'"{0}" "{1}" /build "{2}"' -f $devenv, $solutionPath, $releaseProfile
In some cases I'd be inclined to use Process.Start() so that I could capture the stdout & stderr streams independently (and maybe even control stdin interactively, depending on the application).
PS - the '&' is not strictly necessary.
I think it is unnecessary to use Invoke-Expression here. I've done this with a lot of build scripts and it usually looks like this:
$vsroot = "$env:ProgramFiles(x86)\Microsoft Visual Studio 9.0"
$devenv = "$vsroot\Common7\IDE\devenv.exe"
$sln = Join-Path <source_root> Source\MyProj\MyProj.sln
& $devenv $sln /build Release
or
& $devenv $sln /build "Release|Any CPU"
Although lately, I have had some troubles with using devenv.exe (mis-behaving add-ins, etc), so now I use msbuild.exe:
$msbuild = 'C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe'
& $msbuild $sln /p:Configuration=Release
Currently MSBuild can handle C#, VB and C++ (invokes vcbuild) but it can't handle solutions with setup & deployment projects in them. However, I have found it to be more reliable than using devenv.exe.
BTW you typically need to invoke other tools (sn.exe, signtool.exe, mt.exe, etc) in a build script that are specific to the version of Visual Studio/.NET you want to build against. So it is usually best to configure your environment variables in the same way that the VS 2008 command prompt does. With the PowerShell Community Extensions installed, you can enable one line in the PSCX profile header to enable this for .NET 3.5/VS 2008 settings:
$Pscx:Preferences["ImportVisualStudioVars"] = $true