Re: Opening Dual WIndows in Batch FIle

Tech-Archive recommends: Fix windows errors by optimizing your registry


"Al Dunbar" <alandrub@xxxxxxxxxxx> wrote in message
news:eJVQGLlMKHA.4004@xxxxxxxxxxxxxxxxxxxxxxx

"billious" <billious_1954@xxxxxxxxxxx> wrote in message
news:4aa8c316$0$27605$5a62ac22@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
dbareis wrote:
On Sep 10, 8:56 am, "Al Dunbar" <aland...@xxxxxxxxxxx> 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
[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...!

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:

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..






.

Relevant Pages

  • Re: Wait for background processes to complete
    ... To be able to execute commands in the background and wait for their ... The documentation I am referring to is http://perldoc.perl.org/. ... You can run a command in the background with: ... There is a general problem with perl documentation: ...
    (comp.lang.perl.misc)
  • Re: Opening Dual WIndows in Batch FIle
    ... 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. ... 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. ... 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 parameterof the remainder of the line after the separator following the opening quote of the second argument MINUS the final quote on the line. ...
    (microsoft.public.win2000.cmdprompt.admin)
  • Re: Wait for background processes to complete
    ... To be able to execute commands in the background and wait for their ... The documentation I am referring to is http://perldoc.perl.org/. ... You can run a command in the background with: ... There is no further reference to a "double fork" (except in the ...
    (comp.lang.perl.misc)
  • Re: Opening Dual WIndows in Batch FIle
    ... command doesn't start with a double quote. ... I'd suggest it's very optimistic to rely on the documentation, ... 3b If the second argument IS quoted then an attempt will be made to execute ...
    (microsoft.public.win2000.cmdprompt.admin)
  • "which" and "type" (was: Ubuntu installation questions)
    ... internal command to the bash shell. ... printf is a shell builtin ... If I execute ... quote is a function ...
    (comp.os.linux.setup)