Opening Dual WIndows in Batch FIle
G_dot
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=C:progra~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=C:progra~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
On Aug 27, 1:10 pm, G_dot <gdot...@gmail.com> wrote:
> 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
wrote:
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 /?
.
notepad and continues.
--
.
--
"foxidrive" <got...@woohoo.invalid> wrote in message
news:fg5c959kdeiahjus6...@4ax.com...
billious
<.> wrote in message news:uug1JctJ...@TK2MSFTNGP04.phx.gbl...
> "foxidrive" <got...@woohoo.invalid> wrote in message
> news:fg5c959kdeiahjus6...@4ax.com...
>> On Wed, 26 Aug 2009 20:48:44 -0700 (PDT), dbareis <dba...@gmail.com>
>> wrote:
>>
>>>On Aug 27, 1:10 pm, G_dot <gdot...@gmail.com> wrote:
>>>> 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"
>>
>> 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 /?
>>
> 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...)
.
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
--
.
--
"billious" <billio...@hotmail.com> wrote in message
news:4a961c82$0$28360$5a62...@per-qv1-newsreader-01.iinet.net.au...
dbareis
> On Wed, 26 Aug 2009 20:48:44 -0700 (PDT), dbareis <dbar...@gmail.com>
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
"dbareis" <dba...@gmail.com> wrote in message
news:d163f282-fe08-4ff0...@d9g2000prh.googlegroups.com...
Which says:
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
wrote:
>> >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 /?
>
>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.
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
--
Prof. Timo Salmi mailto:t...@uwasa.fi ftp & http://garbo.uwasa.fi/
Hpage: http://www.uwasa.fi/laskentatoimi/english/personnel/salmitimo/
Department of Accounting and Finance, University of Vaasa, Finland
Useful CMD script tricks http://www.netikka.net/tsneti/info/tscmd.htm
01MDM
Al Dunbar
... 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
> "billious" <billious_1...@hotmail.com> wrote in message
>
> news:4a963ba2$0$28406$5a62...@per-qv1-newsreader-01.iinet.net.au...
>
>
>
>
>
>
>
> > "dbareis" <dbar...@gmail.com> wrote in message
>
> - 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...?
On Wed, 26 Aug 2009 20:48:44 -0700 (PDT), dbareis <dba...@gmail.com>
wrote:
>
>Try:
>
> start notepad "1.txt"
That little thing immediately before the 1 is a double quote/
billious
>>
>> 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
[s] 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 ([s] 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
"foxidrive" <got...@woohoo.invalid> wrote in message
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
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
wrote:
>> On Wed, 26 Aug 2009 20:48:44 -0700 (PDT), dbareis <dba...@gmail.com>
>> wrote:
>>>
>>>Try:
>>>
>>> start notepad "1.txt"
>>
>> 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
"Al Dunbar" <alan...@hotmail.com> wrote in message
news:eJVQGLlM...@TK2MSFTNGP04.phx.gbl...
...
> 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:
>>bres.txt echo running %0 with arguments %1+%2+%3+%4+%5
(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..
Al Dunbar
>
> "Al Dunbar" <alan...@hotmail.com> wrote in message
> news:eJVQGLlM...@TK2MSFTNGP04.phx.gbl...
>>
>> "billious" <billio...@hotmail.com> wrote in message
>> news:4aa8c316$0$27605$5a62...@per-qv1-newsreader-01.iinet.net.au...
>>> dbareis wrote:
>>>> On Sep 10, 8:56 am, "Al Dunbar" <aland...@hotmail.com> 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 -
<snip>
>> 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:
<snip>
> 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.
Granted.
> Why change horses in midstream?
Indeed. So, we are on this horse now...
> 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.
IMHO, when batch commands were first developed, I strongly suspect that they
had very little idea of the extent to which users would run into problems
because of our innate tendency to assume that they were developing a
consistent and sophisticated programming language rather than slightly
extending an interactive command processor. ;-)
> 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.
That was just my observation, not an actual argument. In fact, if we cannot
tell which might be the case then it doesn't really matter how we wound up
with what we have to deal with.
> Whoever did it didn't use the verification tools available, or disregarded
> the results.
I suspect that, whatever verification processes may have been used simply
demonstrated that the code worked the way they expected it to. It does seem,
however, that they were not sticklers for consistency and simplicity in how
the command processes its arguments.
> 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.
We all have our style preferences, however, I don't see where it is clear
that the developers of the START command are of the SLMCVN ilk.
> 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..
So then, it's a good thing that we followed off on this tangent?
/Al
billious
>
>> 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.
>
> We all have our style preferences, however, I don't see where it is clear
> that the developers of the START command are of the SLMCVN ilk.
>
Programmers in general (not restricted to whoever is resonsible for "START")
seem to have poor spelling abilities, appearing even to take some perverse
pride in their self-proclaimed disability. I find this curious when their
working environment mandates strict adherence to spelling and syntax. What
drives them to exacerbate the torture by using SLMCVNs and case-sensitive
languages like Java?
On the other hand, order-clerks want to describe themselves as "IT
Personnel" nowadays, based on the fact that they use a data-entry system
rather than pen and ink. Same notion goes for vets and dentists - even
chiropractors - who call themselves "doctor."
Al Dunbar
>
> "Al Dunbar" <alan...@hotmail.com> wrote in message
> news:%23V89c0N...@TK2MSFTNGP02.phx.gbl...
>>
>>> 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.
>>
>> We all have our style preferences, however, I don't see where it is clear
>> that the developers of the START command are of the SLMCVN ilk.
>>
>
> Programmers in general (not restricted to whoever is resonsible for
> "START") seem to have poor spelling abilities, appearing even to take some
> perverse pride in their self-proclaimed disability.
While I have no doubt this characterization is accurate for *some*
programmers, it is not clear how you deduce it to be universally true, or
even just true "in general".
> I find this curious when their working environment mandates strict
> adherence to spelling and syntax.
I don't find it curious (for those cases that match your description), and
for much the same reason that I do not find it curious that you continue to
beat this particular drum...
> What drives them to exacerbate the torture by using SLMCVNs and
> case-sensitive languages like Java?
Ask one of them.
> On the other hand, order-clerks want to describe themselves as "IT
> Personnel" nowadays, based on the fact that they use a data-entry system
> rather than pen and ink. Same notion goes for vets and dentists - even
> chiropractors - who call themselves "doctor."
Are there perhaps other groups you would like to slag here?
/Al
.
--
.
--
"Al Dunbar" <alan...@hotmail.com> wrote in message
news:uAA3mgbN...@TK2MSFTNGP04.phx.gbl...
Al Dunbar
/Al
<.> wrote in message news:uA9gwkbN...@TK2MSFTNGP05.phx.gbl...