Does everything you do in the GUI in windows (i.e. through pointing, clicking and typing) have a command line equivalent, or are there some things (or maybe a lot of things) the command prompt can’t do?
FYI I'm very new to using the command line and just curious
Microsoft does not guarantee that, but it does gradually allow every changes on UI to have a related PowerShell cmdlet.
Thus, you'd better check out PowerShell, which is more related to server management, than programming.
Related
I am plagued by a very strange phenomenon. I tend to write fairly esoteric Powershell modules for stuff I do at work. Often, after running one of these, and the module has ended I will move onto some other tasks, and when I happen to bring up my Powershell console window again, several blank lines (or just blank "space") will have appeared in the buffer. It never appears right away, which is the most confounding part.
Afterwards, the blinking cursor exists at the end of this blank space, and the blank space cannot be "backspaced" (so it's not something inadvertently entering spaces or newlines). It's just there, as part of the buffer. I usually just clear the screen with cls to keep it from annoying me.
I used to just chalk this up to the buggy Windows Powershell 5.1 buffering. However now that I've begun using Powershell 7 (and Windows Terminal), I see that the issue still exists.
Here is a screenshot of a v7 Windows Terminal tab an hour or so after my module finished running:
Sometimes it seems the longer I wait the more blank space has appeared. Here is a screenshot of the same console tab about 20 hours later:
I'm sorry I don't have a better way of explaining this. I realize that without any code or pattern to analyze, that this is a very poor question, by SO standards, but I am just as confused as you are. The only pattern I've noticed is that this only seems to happen after I run my various custom modules. However this accounts for the majority of my Powershell usage, so it might be a red herring.
Usually my modules simply do some processing (talking to computers, AD, etc) and just output some information via Write-Host, and occasionally output a [PSCustomObject], which I always capture in a variable. Even if I was accidentally outputting some blank lines or something to the pipeline, I can't see how that would manifest as blank buffer space that grows over time. I thought maybe I was incorrectly killing async jobs or something and that was somehow causing this, but this happens even in purely synchronous code.
To be clear, in the screenshots above there is no code actually running. That module was the only thing I had run in this particular console tab/session, and it doesn't run any background processes. So I can't understand why the buffer is changing all on its own. In both screenshots, the tab/window is the same size as it was when the module first completed, so it's not just a bunch of spaces in the buffer that are being dynamically resized. And as noted, when the module fist completed there were NO rogue characters in the buffer at all.
One other thing about my usage is that it's all done on a remote VM, accessed through RDP, which I use daily. The only other thing I can think of is that maybe something about the console window being minimized/maximized/resized, the resolution changing, or the login session being connected/reconnected has something to do with it.
Does this sound familiar to anyone? Any ideas for what could be causing this or what I can try to understand the behavior better are much appreciated.
I've confirmed that this actually happens as a direct result of simply "restoring" and "maximizing" the Powershell console window and/or Windows Terminal window. When the issue is "present", doing this will often add another "set" of blank space to the buffer before the cursor. Minimizing seems to have no effect, only going from maximized to "restored" and back to maximized.
I've also confirmed that this has nothing to do with my custom modules. I can replicate the issue by simply opening a fresh, maximized console window/tab, running get-process and then "restoring" and maximizing. It doesn't happen every time though.
It also has nothing to do with my custom profile script, as it happens even on a freshly-imaged computer with no profile.
At this point I'm going back to blaming it on buffer/rendering/window manager implementation bugs in powershell and moving on with my life.
I first need to offer the disclaimer that I am barely a novice when it comes to scripting or coding, so I might be doing this all wrong in the first place. I'm running into an issue with a script I had written in powershell a while ago that is used on several hundred computers in my company daily to automate starting a certain app that everyone uses. So far everyone else hasn't had an issue except one machine.
Normally when I run the script, it starts the services and cli for the program which opens in a new window. Then the script, still open behind that, sends all of the key commands to that cli window, pauses for a brief line of user input after which it closes that cli window, does a few other clean up tasks and closes out itself.
The only difference on this one machine that's not working is the script won't pass the keystrokes to the cli window. If I put them in manually including the normal user input, it finishes the rest of the script just fine, but the cli window is just not receiving the keystroke input from the main script.
The only part of the script that send the keystrokes to the cli window is a few lines of this:
[System.Windows.Forms.SendKeys]::SendWait("Text{Enter}")
I have tried using the sleep command before and in between the key commands to make sure it's not going through the keystrokes to early. I've checked and windows had gone through an Update two days ago, but we would've heard about this issue right then if that was it. I'm at a loss for what the issue could be and would apreciate and help, tips, or direction to help figure this one out.
Is the console window the active window when the keys are sent? The documentation for the class you are calling indicates that it sends the keys to the active window. Not only that, but the documentation also seems to indicate that there are some issues that developers have run into when using that class to sends keys. I would try using the autoit powershell module instead. Autoit is its own scripting language which specializes in automating windows processes and being capable of automating interactions with windows forms, but also comes bundled with its own powershell module that I think is exactly what you need, so I would download the portable "zip" package, extract the powershell module from "Autoitx", and that should help you accomplish what you need
PowerShell automation especially when using SendKeys can / is glitchy due to many varying reasons. Can you use SendKeys sure, but you have to know the environment it will be run in and the needed performance details. Hence your futzing/guessing with Sleep.
There are purpose-built tools to help.
Auto HotKey
'PowerShell auto hotkey'
or the UIAutomation tool
'PowerShell automating other applications'
It seems like it is not all that easy to create an executable from a PowerShell script - do you know if it was ever meant to be an option?
I have found tools like PS2EXE, but still it does not seem like it was meant to be.
I am asking, if it is worth it to go the extra mile or leave it.
Background reason: I have some less technical users that need a smoother workflow.
As #Bill_Stewart kindly noted:
PowerShell is a shell that contains a powerful scripting language.
Which is perfectly in line with Microsoft's definition :
PowerShell is a task-based command-line shell and scripting language built on .NET.
Basically, wrapping it in an executable would go beyond its purpose. The nice thing about scripting is, that it's lightweight and task based. And in this case, that you can easily run it on multiple OS-ses.
So, I wouldn't go through the effort creating an exe.
If you want to run it easily, just create a .bat or .cmd file (if using Windows). On windows, I believe, you can also create a shortcut with command arguments and a little icon.
For Linux you clould use a .sh.
I'm running Console2, which I believe is just an interface to windows cmd
I have a custom batch file that does most of my dirty work for me, but there are lot of commands in it now. Is there a way I can get a tap autocomplete working for it in the windows command prompt?
For example: my script is called rob.bat and it takes in a various number of arguments
It'd like to type rob set{Tab} and then have it cycle through
setup_envvars
setup_userprefs
setup_whateverothersetupscriptsIhave
Is there a way to do this?
Console2 has no special provisions for tab completion and instead relies on the program running within it to provide such features. Picture Console2 as little more than something that runs a console program hidden somewhere, regularly polls that hidden window for changes, and forwards all input to that window; this is, in essence, what's happening.
Note that Console2 does nothing special with cmd. You can run any shell within it. As for customizing tab completion, cmd offers nothing of that sort. You may be able to change this by installing clink, which has extension points for Lua code. Another option would be PowerShell, which has customizable tab completion out of the box, either by wrapping your program in a function that provides the necessary parameters, or by writing a custom TabExpansion or TabExpansion2 function.
I keep typing "t eh" instead of " the" which is, of course, annoying in the amount of time it takes me to correct myself.
The obvious answer is "Learn to type, noob!" or at least to type more slowly and/or more correctly. This error is frighteningly consistent so it appears I've trained my muscle memory for that pattern already.
But I'm wondering if it's possible to write a small, windows portable script or application that, when it detects the incorrect sequence, backspaces and corrects it automatically at a layer where it would apply to any keyboard input.
Does C# have access to that layer of the OS that intercepts keypresses systemwide?
Will I run into UAC issues with Vista?
Am I re-inventing the wheel (ie, are there open source tools I can modify or use out of the box)?
In DOS this sort of thing was quite easy and one could make TSRs (Terminate and Stay Resident) programs that would, for instance, give you a calculator onscreen with a special keypress. Not to mention the many, many practical joke programs based on this concept (dial "M" for monster!)...
I would, of course, never suggest such a utility could be used that way for co-workers...
-Adam
On windows you could use AutoHotKey. That allows you to create little scripts or macros to automate and correct things like mistypes.
One use was posted on lifehacker which took the common mistyped words and corrected them. It is at http://lifehacker.com/192506/download-of-the-day-universal-autocorrect
UPDATE Per Comment: This is Free software and windows only as far as I know.
The above script is just an example of what it can do. There are a slew of scripts available at AutoHotkeys Site
I suggest AutoHotKey. If you've never used it before, have a quick read of the tutorial: http://www.autohotkey.com/docs/Tutorial.htm
The feature you are looking for is called "hotstrings." http://www.autohotkey.com/docs/Hotstrings.htm
In your case, your script would look something like:
::teh::the
That's it! Add other things you want corrected on additional lines. AutoHotkey scripts can be compiled so you don't have to install AutoHotKey on all of your machines.
It's a very cool program. It's primary use (for making custom hotkeys) rocks! These scripts are system wide so you'll also probably want to make a hotkey to be able to turn them off too!
EDIT: In a comment, it was mentioned that he actually types "t eh" (with a space in it) and I wondered if something additional would be needed for it to work. I just tested it and it works fine. Just install autohotkey, and create a file with the .AHK extension. In that file put in the following line
::t eh::the
and save the file. Then double-click on the AHK file to load AutoHotKey with your script (you'll see a green square in your system tray to let you know it is running). It should work fine!
Yes, you can use pinvoke commands from C# to intercept the low-level os commands. I recommend you take a look at http://www.pinvoke.net. The coding isn't easy but it does work.
I suggest learning to type more slowly. I also suffer from "teh" and "ahve" in part due to autocorrect giving me the leniency. If you forced yourself to retrain then you would not be at a disadvantage when using someone else's machine.
Not to mention the unfortunate event when you need to write "t eh" and are being prevented by an overzealous 'corrector'.