Opening Dual WIndows in Batch FIle

[G_dot]

I have a cmd script that searches 2 log files and then writes the
output to disk.
How do I launch 2 notepad sessions, one for each file within the
script.
Is this possible with the Windows cmd shell?

The only viewer I know of is Notepad, if anyone knows of a better
simple windows viewer please let me know.

Thanks,

-------------------------------------------------------------------------------------------------------
cls
Rem Application Name
set name=Epo Application Log Parser %date% Client to ePO Server
Rem Author
Author Gregg Dotoli
Rem Created
set When="August 25,2009"
rem set logname
set alog=server.log
rem set path on Server to log
set logpath=Crogra~1\mcafee\epolic~1\db\logs\
Title %name% Running at %time% on %date% Searchin %alog%
color 17
findstr "%1" %logpath%%alog% > %alog%_%1.txt & notepad %alog%_%1.txt
rem set logname
set dblog=orion.log
rem set path on Server to log
set logpath=Crogra~1\mcafee\epolic~1\server\logs\
Title %name% Running at %time% on %date% Searching %dblog%
color 71
findstr %1 %logpath%%dblog% > %dblog%_%1.txt & notepad %dblog%_%1.txt

Gregg Dotoli

 

[dbareis]

Hi,

I have a cmd script that searches 2 log files and then writes the
output to disk.
How do I launch 2 notepad sessions, one for each file within the
script.
Is this possible with the Windows cmd shell?

Try:

start notepad "1.txt"

Bye,
Dennis

 

[foxidrive]

Try:

start notepad "1.txt"

Close, but no banana Dennis.

start "" notepad "1.txt"
start "" notepad "2.txt"


The leading quotes ensure that other quotes are not taken as a window
title. See

START /?

 

[Guest]

There's really no need for start at all. Cmd starts GUI programs like
notepad and continues.

 

[billious]

There's really no need for start at all. Cmd starts GUI programs like
notepad and continues.

Not the case.

....
notepad 1.txt
....

will wait for notepad to be exited before continuing to the next batch
command. This applies to ALL programs, GUI or otherwise. If it didn't, a
batch program would invoke ALL of the programs it contains in parallel.

As for display options other than notepad - how about EDIT (or edit /r
filename for read-only) or Vern deBuerg's LIST?

(Or wordpad or EditPlus...)

 

[Guest]

I tested via brackets

C:\Users\user>(notepad
More? notepad
More?
More? )

C:\Users\user>

I didn't realise brackets and batch were different outside of the For
command

 

[dbareis]

Close, but no banana Dennis.

start "" notepad "1.txt"
start "" notepad "2.txt"

The leading quotes ensure that other quotes are not taken as a window
title.  See

START /?

Which says:

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /
BELOWNORMAL]
[/WAIT] [/B] [command/program]
[parameters]

Which both your and my commands follow so I am unsure what is the
point
(as you can see title is optional)...

Bye,
Dennis

 

[billious]

Close, but no banana Dennis.

start "" notepad "1.txt"
start "" notepad "2.txt"

The leading quotes ensure that other quotes are not taken as a window
title. See

START /?

Which says:

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /
BELOWNORMAL]
[/WAIT] [/B] [command/program]
[parameters]

Which both your and my commands follow so I am unsure what is the
point
(as you can see title is optional)...

Bye,
Dennis


----------------------

Heh - such innocent faith in Uncle Bill's two-bit software company.

Problem is that when you invoke an executable which contains a space, you
need to enclose the executable name in double-quotes.

So take

START "string1" "string2" "string3"

Now - is string1 a title and you want to invoke string2 with a parameter of
string3, or are you taking the title-less option, and you want to execute
string1 with parameters of string2 and string3?

Easy way to overcome this syntax ambiguity is to ALWAYS supply a title, but
make the title a null-string if you want an untitled window.

 

[foxidrive]

Close, but no banana Dennis.

start "" notepad "1.txt"
start "" notepad "2.txt"

The leading quotes ensure that other quotes are not taken as a window
title.  See

START /?

Which says:

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /
BELOWNORMAL]
[/WAIT] [/B] [command/program]
[parameters]

Which both your and my commands follow so I am unsure what is the
point (as you can see title is optional)...

