Coffee | Coding | Computers | Church | What does it all mean?
Add ConEmu to your VisualStudio Menu -> Tools -> External:
By copying the line from ConEmu's shell integration to get:
Command: C:\Program Files\ConEmu\ConEmu64.exe
Arguments: "{PowerShell} -cur_console:n"
Initial Directory: $(ProjectDir)
There’s a great Q and Answer at dijkstra-path-finding-in-c-is-15x-slower-than-c-version which starts with C++ code at 2ms vs C# at 38ms; and finishes with C# at 2.8ms.
On similar lines, the solution to this riddle — why-does-net-core-2-0-perform-worse-than-net-framework-4-6-1 — has nothing to do with the framework; it results from the slower performance of 64bit code compared to 32bit.
Which just goes to confirm what you might have suspected;
VMs aren’t that slow; and
For best performance, you have to understand your VM, and your language, and your O/S, and ultimately your CPU.
This seemed to me an error and I and was on the point of raising it as a bug on the Powershell github repo:
PS> "\this".Split( [char]'\', [StringSplitOptions]::RemoveEmptyEntries).Length # >> 2
Presumably it is because [StringSplitOptions]::RemoveEmptyEntries is coerced to a [char] and so the line is parsed as:
PS> "\this".Split( ([char]'\', [StringSplitOptions]::RemoveEmptyEntries) ).Length
Instead of as
PS> \this".Split( (,[char]'\'), [StringSplitOptions]::RemoveEmptyEntries).Length
If the first parameter is a string not a character then it works as expected:
PS> "\this".Split( '\', [StringSplitOptions]::RemoveEmptyEntries).Length # >> 1
But the really unfortunate case is :
PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).Length # >> 2
which results in
PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).[0] # >> $null # instead of # >> "this"
It turns out that it's fixed in Powershell 6 Beta; or to be more precise, it doesn't happen in PowerShell 6. What changed is that the underlying .Net framework has added new overloads to String.Split():
string[] Split(char separator, System.StringSplitOptions options) string[] Split(char separator, int count, System.StringSplitOptions options) string[] Split(string separator, System.StringSplitOptions options) string[] Split(string separator, int count, System.StringSplitOptions options)
Whereas PowerShell 5 only has these overloads available:
string[] Split(Params char[] separator) string[] Split(char[] separator, int count) string[] Split(char[] separator, System.StringSplitOptions options) string[] Split(char[] separator, int count, System.StringSplitOptions options) string[] Split(string[] separator, System.StringSplitOptions options) string[] Split(string[] separator, int count, System.StringSplitOptions options)
And so the best-match overload that PowerShell 6 chooses is different to PowerShell 5's best match.
chuser(1) - man page
Name
chuser- change the current user
Synopsis
chuser [options]
Options
-n, --now immediately terminate this user.
-s, --soft if painless termination protocols are available,
use them. This option is ignored on systems without
appropriate hardware.
-R, --recursive terminate users recursively. This option causes
chuser to spawn new chuser processes repeatedly
until a user capable of terminating it does so.
-v, --verbose replace the usual output of chuser with the
input from the microphone.
History
chuser is intended for users who are instructed to use it by
remote helpdesk operators. It is scheduled for depre-
cation when IT customer services are replaced by robots
with infinite patience.
Comments
chuser attempts to detach the current user from the current
machine. The result of running chuser is non-deterministic
and depends on available hardware. chuser typically fails when run
by a user who intended to run it, but may succeed when used
unwittingly.
chuser expects to run on a foreground thread, so attempting
to background it or run it in a terminal controlled by screen(1)
or tmux(1) may increase the chance of success.
See also
shutdown(8)
kill(1)
sudo rm -Rf /