Minimising the command window running from a batch file

[Fr3M#Ket]

For a long time I suffered occasional mysterious losses of data from my organiser, usually noticed some time after the data had been entered, and suspected that they arose because something had brought processes to an abrupt halt while data that had been saved had yet to be flushed to my drives. So I wrote a batch file and run it as a scheduled task, and I have not noticed any more mysterious losses of data since. This supports but does not prove my suspicion, but rightly or wrongly is the background for my problem.

The content of my batch file is:

@Echo %date% %time% >>"d:\synclogs\synclog.log"

C:\WINDOWS\system32\cmd.exe /c C:\scripts\sync.exe >> "d:\synclogs\synclog.log"

@Echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>"d:\synclogs\synclog.log"
​

The problem is that when it runs it brings up a command window which can be disposed of only by manually minimising it. So I should like to be able to include something in either my batch file or the scheduled task to minimise or dispense with the command window. Googling around I found various suggestions but none of them worked for me. For example, see: http://www.computerhope.com/issues/ch000932.htm.

Can anybody suggest please how to achieve my objective? I should be delighted to do it in TCM, but would nevertheless be very interested to know how this can be done in the Windows command line.

 

[David Marcus]

"tcc /h" will run tcc in a hidden window. There is also "start /min", which you can use in tcc to start another tcc minimized.

 

[Fr3M#Ket]

Thanks David.

Assuming that what I wish to achieve cannot be done with a batch file in windows (but query), I have created a .btm file instead of a batch fille, and associated .btm files with tcc.exe, and the content of my .btm file is:

@Echo %date% %time% >>"d:\synclogs\synclog.log"

C:\scripts\sync.exe >> "d:\synclogs\synclog.log"

@Echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>"d:\synclogs\synclog.log"

Exit​

This is the same as my batch file, but for the omission of:

C:\WINDOWS\system32\cmd.exe /c​

and the addition of:

Exit​

The .btm file runs ok, both by double clicking on it and as a scheduled task, but does not minimise the tcc window. How do I get the tcc window to minimise when opened?

 

[vefatica]

You could make a shortcut to the BTMfile (or to [path\]tcc.exe /c the.btm) and set the shortcut to run minimized. That ought to work for the double-click. Perhaps (I never tried it) you can also schedule a task with the shortcut (LNKfile) as target.
And tasks have a "Hidden" option if that suits you.
As a last resort you could put "WINDOW MIN" in the BTMfile but you'd have to tolerate seeing the console briefly.

 

[Fr3M#Ket]

Thanks Vince.

How does one set a shortcut to run minimised?

How does one select the "Hidden" option? I found the reference in the help file to the /H switch, but since I am not explicitly starting TCC in the above btm file, I wonder how I can introduce the switch, if that is what is required.

Where would you put the "WINDOW MIN" in the BTM file?

Tom

 

[vefatica]

1. Right-click on the shortcut ... "Shortcut" tab ... "Run:" ... choose "Minimized".
2. TCC does have a "/H(idden)" startup option, but ... a console app can't cause itself to be started hidden, so you'd see it flash momentarily anyway. I was referring to the "Hidden" option for a scheduled task. In TaskScheduler, it's at the bottom of the task properties "General" tab.
3. I suppose I'd make "WINDOW MIN" a BTM's first line. But as I warned, you'll see it briefly before it's minimized.

 

[vefatica]

I did a little testing. A scheduled task specifying a shortcut file (.LNK) will start the target of the shortcut but it will not honor the shortcut's Minimized/maximized of the shortcut's startup directory. :-(
And a scheduled task's "Hidden" checkbox appatently only hides the TASKENG.EXE, not the target app. :-(
So I wrote a little MINSTART.EXE (attached), a windows app that won't open any windows of its own. I tested it with a scheduled task:

Run a program: [path\]minstart.exe
Arguments: [path\]tcc.exe
StartIn: some directory
Hidden: checked

It worked as desired ... I saw nothing except the TCC icon appearing on the taskbar.
You might try it in a task and give it the arguments

[path\]tcc.exe /c [path\]my.btm

Next I'll try a HIDESTART.EXE.

 

[Fr3M#Ket]

Thanks again Vince. And thanks for the minstart.exe. That's tremendous.

If I right click on a shortcut, run does not appear as an option. Could this be because I am still using XP?

Likewise, I have no option to run anything hidden in my scheduled task properties. Could this also be because I am still using XP?

I'll try adding WINDOW MIN as the first line of my batch file, although I should have thought ex ante that there would be no window to minimise until the batch file runs "C:\scripts\sync.exe >> "d:\synclogs\synclog.log", and that after it had run it would immediately close, so that WINDOW MIN would have no effect whether placed before or after "C:\scripts\sync.exe >> "d:\synclogs\synclog.log". Have I got the wrong idea there?

Did you create a link to the batch file, or to merely to an executable file? In XP, you can add a switch to an executable by putting it at the end of the target in the shortcut's properties, as shown in the attached .pdf, which is a link to the executable for my brother label printer program. But I am not sure how I could make use of that. If I made link to the .btm file, and added a switch at the end of the shortcut's properties, my thinking in my last paragraph would lead me to doubt whether it would apply to tcc.exe, unless that is the first step when the batch file is opened - which I suppose it may be - I will test it and confirm the result to you. That would represent a key difference from cmd.exe, since that I presume does not run until batch file gets to run C:\WINDOWS\system32\cmd.exe /c C:\scripts\sync.exe >> "d:\synclogs\synclog.log".

Perhaps if WINDOW MIN will work as a suffix to the target address in a link in XP, then so may the /H switch, so if one works, I will also try the other and confirm the result to you.

I am very curious about specifying a directory for a program to "start in". This is specified in the properties of both a link and a scheduled task in XP, and I have often wondered what the effect of so specifying is, and what is required. Does it make any difference? I have noticed in the past that a scheduled task would not work because of the file path of the .exe file in question, and got it working by moving it to folder in the root of C drive.

Tom

 

[Fr3M#Ket]

I have some results now.

WINDOW MIN worked in the BTM file. Creating a link (ie shortcut) to the BTM file and adding the /H switch at the end of the target in the shortcut's properties did not work - the tcc window failed to minimise.

Following the syntax you gave me for minstart.exe, I created the following string for the "run" box in a scheduled task:

C:\scripts\minstart.exe C:\Program Files\JPSoft\TCMD15\tcc.exe /c C:\scripts\Copy of Copy of sync script.btm​

but it did not quite work. TCC.exe appeared to start minimised, but no log was written as prescribed in my BTM file, which is at C:\scripts\Copy of Copy of sync script.btm.

So it looks like minstart worked, and tcc.exe ran, but for some reason the BTM file was not executed. Any idea why not?

 

[vefatica]

I have some results now.

WINDOW MIN worked in the BTM file. Creating a link (ie shortcut) to the BTM file and adding the /H switch at the end of the target in the shortcut's properties did not work - the tcc window failed to minimise.

Following the syntax you gave me for minstart.exe, I created the following string for the "run" box in a scheduled task:

C:\scripts\minstart.exe C:\Program Files\JPSoft\TCMD15\tcc.exe /c C:\scripts\Copy of Copy of sync script.btm​

but it did not quite work. TCC.exe appeared to start minimised, but no log was written as prescribed in my BTM file, which is at C:\scripts\Copy of Copy of sync script.btm.

So it looks like minstart worked, and tcc.exe ran, but for some reason the BTM file was not executed. Any idea why not?

"/H" is an argument to TCC.EXE. It belongs after TCC.EXE and before the name of any command, script, or program TCC is to run.
I'd be surprised if TCC actually started. Any single argument to MINSTART (to almost any program) which contains whitespace must be quoted. So you should be giving MINSTART the arguments

"C:\Program Files\JPSoft\TCMD15\tcc.exe" /c "C:\scripts\Copy of Copy of sync script.btm"

Add "/H" (before or after "/C") and the TCC, which is started minimized, will hide itself.

 

[vefatica]

I think XP is the same. Right click on a shortcut, choose "Properties". In the properties dialog, on the "Shortcut" tab, there's "Run:" (normal, min, max).

 

[Fr3M#Ket]

Thanks Vince.



I have got it working now with the following scheduled task:

"C:\Program Files\JPSoft\TCMD15\tcc.exe" /c /h "C:\scripts\Copy of Copy of sync script.btm"​

And the BTM contains:

@Echo %date% %time% >>"d:\synclogs\synclog.log"

C:\scripts\sync.exe >> "d:\synclogs\synclog.log"

@Echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>"d:\synclogs\synclog.log"

Exit​

I note that the effect of the /h switch is to minimise the tcc window, rather than hide it ab initio. I wonder why – is that what you would expect? Would HIDESTART.exe overcome that, so that the tcc window would be hidden ab initio?



Can I dispense with either the /c in the scheduled task or the Exit in the BTM file?



I never managed to get the minstart approach to work, even with the addition of quote marks, so that it read:

"C:\scripts\minstart.exe” “C:\Program Files\JPSoft\TCMD15\tcc.exe” \c “C:\scripts\Copy of Copy of sync script.btm"

I tried moving the /c to after "C:\scripts\minstart.exe”, and then removing it, but still to no avail.



You are right – I have found start minimised in the shortcut properties now, and, as you found on your system, the tcc window does not minimise as a result of selecting start minimised in the shortcut properties.



Tom

 

[vefatica]

Your attempt with MINSTART has a "\c". That should be "/c".
You probably want the "/c" (especially if TCC is hidden). Without it, TCC will keep running after it's done executing the BTMfile.
"/c" and/or "/h" are arguments to TCC; they belong right after "[path\]tcc.exe" and before any command, script, or app that you want TCC to execute.
Here, starting TCC with "/h" causes TCC to appear briefly (either taskbar icon or a full console plus taskbar icon) and then become hidden (console and/or taskbar icon disappear).
The shortcut\properties\minimized thingy works here if I 2click on the shortcut, but not with a scheduled task.
Attached is HIDESTART.ZIP.
With the one you started your last post with

"C:\Program Files\JPSoft\TCMD15\tcc.exe" /c /h "C:\scripts\Copy of Copy of sync script.btm"

I'd expect that TCC's console would appear briefly before TCC hides itself.

 

[Fr3M#Ket]

Thank Vince, for your advice and for Hidestart.

Perhaps Exit could be dispensed with in the BTM, if the /c switch is retained. I'll experiment in due course.

Same here with the shortcut\properties\minimized thingy.

Should Hidestart mean no initial tcc console?

I have not yet tried Hidestart because I still cannot get Minstart to work. When I enter the following into the run box of the scheduled task:

"C:\scripts\minstart.exe” “C:\Program Files\JPSoft\TCMD15\tcc.exe” /c “C:\scripts\Copy of Copy of sync script.btm"​

The /c changes to \c on applying the changes to the task. I wonder what I am doing wrong. Is it ok to add an argument to an argument? I am thinking that “C:\Program Files\JPSoft\TCMD15\tcc.exe” is an argument to "C:\scripts\minstart.exe”, so that /c and “C:\scripts\Copy of Copy of sync script.btm", being arguments to “C:\Program Files\JPSoft\TCMD15\tcc.exe”, are arguments to the argument to "C:\scripts\minstart.exe”.

Tom

 

[vefatica]

That's right, EXIT at the end of the BTMfile will work as well as "/c" on TCC's command line.
Yes, HIDESTART should mean no initial console.
Both MINSTART and HIDESTART read their command line up to the first whitespace-delimited token after the program name (MINSTART or HIDESTART) and pass the entire remainder of the command line (untouched) to the Windows CreateProcess() function. So, while technically, "...TCC.EXE", "/c", and "thebtmfile" are distinct arguments to MINSTART it doesn't treat them as such. So, in your example, the CreateProcess() function should get the command line

“C:\Program Files\JPSoft\TCMD15\tcc.exe” /c “C:\scripts\Copy of Copy of sync script.btm"

which seems valid.
I don't know why Windows would change "/c" to "\c"; I have never seen it.
Can you run the task as the "SYSTEM" user? That way, you just won't see it, period! (at least on Win7).

 

[Fr3M#Ket]

Success!

The reversion of /c to \c had something to do with the quote marks. I wonder why, or course.

Having changed the name of the BTM file merely to shorten it, I have found that the following in the run box now works, success being the result of removal of the quote marks around the first 2 chunks, in which there are no spaces:

C:\scripts\minstart.exe C:\Program Files\JPSoft\TCMD15\tcc.exe /c "C:\scripts\Sync script.btm"
​

Hooray! And thanks for all your help.

It starts tcc minimised, rather than opening a tcc box which then closes. I presume that the overall strategy is for minstart.exe somehow to tell tcc.exe before it starts not to open a box when it starts, if that is possible.

The scheduled task is set to start in c:\scripts, where minstart.exe and Sync script.btm reside, though tcc.exe is of course elsewhere. What is the significance of where a program starts? Do not the file paths tell the OS where to go?

How does one write such a program as minstart, which I take it you then converted to an exe file using the windows utility therefor (iexpress.exe?)? I suppose you have to know how windows Works and then learn some language with a name like C+ or vbs.

Anyhow, thanks again.

Tom

 

[vefatica]

I presume that the overall strategy is for minstart.exe somehow to tell tcc.exe before it starts not to open a box when it starts, if that is possible.

There's no cooperation from TCC.EXE. TCC doesn't open its own console window (box). Windows does that automatically because TCC.EXE has a flag in it telling windows that it is a console-based program. MINSTART just asks Windows to create a process with the command line you specified and says that the initial state should be minimized.

How does one write such a program as minstart, which I take it you then converted to an exe file using the windows utility therefor (iexpress.exe?)? I suppose you have to know how windows Works and then learn some language with a name like C+ or vbs.

Somewhat simplified ... You need a language ... like C/C++, VB, C# for which Microsoft has provided an API (Application Programming Interface, a collection of functions and structures that extend the language to do OS-specific things). And you need software that will turn your human-readable instructions (*.C, *.CPP, ...) into machine-readable instructions (*.EXE, *.DLL, ...). Microsoft's "Visual Studio" is one example of such software. Rex uses it to build TCC and TCMD. I use it.

 

[Fr3M#Ket]

Thanks Vince.

I fear it may be a while before I graduate to writing my own C or vb scripts. I wonder where I could find course, perhaps an online course, that would get me going with the basics of such and the the context in which one is operating.

What are you referring to when you say: "the command line you specified"? Is that: C:\Program Files\JPSoft\TCMD15\tcc.exe /c "C:\scripts\Sync script.btm"?

What is the meaning of the directory that a program "starts in"?

I am enjoying my minimised runs of sync.exe. Did the basic concept of flushing the drives seem sensible? I have not suffered a mysterious data loss since I started this a couple of months ago. But it seems odd that it would not be included in Windows if needed to prevent data loss.

Tom

 

[vefatica]

I'm sure most colleges and universities offer elementary programming courses (in some language) and no doubt you could find something online. C, for example, is pretty compact though the learning curve is initially steep. On the other hand, the Windows API is vast. If you know a supported language, using the Windows API, is easy but learning what's in the API will never end. For getting complicated things done without building an EXE, VBScript is very powerful. It's a scripting language (as is the batch scripting language) that has access to much in the Windows API. Having worked in C for 25 years, VBScript and VB are foreign to me. But many seem to take to it quickly. And you don't need anything special; the ability to run VB script (or something like it) in built into Windows.

Yes. By "command you specified" I meant the tail of the MINSTART command line ... what you want MINSTART to run.

Every running program has a "current directory", where files are looked for and put by default (in a sense, "where I am right now"). In TCC, it's what you see if you give the DIR command (with no arguments). If you said

some_command > file.txt

TCC would look for (or create) file.txt in its current directory. See/change the current directory with the CD and CDD commands. Display the current directory in your prompt with "$p" (and a variety of other ways). Depending on how you start TCC (or any program) you may have the opportunity to specify the current directory it gets when it's started. In the absence of any specification, a program inherits the current directory of the program that started it.

I don't know what SYNC.EXE does. Flushing things seems sensible. But I have never found it necessary. Windows doesn't seem to have a "data loss" problem.

 

[Fr3M#Ket]

Thanks again Vince.

It looks like a "scripting" course could be the way to go. I suppose that the basics of more than one language would enable one to select the language that would best lend itself to the task in hand according to its available commands.

Perhaps the automatic flushing by Windows was not taking place in the usual way for the application where I noticed the data loss, although I should have thought that the flushing would be independent of the application, after data had been saved in the application. I found sync.exe at Sysinternals

Tom