Try it mate. You seem unable to learn it from friendly discussions.

 

[gdotoli]

Dual WIndows in Batch FIle

I need to spawn the windows in parallel, not sequentially.

How do I launch both windows at once?


Thanks,

Gregg Dotoli

 

[Timo Salmi]

How do I launch 2 notepad sessions, one for each file within the
script.

109} How do I open e.g. three separate instances of notepad at one go?
http://www.netikka.net/tsneti/info/tscmd109.htm


All the best, Timo

 

[01MDM]

C:\> for %i in (1.log 2.log) do start "" notepad "%i"

 

[Al Dunbar]

Close, but no banana Dennis.

start "" notepad "1.txt"
start "" notepad "2.txt"

The leading quotes ensure that other quotes are not taken as a window
title. See

START /?

Which says:

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /
BELOWNORMAL]
[/WAIT] [/B] [command/program]
[parameters]

Which both your and my commands follow so I am unsure what is the
point
(as you can see title is optional)...

Bye,
Dennis


----------------------

Heh - such innocent faith in Uncle Bill's two-bit software company.

Problem is that when you invoke an executable which contains a space, you
need to enclose the executable name in double-quotes.

So take

START "string1" "string2" "string3"

Now - is string1 a title and you want to invoke string2 with a parameter
of string3, or are you taking the title-less option, and you want to
execute string1 with parameters of string2 and string3?

Easy way to overcome this syntax ambiguity is to ALWAYS supply a title,
but make the title a null-string if you want an untitled window.

.... or for applications that do not use the title supplied by the START
command.

Dennis is right, though, in deducing from the help text that the title is
"optional". It is just that it is only optional when it is not required.

/Al

 

[dbareis]

Which says:

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
     [/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /
BELOWNORMAL]
     [/WAIT] [/B] [command/program]
     [parameters]

Which both your and my commands follow so I am unsure what is the
point
(as you can see title is optional)...


Heh - such innocent faith in Uncle Bill's two-bit software company.

Problem is that when you invoke an executable which contains a space, you
need to enclose the executable name in double-quotes.

So take

START "string1" "string2" "string3"

Now - is string1 a title and you want to invoke string2 with a parameter
of string3, or are you taking the title-less option, and you want to
execute string1 with parameters of string2 and string3?

Easy way to overcome this syntax ambiguity is to ALWAYS supply a title,
but make the title a null-string if you want an untitled window.

... or for applications that do not use the title supplied by the START
command.

Dennis is right, though, in deducing from the help text that the title is
"optional". It is just that it is only optional when it is not required.

/Al- Hide quoted text -

- Show quoted text -

Thanks for that, and it wasn't required (for my example commands) as
the
command doesn't start with a double quote.

Bye,
Dennis

 

[foxidrive]

Thanks for that, and it wasn't required (for my example commands) as the
command doesn't start with a double quote.

Hmmm...?

Try:

start notepad "1.txt"

That little thing immediately before the 1 is a double quote/

 

[billious]

On Sep 10, 8:56 am, "Al Dunbar" <[email protected]> wrote:

[snip - START command documented syntax]

Thanks for that, and it wasn't required (for my example commands) as
the
command doesn't start with a double quote.

Bye,
Dennis

I'd suggest it's very optimistic to rely on the documentation, given the
originator's expression skills. Despite the availability of
spelling-checkers and syntax-analysers, the documentation contains such
blunders as "hexidecimal" and displays a confusion about the use of singlar
and plural. Evidently, it was not deemed appropriate to use these tools - or
perhaps it displays a worrying level of confidence in them.

The same person also appear to believe that such constructs as '+=' are so
self-evident that they require no explanation, that there is no need to
allow a universal-format response for date (like CCYYMMDDHHMMSS for
instance) and that whereas 0x is implemented to explicitly specify hex in
SET, there is no need to allow 0d for decimal and 0o for octal. It appears
that this person's view of the world is that Octal is so much more important
than decimal that a leading zero is interpreted as octal, and the consequent
pitfalls can be disclaimed by a note in the documentation. No need to
document that a leading semicolon will cause FOR /F to disregard a line, of
course. That's just so obvious and unimportant it doesn't require as much as
a note.

