TOPIC: CMD.EXE
Resolving Windows Update Error 0x80244019 on Windows 10
21st August 2015In Windows 10, the preferred place to look if you fancy prompting an update of the system is in the Update & Security section of the Settings application. At the top is the Windows Update, and the process usually is as simple as pressing the Check for updates button. For most of the time, that has been my experience, but it stopped working on my main Windows 10 virtual machine, so I needed to resolve the problem.
Initially, going into the Advanced Options section and deselecting the tick box for Give me updates for other Microsoft products when I update Windows helped. However, it seemed a non-ideal solution, so I looked further. When it was then that I found that manually resetting a system's Windows Updates components helped others, I tried that and restarted the system.
The first part of the process was to right-click on the Start Menu button and select the Windows PowerShell (Admin) entry from the menu that appeared. This may be replaced by Command Prompt (Admin) on your system on your machine, but the next steps in the process are the same. In fact, you could include any commands you see below in a script file and execute that if you prefer. Here, I will run through each group in succession.
From either PowerShell or the Command Prompt, you need to stop the Windows Update, Cryptographic, BITS (or Background Intelligent Transfer Service) and MSI Installer services. To accomplish this, execute the following commands at a command prompt:
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
With the services stopped, it is then possible to rename the SoftwareDistribution and Catroot2 folders so you can refresh everything to remove them. To accomplish this, execute the following pair of commands using either PowerShell or the Command Prompt:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
Once you have the folders renamed, then you can start the Windows Update, Cryptographic, BITS and MSI Installer services by executing the following commands in either PowerShell or the Command Prompt:
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
Once these have completed, you may close the PowerShell or Command Prompt window that you were using and restart the machine. Going into the Update & Security section of the Settings tool afterwards and pressing the Check for updates button now builds new versions of the folders that you renamed, and this takes a little while longer than the usual update process. Otherwise, you could let your system rebuild things in its own time. As it happens, I opted for manual intervention and all has worked well since then.
Windows commands for setting default applications for opening certain file types
18th August 2015On Friday, I was working on a system where a session is instantiated from a stored virtual machine that produces a fresh session every time, meaning that all previous changes get lost. What I have is a batch script that I run to reinstate what I need, and I encountered another task that I wanted it to do.
Part of my work involves the creation of plain text files with the extension lst and this is getting associated with SAS instead of Notepad. While you can reassign such associations using the GUI, it would be a bonus to do it via the command line too, so the assoc and ftype commands caught my interest. The first of these associates a file with a given extension with a desired file type, while the second shows the available file types together with the associated applications that open them. The assoc command also shows all the associations that are in place when it is executed with no parameters, and the ftype command does the same for file types.
Once you have picked out a file type with the ftype command, then the assoc can be used like the following:
assoc .lst=txtfile
The above associates an extension with a file type. In this, .lst files are going to get opened by Notepad because of the txtfile association. Though it did not do what I wanted on Friday due to system lockdown, it is good to know that this is possible and that even the Windows command line supports goodies like these.
Creating empty text files and changing file timestamps using Windows Command Prompt & Powershell
17th May 2013Linux and UNIX have the touch command for changing the creation dates and times for files. However, it also creates empty text files for you as well. In fact, there are times when I feel the need to do this sort of thing on Windows too and the following command accomplishes the deed when run in a Command Prompt window:
type nul > command.bat
Essentially, null output is sent to a file that is created anew, command.bat in this case. Then, you can edit it in Notepad (or whatever is your choice of text editor) and add in what you need. This will not work in PowerShell, so you need another command for that:
New-Item command.bat -type file1
This uses the New-Item command, which also can be used to create folders as well if you so desire. Then, the command becomes the following:
New-Item c:\commands -type directory1
Note that file1 in the previous example has become directory1 and there is the -force option should you need to overwrite what already exists for some reason...
That other use of the UNIX/Linux touch command can be performed from the Command Prompt too, and here is an example command:
copy /b file.txt +,,
The /b switch switches on binary behaviour for the copy command, though that appears to be the default action anyway. The + operator triggers concatenation and ,, gets around not having a defined destination because you cannot copy a file over itself. If that were possible, then there would no need for special syntax for changing the date and time for a file.
For doing the same thing with PowerShell, try the following:
(GetChildItem test.txt).LastWriteTime=Get-Date
The GetChildItem command has aliases of gci, dir and ls and the last two of these give away its essential purpose. Here, it is used to pick out the test.txt file so that its timestamp can be replaced with the current date and time returned by the Get-Date command. The syntax looks a little more complex, even if it achieves the same end. Somehow, that touch command is easier to explain. Are Linux and UNIX that complicated, after all?
Saving Windows Command Prompt & Powershell command history to a file for later useage
15th May 2013It's remarkable what ideas Linux gives that you wouldn't encounter that clearly in the world of Windows. One of these is output and command line history, so a script can be created. In the Windows world, this would be called a batch file. Linux usefully has the history command, and it does the needful for taking a snapshot like so:
history > ~/commands.sh
All the commands stored in a terminal's command history get stored in the commands.sh in the user's home area. The command for doing the same thing from the Windows command line is not as obvious because it uses the doskey command that is intended for command line macro writing and execution. Usefully, it has a history option that tells it to output all the commands issued in a command line session. Unless, you create a file with them in there, there appears to be no way to store all those commands across sessions, unlike UNIX and Linux. Therefore, a command like the following is a partial solution that is more permanent than using the F7 key on your keyboard:
doskey /history > c:\commands.bat
Windows PowerShell has something similar too, and it even has aliases of history and even h. All PowerShell scripts have file extensions of ps1 and the example below follows that scheme:
get-history > c:\commands.ps1
However, I believe that even PowerShell doesn't carry over command history between sessions, though Microsoft is working on adding this useful functionality. While they could co-opt Cygwin of course, that doesn't seem to be their way of going about things.
Shell swapping in Windows: PowerShell and the legacy command prompt
28th April 2010Until the advent of PowerShell, Windows had been the poor relation when it came to working from the command line when compared with UNIX, Linux and so on. A recent bit of fiddling had me trying to run FTP from the legacy command prompt when I ran into problems with UNC address resolution (it's unsupported by the old technology) and mapping of network drives. It turned out that my error 85 was being caused by an unavailable drive letter that the net use command didn't reveal as being in use. Reassuringly, this wasn't a Vista issue that I couldn't circumvent.
During this spot of debugging, I tried running batch files in PowerShell and discovered that you cannot run them there like you would from the old command prompt. In fact, you need a line like the following:
cmd /c script.bat
In other words, you have to call cmd.exe like perl.exe, wscript.exe and cscript.exe for batch files to execute. If I had time, I might have got to exploring the use ps1 files for setting up PowerShell commandlets, but that is something that needs to wait until another time. What I discovered though is that UNC addressing can be used with PowerShell without the need for drive letter mappings, not a bad development at all. While on the subject of discoveries, I discovered that the following command opens up a command prompt shell from PowerShell without any need to resort to the Start Menu:
cmd /k
Entering the exit command returns you to the PowerShell command line again, and entering cmd /? reveals the available options for the command, so you need never be constrained by your own knowledge or its limitations.
Automating FTP II: Windows
15th April 2008Having thought about automating command line FTP on UNIX/Linux, the same idea came to me for Windows too, and you can achieve much the same results, even if the way of getting there is slightly different. The first route to consider is running a script file with the ftp command at the command prompt (you may need %windir%system32ftp.exe to call the right FTP program in some cases):
ftp -s:script.txt
The contents of the script are something like the following:
open ftp.server.host
user
password
lcd destination_directory
cd source_directory
prompt
get filename
bye
It doesn't take much to turn your script into a batch file that takes the username as its first input and your password as its second for the sake of enhanced security and deletes any record thereof for the same reason:
echo open ftp.server.host > script.txt
echo %1 >> script.txt
echo %2 >> script.txt
echo cd htdocs >> script.txt
echo prompt >> script.txt
echo mget * >> script.txt
echo bye >> script.txt
%windir%system32ftp.exe -s:script.txt
del script.txt
The feel of the Windows command line (in Windows 2000, it feels very primitive, but Windows XP is better and there's PowerShell now too) can leave a lot to be desired by someone accustomed to its UNIX/Linux counterpart, yet there's still a lot of tweaking that you can do to the above, given a bit of knowledge of the Windows batch scripting language. Any escape from a total dependence on pointing and clicking can only be an advance.