Sending "Y" to chkdsk to run on C at next reboot

[Fr3M#Ket]

I have tried to write a script to require chkdsk to run on C drive on the next reboot so that the process can be set up as an automated task. But I cannot find a way to send enter Y in response to the enquiry that comes back from chkdsk (because the volume is in use and chkdsk cannot lock the c drive) as to whether I want to run chkdsk on the next reboot. I cannot see how to do it in a batch file, in tcmd, using sendkeys, or using AutoIt, or anything else. There must be a way. Can anybody help, please?

 

[mikea]

This sort of thing once worked for me, but I don't know if it can be done with chkdsk:

echo y | <name of program to send 'y' to>

In other words: pass the character 'y' to the standard input of the next app in the 'pipeline'.

 

[vefatica]

I have read that this will cause a chkdsk on the next reboot.

fsutil dirty set c:

 

[mikea]

That'd sure be better than "echo y | ..." (etc.)

 

[Charles Dye]

This sort of thing once worked for me, but I don't know if it can be done with chkdsk:

echo y | <name of program to send 'y' to>

In other words: pass the character 'y' to the standard input of the next app in the 'pipeline'.

Or:

chkdsk c: /f <<< y

Does pretty much the same thing, but without spawning a subshell. (IIRC, this syntax isn't available in TCC/LE.)

 

[Fr3M#Ket]

Thank you all for your help.

fsutil dirty set c: looks like it would work. Thanks for that idea. Does setting the dirty bit have any effect other than prompting chkdsk with the /f switch at the next reboot?

I found another solution using a small program that can be downloaded from sendkeysnet.blogspot.ca/2009/06/finally-keyboard-macro-you-can.html, and which looks like it could be useful.

The other ideas did not work for me when I tried them.

I tried playing around with the redirection operators > and &, but could only guess about handles.

I was intrigued by the suggestion chkdsk c: /f <<< y since I can find no reference anywhere to <<< as an operator. It is not mentioned in the Microsoft list of dos commands, and googling it brought up nothing.

I do now have 2 solutions, including the fsutil solution, but am still intrigued to know whether there is some dos command that could be added to a batch file to do that after chkdsk c: /f has run and generated its request for a 'y' or an 'n'.

The sendkeys solution was:
start chkdsk C: /f
SendKeys y{enter}
but for some reason I found that:
C:\WINDOWS\system32\cmd.exe /C chkdsk C: /f
SendKeys y{enter}
would not work, which I find most curious.

Would that I understood how to use dos, and handles and the many other programming concepts that I have yet to find in depth explanations of on the net. I am sure I would learn something significant about dos if I could find a direct solution in dos to the problem of how to send 'y' and 'return'. Fsutil sidesteps that very neatly of course. So do please let me know if you can think of a solution to that in dos, but I have to admit that it is academic now from the point of view of my initial objective.

 

[Charles Dye]

I was intrigued by the suggestion chkdsk c: /f <<< y since I can find no reference anywhere to <<< as an operator. It is not mentioned in the Microsoft list of dos commands, and googling it brought up nothing.

Not surprising, since you're using neither DOS nor a Microsoft shell! Type HELP REDIRECTION and then click on the link called "Here-string redirection" (or just scroll down to the very bottom of the page.)

 

[Fr3M#Ket]

Ok. What am I using, and where shall I type HELP REDIRECTION?

 

[Steve Fabian]

At the command prompt use the VER command. Unless it displays TCC, Take Command or 4NT (with a version number and operating system identification), you are not operating a JPsoft product as your command processor, and information in this Forum is not relevant to your environment.

Here is an explanation of terms. Shell, or command processor, or command interpreter, is the program which accepts and interprets commands from the keyboard, interfaces to the operating system, and displays its response. When the operating system is Unix, the three common ones are the Bourne-, Korn-, and C-shell. In Linux bash and zsh are the most common. For PC-DOS and MS-DOS the original was COMMAND.COM; one of the earliest (and best) alternates was 4DOS.COM from JPsoft. (For Windows NT it became 4NT; for the tabbed user interface TCMD - Take Command - it became TCC.) When Windows became the common name for Microsoft's operating systems, some publicist (not one who understood the difference between user interface and operating system) started to refer to the UI program CMD.EXE by the hieroglyphic symbol (i.e., icon) representing CMD.EXE as "the MS-DOS prompt", later shortened to "DOS prompt", not realizing that DOS stands for disk operating system, not a user interface program.

 

[Fr3M#Ket]

Steve, Thanks for your comments. I am indeed using cmd.exe, which I suppose is MS-DOS, and I appreciate what you say about the terminological slippage, and would agree that any improvement in terminological accuracy is illuminating. The VER command merely displays the windows version, but I do have Take Command installed, and I even have a licence for it! As I tried to indicate at the beginning of this discussion, I should be only to pleased to use Take Command to do the business - indeed I bought it because cmd.exe is hard to get to know - but have hitherto got the impression from what has been said and from my own brief inspection of it that it does not lend itself to the matter in hand. One day I hope to have a working understanding of the available 'shells', and so far as Take Command is concerned, that includes its relationship with the other shells in terms of what it and they can do.

 

[vefatica]

It's TCC.EXE you should be looking at. That's the JPSoft command interpreter (compare to CMD.EXE) which typically runs in the Take Command GUI. TCC.EXE is a console application and should be appropriate whenever CMD.EXE is. TCC is much more powerful than CMD.

 

[Fr3M#Ket]

Thanks Vefatica - it's good to read that. But how is the problem eased in TCC, other than by using the fsutil dirty set c: command? Is there a sendkeys equivalent in TCC? I see that it contains the 'here-string redirection' that Charles Dye referred to above, which is a very neat solution, and so I tried it but for some reason does not work - a manual n or y is still called for.

 

[vefatica]

Thanks Vefatica - it's good to read that. But how is the problem eased in TCC, other than by using the fsutil dirty set c: command? Is there a sendkeys equivalent in TCC? I see that it contains the 'here-string redirection' that Charles Dye referred to above, which is a very neat solution, and so I tried it but for some reason does not work - a manual n or y is still called for.

I was speaking quite generally. If you want to script actions, TCC is a much more powerful tool than CMD. Sending keystrokes probably won't work for anything but normal desktop interaction; it typically relies on emulating the actual pressing of keys. I suspect that TCC's "<<<" works differently ... by redirecting a program's standard input.

I just tried this:

v:\> CHKDSK c: /f <<< n
The type of the file system is NTFS.

Chkdsk cannot run because the volume is in use by another
process.  Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N)
v:\>

The prompt returned immediately, suggesting (I'm not sure) that CHKDSK actually accepted the "n". So maybe Charles's suggestion might work. In another test, I'm sure the redirection worked:

v:\> ftp <<< help
Commands may be abbreviated.  Commands are:

!  delete  literal  prompt  send
?  debug  ls  put  status
append  dir  mdelete  pwd  trace
ascii  disconnect  mdir  quit  type
bell  get  mget  quote  user
binary  glob  mkdir  recv  verbose
bye  hash  mls  remotehelp
cd  help  mput  rename
close  lcd  open  rmdir

v:\>

 

[Fr3M#Ket]

Thanks Vince. I am afraid that CHKDSK c: /f <<< y returns the same as CHKDSK c: /f <<< n. The SendKeys app that I mentioned above worked, as long as I commenced with Start chkdsk. I was hoping to get some useful set of generally applicable principles out of this - such as a general scheme for inputting data (using handles?). But working knowledge of scripting is hard won. I also took a look at AutoIt, but groping a way through that looks hard going too.

 

[Charles Dye]

The prompt returned immediately, suggesting (I'm not sure) that CHKDSK actually accepted the "n". So maybe Charles's suggestion might work.

It works; I tested before posting. Of course, the actual disk check doesn't happen until the next reboot -- but that's the way NT's CHKDSK has always worked.

 

[Fr3M#Ket]

I have copied below what I get, as copied from the TCC tab in Total Command. Am I doing something wrong?

TCC 15.01.56 Windows XP [Version 5.1.2600]
Copyright 2013 JP Software Inc. All Rights Reserved
Registered to Thomas Halford

[C:\Program Files\JPSoft\TCMD15]chkdsk c: /f <<< y
The type of the file system is NTFS.
Cannot lock current drive.

Chkdsk cannot run because the volume is in use by another
process. Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N)
This volume will be checked the next time the system restarts.

[C:\Program Files\JPSoft\TCMD15]

 

[Charles Dye]

I have copied below what I get, as copied from the TCC tab in Total Command. Am I doing something wrong?

No -- that's a success message! ("This volume will be checked the next time the system restarts.") You'll see the disk check the next time you reboot.

 

[Fr3M#Ket]

Got it! Thanks very much indeed. I have just rebooted, and it did indeed work. I overlooked the last line - I suppose because there was no record apparent other than the result of the y having been sent. The here-string redirection is very nice solution, and of course an affirmation of TCC.

I'd still be interested to know if there is a solution in cmd.exe. Something to do with handles?

It looks in the help file like if I want to write a batch file that runs in tcc I should substitute the file path of tcc.exe for the file path of cmd.exe. But what if I start the script with, for example, the Start command? How do I get that to run in TCC?

 

[Charles Dye]

I'd still be interested to know if there is a solution in cmd.exe. Something to do with handles?

Either Mike's or Vincent's approach would work in CMD.EXE. (Mike is doing almost exactly the same thing I am, only with CMD-compatible syntax. Vincent is just calling an external -- probably the most elegant solution of the three.)

It looks in the help file like if I want to write a batch file that runs in tcc I should substitute the file path of tcc.exe for the file path of cmd.exe. But what if I start the script with, for example, the Start command? How do I get that to run in TCC?

Give your batch file an extension of .BTM, and associate that extension with TCC. There's a script named TCCBATCH.BTM in your install directory that will set up the association for you.

 

[Fr3M#Ket]

Thanks Charles. Do you mean that "echo y | chksdsk.exe" should work? I thought I tried it and found that it did not, but if that is what Mike meant, I will try it again for the benefit of my education.

By an 'external', do you mean an operator that calls on another operator?

Will double clicking on .btm file, or running it as a scheduled task, start up TCC, or does Take Command need to be running already for that to work?

 

[Steve Fabian]

External usually, including in Charles' post above, means what the WHICH command reports, i.e., an executable (machine language) program which TCC uses to perform an action. In some instances it is part of the OS (or as in the case of fsutil.exe, is bundled with the OS). On my WinXP system TCC's which command displays
fsutil is an external : C:\WINDOWS\system32\fsutil.exe

There are no operators at the level of programming we talk about here.

More later.

 

[Steve Fabian]

Will double clicking on .btm file, or running it as a scheduled task, start up TCC, or does Take Command need to be running already for that to work?

As Charles wrote (see above), if you inform Windows that .BTM files are to be executed by TCC.EXE, by setting appropriate registry entries displayable by the ASSOC and FTYPE commands (see there), clicking or double clicking on the name of the .BTM batch file will cause Windows to start a new instance of TCC.EXE to process the batch file. OTOH if you already have a TCC instance running, either in a taab of TCMD or in its own window, you can just type its name at the command prompt for it to be executed (assuming it is on your path). In the file view window of TCMD with TCC in the currently active tab you can just double click on the name of the batch file for it to be processed in that TCC instance.
--
HTH, Steve

 

[Fr3M#Ket]

Many thanks to you all for all your help. All working nicely now.

 

[mikea]

It appears to me (I'm still using TCC 15.01) that...

chkdsk c: /f << n

had exactly the same result as...

chkdsk c: /f <<< n

I was a bit surprised -- I'd have expected the first "here-doc" command to wait for a "label" n as its final line of input before terminating. How are these two forms of "here-doc" expected to differ?

 

[kishor]

simple solution
If you need to press "y", AND THEN HIT "Enter",
it gets more complicated. You have to create
what is generally called a "script" containing
the exact keystrokes you need to press. You can
create it ahead of time, or as needed like this:

------------
ECHO Y>SCRIPT.TXT
ECHO.>>SCRIPT.TXT
TYPE SCRIPT.TXT|CHKDSK C: /F
------------

 

[Charles Dye]

simple solution
If you need to press "y", AND THEN HIT "Enter",
it gets more complicated. You have to create
what is generally called a "script" containing
the exact keystrokes you need to press. You can
create it ahead of time, or as needed like this:

------------
ECHO Y>SCRIPT.TXT
ECHO.>>SCRIPT.TXT
TYPE SCRIPT.TXT|CHKDSK C: /F
------------

That'll actually give you two newlines -- one from the first ECHO and one from the second. (Which is okay; CHKDSK doesn't need two, but the second won't hurt anything; and maybe some other program will need two lines of input.)

There are simpler ways of doing the same thing in TCC, though. In addition to here-documents and TEXT/ENDTEXT, you can also embed a carriage return with ^R and a line feed with ^N :

echo Y^R^N | chkdsk c: /f

(Only one ^R^N because ECHO automatically adds a pair.)