I've tried to analyse the syntax for the START command, and I'll admit that
I've only tried unquoted and quoted strings - no unbalanced-quotes, embedded
quotes or alternative separators like semicolons or tabs. What I conclude is
this:

1. If there is a single argument, that argument will be executed, whether or
not it is quoted.
2. If the first argument is NOT quoted, then that first argument will be
executed with parameters of the remaining arguments
3. If the first argument IS quoted, then that will be used as the TITLE.
3a If the second argument is NOT quoted, then the second argument will be
executed with parameters of the remaining arguments
3b If the second argument IS quoted then an attempt will be made to execute
that part of the command-line AFTER the opening quote of the second argument
UP TO the final quote on the line, with parameter(s) of the remainder of the
line after the separator following the opening quote of the second argument
MINUS the final quote on the line.

This should all be clear, I hope - with the exception of 3b, which I'll
exemplify:

START "s tring1" "s tring2" "s tring3" "s tring4" parm5

Where there is a deliberate space between "s" and "tring"

will select (parameters delimited by [] for clarity)
[s tring1] as TITLE
as executable
[tring2"] as executable's first parameter
["s tring3"] as executable's second parameter
["s tring4] as executable's third parameter
[parm5] as executable's fourth parameter

Note that the actual executable is that part before the space-separator; the
first parameter delivered has an unbalanced quote and the third parameter is
missing the closing quote.

Observe the response should the target executable ( in this case) not
exist - the executable reported as not existing is that command-line portion
up to the final quote, not simply to the first separator following the
opening quote on the second argument...!

There's probably a better way to express this observation. What is certain
is that the description of the title as being optional is hard to justify.

 

[Al Dunbar]

Hmmm...?




That little thing immediately before the 1 is a double quote/

Yes, but, as Dennis states, the "command" does not start with a double
quote. The "command" in this example would be [notepad "1.txt"]. On my
system, this command:

start notepad "1.txt"

works perfectly well. The (optional) (and quoted) title parameter is really
only required when the command to be started begins with the name of an
executable that is quoted. If notepad were not on the path and located in a
folder whose path contained a blank character, then the title parameter
would be required, i.e.:

start "" "C:\a test\notepad.exe" 1.txt

All that said, I do agree that it is good practice to always include the
title parameter. I am sure if we check the archives of this newsgroup we
will find a number of cases where people have had problems when their start
commands suddenly required a quoted executable name, and the result was not
what they expected.

/Al

 

[Al Dunbar]

On Sep 10, 8:56 am, "Al Dunbar" <[email protected]> wrote:

[snip - START command documented syntax]

Thanks for that, and it wasn't required (for my example commands) as
the
command doesn't start with a double quote.

Bye,
Dennis

I'd suggest it's very optimistic to rely on the documentation, given the
originator's expression skills. Despite the availability of
spelling-checkers and syntax-analysers, the documentation contains such
blunders as "hexidecimal" and displays a confusion about the use of
singlar and plural. Evidently, it was not deemed appropriate to use these
tools - or perhaps it displays a worrying level of confidence in them.

The same person also appear to believe that such constructs as '+=' are so
self-evident that they require no explanation, that there is no need to
allow a universal-format response for date (like CCYYMMDDHHMMSS for
instance) and that whereas 0x is implemented to explicitly specify hex in
SET, there is no need to allow 0d for decimal and 0o for octal. It appears
that this person's view of the world is that Octal is so much more
important than decimal that a leading zero is interpreted as octal, and
the consequent pitfalls can be disclaimed by a note in the documentation.
No need to document that a leading semicolon will cause FOR /F to
disregard a line, of course. That's just so obvious and unimportant it
doesn't require as much as a note.

I've tried to analyse the syntax for the START command, and I'll admit
that I've only tried unquoted and quoted strings - no unbalanced-quotes,
embedded quotes or alternative separators like semicolons or tabs. What I
conclude is this:

1. If there is a single argument, that argument will be executed, whether
or not it is quoted.
2. If the first argument is NOT quoted, then that first argument will be
executed with parameters of the remaining arguments
3. If the first argument IS quoted, then that will be used as the TITLE.
3a If the second argument is NOT quoted, then the second argument will be
executed with parameters of the remaining arguments
3b If the second argument IS quoted then an attempt will be made to
execute that part of the command-line AFTER the opening quote of the
second argument UP TO the final quote on the line, with parameter(s) of
the remainder of the line after the separator following the opening quote
of the second argument MINUS the final quote on the line.

This should all be clear, I hope - with the exception of 3b, which I'll
exemplify:

START "s tring1" "s tring2" "s tring3" "s tring4" parm5

Where there is a deliberate space between "s" and "tring"

will select (parameters delimited by [] for clarity)
[s tring1] as TITLE
as executable
[tring2"] as executable's first parameter
["s tring3"] as executable's second parameter
["s tring4] as executable's third parameter
[parm5] as executable's fourth parameter

Note that the actual executable is that part before the space-separator;
the first parameter delivered has an unbalanced quote and the third
parameter is missing the closing quote.

Observe the response should the target executable ( in this case) not
exist - the executable reported as not existing is that command-line
portion up to the final quote, not simply to the first separator following
the opening quote on the second argument...!

Nice work, providing the above blow-by-blow description of how start parses
its parameters. No matter how succinctly this can be summarized, it is a
good illustration that always including a title parameter simplifies the
calculations one might have to go through to determine if it is required.
And we haven't even considered the possibility of using a non-literal string
as the executable to be started, i.e.:

set exe="C:\a b\c.exe"
start %exe% 1.txt

There's probably a better way to express this observation. What is certain
is that the description of the title as being optional is hard to justify.

Well, it *is* optional in that it is not always required. Where the docs
fail is in not explaining the why's and the wherefore's of this, leaving it
up to this newsgroup to explain.

Also, I suspect that the help file info was written after the command was
developed, and by people other than the development team. We can argue that
the help text is inaccurate, or we could lay more of the blame on the
command itself. Unfortunately, neither case will cause either of the
blameworthy parts to be fixed.

/Al

 

[foxidrive]

That little thing immediately before the 1 is a double quote/

Yes, but, as Dennis states, the "command" does not start with a double
quote. The "command" in this example would be [notepad "1.txt"]. On my
system, this command:

start notepad "1.txt"

works perfectly well.

Yes, it does too here. Sorry Dennis.

The (optional) (and quoted) title parameter is really
only required when the command to be started begins with the name of an
executable that is quoted.

That's another 'gotcha' to remember. As you say Al, it's best to always
include the "" just because it's simple to remember.

 

[billious]

On Sep 10, 8:56 am, "Al Dunbar" <[email protected]> wrote:

[snip - START command documented syntax]

Dennis is right, though, in deducing from the help text that the
title is "optional". It is just that it is only optional when it is
not required.

/Al- Hide quoted text -

- Show quoted text -

Thanks for that, and it wasn't required (for my example commands) as
the
command doesn't start with a double quote.

Bye,
Dennis

I'd suggest it's very optimistic to rely on the documentation, given the
originator's expression skills. Despite the availability of
spelling-checkers and syntax-analysers, the documentation contains such
blunders as "hexidecimal" and displays a confusion about the use of
singlar and plural. Evidently, it was not deemed appropriate to use these
tools - or perhaps it displays a worrying level of confidence in them.

The same person also appear to believe that such constructs as '+=' are
so self-evident that they require no explanation, that there is no need
to allow a universal-format response for date (like CCYYMMDDHHMMSS for
instance) and that whereas 0x is implemented to explicitly specify hex in
SET, there is no need to allow 0d for decimal and 0o for octal. It
appears that this person's view of the world is that Octal is so much
more important than decimal that a leading zero is interpreted as octal,
and the consequent pitfalls can be disclaimed by a note in the
documentation. No need to document that a leading semicolon will cause
FOR /F to disregard a line, of course. That's just so obvious and
unimportant it doesn't require as much as a note.

I've tried to analyse the syntax for the START command, and I'll admit
that I've only tried unquoted and quoted strings - no unbalanced-quotes,
embedded quotes or alternative separators like semicolons or tabs. What I
conclude is this:

1. If there is a single argument, that argument will be executed, whether
or not it is quoted.
2. If the first argument is NOT quoted, then that first argument will be
executed with parameters of the remaining arguments
3. If the first argument IS quoted, then that will be used as the TITLE.
3a If the second argument is NOT quoted, then the second argument will be
executed with parameters of the remaining arguments
3b If the second argument IS quoted then an attempt will be made to
execute that part of the command-line AFTER the opening quote of the
second argument UP TO the final quote on the line, with parameter(s) of
the remainder of the line after the separator following the opening quote
of the second argument MINUS the final quote on the line.

This should all be clear, I hope - with the exception of 3b, which I'll
exemplify:

START "s tring1" "s tring2" "s tring3" "s tring4" parm5

Where there is a deliberate space between "s" and "tring"

will select (parameters delimited by [] for clarity)
[s tring1] as TITLE
as executable
[tring2"] as executable's first parameter
["s tring3"] as executable's second parameter
["s tring4] as executable's third parameter
[parm5] as executable's fourth parameter

Note that the actual executable is that part before the space-separator;
the first parameter delivered has an unbalanced quote and the third
parameter is missing the closing quote.

Observe the response should the target executable ( in this case) not
exist - the executable reported as not existing is that command-line
portion up to the final quote, not simply to the first separator
following the opening quote on the second argument...!

Nice work, providing the above blow-by-blow description of how start
parses its parameters. No matter how succinctly this can be summarized, it
is a good illustration that always including a title parameter simplifies
the calculations one might have to go through to determine if it is
required. And we haven't even considered the possibility of using a
non-literal string as the executable to be started, i.e.:

set exe="C:\a b\c.exe"
start %exe% 1.txt

There's probably a better way to express this observation. What is
certain is that the description of the title as being optional is hard to
justify.

Well, it *is* optional in that it is not always required. Where the docs
fail is in not explaining the why's and the wherefore's of this, leaving
it up to this newsgroup to explain.

Also, I suspect that the help file info was written after the command was
developed, and by people other than the development team. We can argue
that the help text is inaccurate, or we could lay more of the blame on the
command itself. Unfortunately, neither case will cause either of the
blameworthy parts to be fixed.

/Al

....

set exe="C:\a b\c.exe"
start %exe% 1.txt

Oh dear, you don't really believe I didn't automate the testing?

Here's one of the batches I used:


This solution developed using XP

----- batch begins -------
[1]@echo off
[2]del bres.txt 2>nul
[3]for %%a in (bres1.bat "b res1.bat") do (
[4]for %%b in (bres2.bat "b res2.bat") do (
[5]for %%c in (bres3.bat "b res3.bat") do (
[6]for %%d in (bres4.bat "b res4.bat") do (
[7]>>bres.txt echo\%%a %%b %%c %%d
[8]start /wait %%a %%b %%c %%d
[9]>>bres.txt echo\-------------
[10])
[11])
[12])
[13])
------ batch ends --------

Lines start [number] - any lines not starting [number] have been wrapped and
should be rejoined. The [number] that starts the line should be removed

Where the batch files 'bres?.bat', 'b res?.bat' and b.bat all have the
active contents:

(this was one of a short series of batches - one of the others had lines
like
for %%a in (bres1.bat "bres1.bat") do (
for instance)

I did it this way to be sure of trying all combinations.

I would have expected the programmer to have consistently interpreted
parameters as tokens separated by er, separators - each string being a
token, and where a token is required to contain a separator, then the string
needs to be quoted. It seems from the way that START is implemented that
this philosophy was NOT followed. Why change horses in midstream?

The failure to implement 0D/0o or date/u is clearly a developer's decision.
It would seem that these decisions were made without adequate consideration
of the consequences.

I can't see that it's relevant whether the documentation was an afterthought
performed by a different section or whether it was done by the developers.
Whoever did it didn't use the verification tools available, or disregarded
the results. I've been astonished by encountering so programmers who seem
to have difficulty in this area. After all, their profession requires strict
adherence to syntax and spelling - they even seem to revel in
StupidLongMixedCaseVariableNames.

What now appears to be the case is that quoted parameters to START are
processed in an irregular manner, which wouldn't have been evident had the
discussion been restricted the the original particular example..