info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Safe Echoing Revisited
5,262 views
Skip to first unread message
Andy
Mar 8, 2013, 2:56:39 PM3/8/13
to
On Tuesday, July 30, 2002 3:06:51 PM UTC-6, Ritchie Lawrence wrote:
> ----------------------------------------------------------------------------
> Background
>
> For the benefit of those not familiar with safe ECHOing, here's a brief
> overview of ECHOs 'hidden dangers'. Take a look at the basic statement
> below:-
>
> ECHO %VAR%
>
> This doesn't behave as expected when VAR is set to /?, ON, OFF or when VAR
> is undefined. The usual workaround is to append a period immediately after
> the ECHO command, like this:-
>
> ECHO.%VAR%
>
> However, this introduces a new problem. If VAR is undefined and the current
> working directory contains a file named 'echo', the following error is
> displayed (although the script continues to execute):-
>
> 'echo.' is not recognized as an internal or external command,
> operable program or batch file.
>
> Back in May of this year in a thread titled 'ECHOing blank lines - what
> happened?' (See Ref#1), with the help of Simon and Frank, I concluded the
> safest way to echo, was to append a colon immediately after the echo
> command.
>
> This is something I've been doing ever since (well... when I remember to)
> and in doing so, all the problems mentioned above are avoided. I've
> since noticed another reason to use the colon, that being to dramatically
> reduce the execution times of scripts containing a 'CALL ECHO' statement.
>
> ----------------------------------------------------------------------------
> Minimizing the Execution Time of CALL ECHO
>
> I've known for some time that the CALL ECHO statement observably impacts
> script performance, but just assumed that was due to pushing stuff onto the
> stack and expanding variables etc. That was until the other day.
>
> I was writing a solution that used a CALL ECHO statement and during the
> testing noticed that I'd missed out 'the colon'. After adding it, the script
> ran as though the CALL wasn't present. Some experimentation was called
> for...
>
> ----------------------------------------------------------------------------
> Method
>
> The first test was to compare the effect of various characters placed after
> ECHO without a CALL, the second with a call. Here are the two scripts:-
>
> ================ script 1 ==============
> @echo off
> for /l %%a in (1,1,500) do echoX%%a
>
> ================ script 2 ==============
> @echo off
> for /l %%a in (1,1,500) do call echoX%%a
>
> Script 2 is obviously somewhat contrived, however it has the same effect as
> a script that genuinely requires a CALL ECHO statement. The scripts were
> edited and the X was substituted for various characters. TIMETHIS from the
> resource kit was used to obtain execution times. No results were recorded
> until the console buffer had been filled. The operating system was Windows
> 2000 (SP2).
>
> ----------------------------------------------------------------------------
> Results
>
> Script 1
> +--------------------------------+---------+
> | Characters Tested |Time (ms)|
> +--------------------------------+---------+
> | <space> + [ ] / ; | 380 |
> +--------------------------------+---------+
> | . : \ | 450 |
> +--------------------------------+---------+
>
> Script 2
> +--------------------------------+---------+-------------------------------+
> | Characters Tested |Time (ms)| Time (ms) with PATH undefined |
> +--------------------------------+---------+-------------------------------+
> | / | 600 | 600 |
> +--------------------------------+---------+-------------------------------+
> | : \ | 630 | 630 |
> +--------------------------------+---------+-------------------------------+
> | <space> ; | 991 | 891 |
> +--------------------------------+---------+-------------------------------+
> | + [ ] | 4636 | 771 |
> +--------------------------------+---------+-------------------------------+
> | . | 7330 | 921 |
> +--------------------------------+---------+-------------------------------+
>
> As you can see the period has the worst times, it also causes problems when
> a file named 'echo' exists in the current directory. It seems the CALL
> command is iterating the PATH variable. To verify, script 2 tests were re-
> run, this time with the PATH variable undefined. The execution times for the
> colon, backslash and forward slash remained unchanged, whilst the time for
> the period was reduced dramatically.
>
> ----------------------------------------------------------------------------
> Conclusion
>
> It's interesting that the colon and slashes stop CMD iterating the PATH.
> These are all illegal filename characters so I guess CMD just doesn't
> bother.
>
> So, what's the best character to use? Given that your scripts will be more
> reliable if using some kind of character immediately after ECHO, you may as
> well use one that gives the best all-round performance under all conditions
> and doesn't introduce new problems. That definitely rules out the period.
> The forward slash is clearly the best performer, hotly pursued by the colon
> and backslash.
>
> I going to continue with the colon, its what I've been using for the last
> few months. For all the new blood out there, if you want the fastest scripts
> then the forward slash is the way to go.
>
> --
> Ritchie
> set mail=%mail:do=%
>
> ----------------------------------------------------------------------------
> References
>
> #1 'ECHOing blank lines - what happened?'
>
> http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=ea31bcfac07e02af&seekm=3d05d7c3_2%40mk-nntp-1.news.uk.worldonline.c
> om&frame=off
>
> If link is broken, search Google groups for "ECHOing blank lines - what
> happened?" (include the quotes)
Could you condense your conclusions a bit ?
Thanks.
> ----------------------------------------------------------------------------
> Background
>
> For the benefit of those not familiar with safe ECHOing, here's a brief
> overview of ECHOs 'hidden dangers'. Take a look at the basic statement
> below:-
>
> ECHO %VAR%
>
> This doesn't behave as expected when VAR is set to /?, ON, OFF or when VAR
> is undefined. The usual workaround is to append a period immediately after
> the ECHO command, like this:-
>
> ECHO.%VAR%
>
> However, this introduces a new problem. If VAR is undefined and the current
> working directory contains a file named 'echo', the following error is
> displayed (although the script continues to execute):-
>
> 'echo.' is not recognized as an internal or external command,
> operable program or batch file.
>
> Back in May of this year in a thread titled 'ECHOing blank lines - what
> happened?' (See Ref#1), with the help of Simon and Frank, I concluded the
> safest way to echo, was to append a colon immediately after the echo
> command.
>
> This is something I've been doing ever since (well... when I remember to)
> and in doing so, all the problems mentioned above are avoided. I've
> since noticed another reason to use the colon, that being to dramatically
> reduce the execution times of scripts containing a 'CALL ECHO' statement.
>
> ----------------------------------------------------------------------------
> Minimizing the Execution Time of CALL ECHO
>
> I've known for some time that the CALL ECHO statement observably impacts
> script performance, but just assumed that was due to pushing stuff onto the
> stack and expanding variables etc. That was until the other day.
>
> I was writing a solution that used a CALL ECHO statement and during the
> testing noticed that I'd missed out 'the colon'. After adding it, the script
> ran as though the CALL wasn't present. Some experimentation was called
> for...
>
> ----------------------------------------------------------------------------
> Method
>
> The first test was to compare the effect of various characters placed after
> ECHO without a CALL, the second with a call. Here are the two scripts:-
>
> ================ script 1 ==============
> @echo off
> for /l %%a in (1,1,500) do echoX%%a
>
> ================ script 2 ==============
> @echo off
> for /l %%a in (1,1,500) do call echoX%%a
>
> Script 2 is obviously somewhat contrived, however it has the same effect as
> a script that genuinely requires a CALL ECHO statement. The scripts were
> edited and the X was substituted for various characters. TIMETHIS from the
> resource kit was used to obtain execution times. No results were recorded
> until the console buffer had been filled. The operating system was Windows
> 2000 (SP2).
>
> ----------------------------------------------------------------------------
> Results
>
> Script 1
> +--------------------------------+---------+
> | Characters Tested |Time (ms)|
> +--------------------------------+---------+
> | <space> + [ ] / ; | 380 |
> +--------------------------------+---------+
> | . : \ | 450 |
> +--------------------------------+---------+
>
> Script 2
> +--------------------------------+---------+-------------------------------+
> | Characters Tested |Time (ms)| Time (ms) with PATH undefined |
> +--------------------------------+---------+-------------------------------+
> | / | 600 | 600 |
> +--------------------------------+---------+-------------------------------+
> | : \ | 630 | 630 |
> +--------------------------------+---------+-------------------------------+
> | <space> ; | 991 | 891 |
> +--------------------------------+---------+-------------------------------+
> | + [ ] | 4636 | 771 |
> +--------------------------------+---------+-------------------------------+
> | . | 7330 | 921 |
> +--------------------------------+---------+-------------------------------+
>
> As you can see the period has the worst times, it also causes problems when
> a file named 'echo' exists in the current directory. It seems the CALL
> command is iterating the PATH variable. To verify, script 2 tests were re-
> run, this time with the PATH variable undefined. The execution times for the
> colon, backslash and forward slash remained unchanged, whilst the time for
> the period was reduced dramatically.
>
> ----------------------------------------------------------------------------
> Conclusion
>
> It's interesting that the colon and slashes stop CMD iterating the PATH.
> These are all illegal filename characters so I guess CMD just doesn't
> bother.
>
> So, what's the best character to use? Given that your scripts will be more
> reliable if using some kind of character immediately after ECHO, you may as
> well use one that gives the best all-round performance under all conditions
> and doesn't introduce new problems. That definitely rules out the period.
> The forward slash is clearly the best performer, hotly pursued by the colon
> and backslash.
>
> I going to continue with the colon, its what I've been using for the last
> few months. For all the new blood out there, if you want the fastest scripts
> then the forward slash is the way to go.
>
> --
> Ritchie
> set mail=%mail:do=%
>
> ----------------------------------------------------------------------------
> References
>
> #1 'ECHOing blank lines - what happened?'
>
> http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=ea31bcfac07e02af&seekm=3d05d7c3_2%40mk-nntp-1.news.uk.worldonline.c
> om&frame=off
>
> If link is broken, search Google groups for "ECHOing blank lines - what
> happened?" (include the quotes)
Could you condense your conclusions a bit ?
Thanks.
Andy
Mar 9, 2013, 4:28:05 PM3/9/13
to
On Saturday, March 9, 2013 3:22:25 PM UTC-6, Todd Vargo wrote:
> Todd Vargo
con·dense (kn-dns)
v. con·densed, con·dens·ing, con·dens·es
v.tr.
1. To reduce the volume or compass of.
2. To make more concise; abridge or shorten.
3. Physics
a. To cause (a gas or vapor) to change to a liquid.
b. To remove water from (milk, for example).
> On 3/8/2013 2:56 PM, Andy wrote:
>
> > On Tuesday, July 30, 2002 3:06:51 PM UTC-6, Ritchie Lawrence wrote:
> <long post snipped>
>
> > On Tuesday, July 30, 2002 3:06:51 PM UTC-6, Ritchie Lawrence wrote:
>
>
> > Could you condense your conclusions a bit ?
> > Thanks.
>
> Sure, here is a link for you.
>
> > Could you condense your conclusions a bit ?
> > Thanks.
>
> Todd Vargo
con·dense (kn-dns)
v. con·densed, con·dens·ing, con·dens·es
v.tr.
1. To reduce the volume or compass of.
2. To make more concise; abridge or shorten.
3. Physics
a. To cause (a gas or vapor) to change to a liquid.
b. To remove water from (milk, for example).
Liviu
Mar 10, 2013, 1:52:01 AM3/10/13
to
"Todd Vargo" wrote...
>
> Replacing NOISE with louder NOISE only makes the room louder. :(
There is, too, the notion of noise-canceling in certain environments ;-)
But, you are right. Apologies to the innocent bystanders.
Liviu
>
> Replacing NOISE with louder NOISE only makes the room louder. :(
There is, too, the notion of noise-canceling in certain environments ;-)
But, you are right. Apologies to the innocent bystanders.
Liviu
douglas...@gmail.com
Mar 15, 2015, 4:42:44 PM3/15/15
to
On Tuesday, July 30, 2002 at 2:06:51 PM UTC-7, Ritchie Lawrence wrote:
> Script 2 is obviously somewhat contrived, however it has the same effect as
> a script that genuinely requires a CALL ECHO statement.
When would a script require a CALL ECHO statement? What is the benefit over ECHO by itself? Forgive me if the answer should be obvious, but Google only turned up a couple references to doing this, and nothing about why you'd want to.
> Script 2 is obviously somewhat contrived, however it has the same effect as
> a script that genuinely requires a CALL ECHO statement.
Thanks,
Douglas
frank.w...@gmail.com
Mar 15, 2015, 5:50:15 PM3/15/15
to
From douglas.swehla:
variables, before delayed expansion was added.
CALL ECHO %%CD%%
prodeuces
ECHO %CD%
which prints the value.
Frank
>When would a script require a CALL ECHO statement?
It was necessary a lot to provide delayed expansion of
variables, before delayed expansion was added.
CALL ECHO %%CD%%
prodeuces
ECHO %CD%
which prints the value.
Frank
douglas...@gmail.com
Mar 15, 2015, 10:37:01 PM3/15/15
to
On Sunday, March 15, 2015 at 2:50:15 PM UTC-7, frank.w...@gmail.com wrote:
> From douglas.swehla:
> >When would a script require a CALL ECHO statement?
>
> It was necessary a lot to provide delayed expansion of
> variables, before delayed expansion was added.
>
> Frank
> From douglas.swehla:
> >When would a script require a CALL ECHO statement?
>
> It was necessary a lot to provide delayed expansion of
> variables, before delayed expansion was added.
>
Perfect, thanks!
Douglas
Ritchie Lawrence
Jul 30, 2002, 5:00:10 PM7/30/02
to
----------------------------------------------------------------------------
Background
Background
ECHO %VAR%
ECHO.%VAR%
----------------------------------------------------------------------------
Method
Script 2 is obviously somewhat contrived, however it has the same effect as
Frank
Jul 30, 2002, 8:00:31 PM7/30/02
to
Ritchie Lawrence <3d46fed0$0$237$cc9e...@news.dial.pipex.com>...
^ So, what's the best character to use? Given that your scripts will be
more
^ reliable if using some kind of character immediately after ECHO, you may
as
^ well use one that gives the best all-round performance under all
conditions
^ and doesn't introduce new problems. That definitely rules out the
period.
^ The forward slash is clearly the best performer, hotly pursued by the
colon
^ and backslash.
Wow! I spot-checked your results on NT4 with NT4 and NT5 consoles
side-by-side and got similar results. I ran the 1-500 tests with TIMETHIS
in a 1-10 loop and read the output of that with FOR /F to get the quickest
time of the ten. I redirected ECHO to NUL: so my times were a little
quicker but they were still roughly the same as yours.
I'm sold. I think I'll go with the forward slash because next to the period
it's the easiest to type.
Thanks again Ritchie!
Frank
P.S. - My spell-checker keeps wanting to change your name to "Retch". If I
miss it one of these days, please understand.
Garry Deane
Jul 30, 2002, 9:24:05 PM7/30/02
to
On Tue, 30 Jul 2002 22:00:10 +0100, "Ritchie Lawrence"
<rlaw...@commanddoline.co.uk> wrote:
<rlaw...@commanddoline.co.uk> wrote:
<snip>
>As you can see the period has the worst times, it also causes problems when
>a file named 'echo' exists in the current directory. It seems the CALL
>command is iterating the PATH variable. To verify, script 2 tests were re-
>run, this time with the PATH variable undefined. The execution times for the
>colon, backslash and forward slash remained unchanged, whilst the time for
>the period was reduced dramatically.
>
>----------------------------------------------------------------------------
>Conclusion
>
>It's interesting that the colon and slashes stop CMD iterating the PATH.
>These are all illegal filename characters so I guess CMD just doesn't
>bother.
>
>So, what's the best character to use? Given that your scripts will be more
>reliable if using some kind of character immediately after ECHO, you may as
>well use one that gives the best all-round performance under all conditions
>and doesn't introduce new problems. That definitely rules out the period.
>The forward slash is clearly the best performer, hotly pursued by the colon
>and backslash.
>
>I going to continue with the colon, its what I've been using for the last
>few months. For all the new blood out there, if you want the fastest scripts
>then the forward slash is the way to go.
>
Great work! I've never been one to use 'echo.%var%' much - I prefer to
quickly see that I've overlooked something when I get an 'ECHO is on.'
message. Nevertheless, you've convinced me to use 'echo:' instead of
'echo.' when necessary.
I think I agree with you about using ':' rather than '/' simply
because it looks better.
Garry
bha.la...@gmail.com
Mar 7, 2013, 1:13:20 PM3/7/13
to
This is all very revealing: good dilligence. However, I noted a latent problem. Are the results the same in a .bat file as in a .cmd file? The former could be executed under superseded operating systems: DOS through Windows-98.
For example, Neil Rubenking’s 12/1992 /PC Magazine DOS Batch File Lab Notes/ revealed a technique for searching for multiple "/" characters (each a switch precursor) in %0 commands, which functions fine in Win-98 but fails in Windows-2000 and subsequent editions.
Another minor, overlooked problem is the case of others reading and copying one’s script code. As MS formally documents the use of the "." in ECHO, no one should conclude that it is erroneous. (For completeness, I believe that DOS 3.3 supports " " and not ".", but please check that for validity.) ECHO: looks a bit like ECHO., so some code readers might let it pass. However, to the uniformed (like me until today), ECHO/ looks erroneous.
Of course, the remedy for that is to insert an explanatory REM before its first use in your code, crediting the URL of this fine Google groups forum.
For example, Neil Rubenking’s 12/1992 /PC Magazine DOS Batch File Lab Notes/ revealed a technique for searching for multiple "/" characters (each a switch precursor) in %0 commands, which functions fine in Win-98 but fails in Windows-2000 and subsequent editions.
Another minor, overlooked problem is the case of others reading and copying one’s script code. As MS formally documents the use of the "." in ECHO, no one should conclude that it is erroneous. (For completeness, I believe that DOS 3.3 supports " " and not ".", but please check that for validity.) ECHO: looks a bit like ECHO., so some code readers might let it pass. However, to the uniformed (like me until today), ECHO/ looks erroneous.
Of course, the remedy for that is to insert an explanatory REM before its first use in your code, crediting the URL of this fine Google groups forum.
Frank Westlake
Mar 7, 2013, 4:04:22 PM3/7/13
to
2013-03-07 10:13, bha.la...@gmail.com:
> ... crediting the URL of this fine Google groups forum.
Your message may have been mis-sent: you have the header line
"Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group, not
to a grugle goop.
I can't answer any of your DOS related questions but others here may
still be maintaining compatibility with those operating systems.
Frank
> ... crediting the URL of this fine Google groups forum.
Your message may have been mis-sent: you have the header line
"Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group, not
to a grugle goop.
I can't answer any of your DOS related questions but others here may
still be maintaining compatibility with those operating systems.
Frank
jeb
Mar 7, 2013, 4:05:01 PM3/7/13
to
This seems to be a topic that pops periodically to the top.
"ECHO. FAILS to give text or blank line - Instead use ECHO/"
http://www.dostips.com/forum/viewtopic.php?p=4554#p4554
IMHO only "echo(" will be safe
echo:%var% and many other have problems with a path in %var%
Like \..\..\windows\system32\calc.exe
This expands to
echo:\..\..\windows\system32\calc.exe
and starts the calculator
echo. is not safe and very slow, as it forces a disk access (therefore you got an error message when a file exists named "echo")
jeb
"ECHO. FAILS to give text or blank line - Instead use ECHO/"
http://www.dostips.com/forum/viewtopic.php?p=4554#p4554
IMHO only "echo(" will be safe
echo:%var% and many other have problems with a path in %var%
Like \..\..\windows\system32\calc.exe
This expands to
echo:\..\..\windows\system32\calc.exe
and starts the calculator
echo. is not safe and very slow, as it forces a disk access (therefore you got an error message when a file exists named "echo")
jeb
Todd Vargo
Mar 7, 2013, 11:51:08 PM3/7/13
to
On 3/7/2013 1:13 PM, bha.la...@gmail.com wrote:
> This is all very revealing: good dilligence. However, I noted a latent problem. Are the results the same in a .bat file as in a .cmd file? The former could be executed under superseded operating systems: DOS through Windows-98.
>
> For example, Neil Rubenking�s 12/1992 /PC Magazine DOS Batch File Lab Notes/ revealed a technique for searching for multiple "/" characters (each a switch precursor) in %0 commands, which functions fine in Win-98 but fails in Windows-2000 and subsequent editions.
> This is all very revealing: good dilligence. However, I noted a latent problem. Are the results the same in a .bat file as in a .cmd file? The former could be executed under superseded operating systems: DOS through Windows-98.
>
>
> Another minor, overlooked problem is the case of others reading and copying one�s script code. As MS formally documents the use of the "." in ECHO, no one should conclude that it is erroneous. (For completeness, I believe that DOS 3.3 supports " " and not ".", but please check that for validity.) ECHO: looks a bit like ECHO., so some code readers might let it pass. However, to the uniformed (like me until today), ECHO/ looks erroneous.
>
> Of course, the remedy for that is to insert an explanatory REM before its first use in your code, crediting the URL of this fine Google groups forum.
>
Congratulations, you responded to a message from July 30, 2002.
> Of course, the remedy for that is to insert an explanatory REM before its first use in your code, crediting the URL of this fine Google groups forum.
>
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
foxidrive
Mar 7, 2013, 11:53:56 PM3/7/13
to
On 8/03/2013 3:51 PM, Todd Vargo wrote:
> On 3/7/2013 1:13 PM, bha.la...@gmail.com wrote:
>> This is all very revealing: good dilligence.
>
> On 3/7/2013 1:13 PM, bha.la...@gmail.com wrote:
>> This is all very revealing: good dilligence.
>
> Congratulations, you responded to a message from July 30, 2002.
That's a secret plan to increase the traffic in the group. Shhh. *taps nose*
--
foxi
frank.w...@gmail.com
Mar 8, 2013, 6:24:28 AM3/8/13
to
From Todd Vargo :
hasn't previously posted here replies to an old message,
then someone from dostips replies to that with a link to
dostips, then the previously unseen google account never
posts here again.
I call it SPAM.
Frank
>Congratulations, you responded to a message from July
>30, 2002.
The pattern seems to be that a google account which
>30, 2002.
hasn't previously posted here replies to an old message,
then someone from dostips replies to that with a link to
dostips, then the previously unseen google account never
posts here again.
I call it SPAM.
Frank
Liviu
Mar 9, 2013, 1:09:25 AM3/9/13
to
<frank.w...@gmail.com> wrote in message
news:13d49c35f51$frank.w...@gmail.com...
You have chosen a particularly ungracious way to say "thank you".
FYI the same link has been posted several times before, in reply to the
same question, and it happens to be the most meaningful answer, with all
the relevant background linked for those who care.
> I call it SPAM.
I call this post of yours NOISE.
Liviu
news:13d49c35f51$frank.w...@gmail.com...
FYI the same link has been posted several times before, in reply to the
same question, and it happens to be the most meaningful answer, with all
the relevant background linked for those who care.
> I call it SPAM.
I call this post of yours NOISE.
Liviu
Frank Westlake
Mar 9, 2013, 5:48:17 AM3/9/13
to
2013-03-08 22:09, Liviu:
hidden input? No, nor have I received thanks for any of my work here. So among all of you I am far advanced in the behavior of giving thanks.
And I shall not thank anybody who willfully engages in dishonesty, and mere deceit is dishonesty.
Frank
> You have chosen a particularly ungracious way to say "thank you".
I did thank Jeb when he first published that work here, and I have thanked him for other work since then, but did he thank Tom Lavedas for his work on
hidden input? No, nor have I received thanks for any of my work here. So among all of you I am far advanced in the behavior of giving thanks.
And I shall not thank anybody who willfully engages in dishonesty, and mere deceit is dishonesty.
Frank
Todd Vargo
Mar 9, 2013, 4:22:25 PM3/9/13
to
On 3/8/2013 2:56 PM, Andy wrote:
> On Tuesday, July 30, 2002 3:06:51 PM UTC-6, Ritchie Lawrence wrote:
>> ----------------------------------------------------------------------------
<long post snipped>
>> ----------------------------------------------------------------------------
>
> Could you condense your conclusions a bit ?
>
> Thanks.
>
Sure, here is a link for you.
http://lipas.uwasa.fi/~ts/http/quote.html
PS: I have not seen a post from him since the latter part of 2002.
Frank Westlake
Mar 9, 2013, 4:56:26 PM3/9/13
to
2013-03-09 13:22, Todd Vargo:
Good stuff.
Frank
Good stuff.
Frank
Todd Vargo
Mar 9, 2013, 5:52:42 PM3/9/13
to
Liviu
Mar 9, 2013, 7:01:56 PM3/9/13
to
"Frank Westlake" <frank.w...@gmail.com> wrote...
> 2013-03-08 22:09, Liviu:
Lighten up, Francis ;-)
Quite ironic to see such an enforcer of netiquette as you pose to be
disregard the basic rules and throw another loony fit, this time over a
perceived slight between two other posters, on a topic as unrelated
to the original topic of this thread as your first post was.
Liviu
> 2013-03-08 22:09, Liviu:
>>
>> I call this post of yours NOISE
>
> [snipped more NOISE]
>> I call this post of yours NOISE
>
Lighten up, Francis ;-)
Quite ironic to see such an enforcer of netiquette as you pose to be
disregard the basic rules and throw another loony fit, this time over a
perceived slight between two other posters, on a topic as unrelated
to the original topic of this thread as your first post was.
Liviu
bha.la...@gmail.com
Mar 9, 2013, 7:07:26 PM3/9/13
to
“Frank” wrote on 2013-03-07 10:13, bha.la...@gmail.com:
> ... crediting the URL of this fine Google groups forum.
Your message may have been mis-sent: you have the header line
"Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group, not
to a grugle goop.
I can't answer any of your DOS related questions[,] but others here may
> ... crediting the URL of this fine Google groups forum.
Your message may have been mis-sent: you have the header line
"Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group, not
to a grugle goop.
still be maintaining compatibility with those operating systems.
Frank
-----
Frank
Google automatically handled the posting. I found the forum accidentally through an ordinary Google search, which pointed to https://groups.Google.com/forum/?hl=en&fromgroups#!msg/alt.msdos.batch.nt/VhNXmRQEcVk/J3-C8ViGOD0J (pared URL).
“…others here may
still be maintaining compatibility with those operating systems.” Some might maintain Win-98 as an additional volume on their disk, for example. Others, like me, might have Win-98 on an old computer reserved for special purposes.
----
The basic question was whether anyone had replicated the tests under COMMAND.COM, not just cmd.exe. The old PC Magazine program bat2exe.com (DOS 3.3, I believe) yet may be downloaded on the internet. How would it treat ECHO/? Someday, I might test that one.
----
Incidentally, I am Bryan H. Allen, low-grade amateurish amateur script programmer. I know not the reason for Google instead posting a fragment of my e-mail address.
Todd Vargo
Mar 9, 2013, 11:19:53 PM3/9/13
to
Replacing NOISE with louder NOISE only makes the room louder. :(
Liviu
Mar 10, 2013, 1:38:17 AM3/10/13
to
<bha.la...@gmail.com> wrote...
Please fix your quoting. Google doesn't make it easy, nor obvious, but
you have still posted to a newsgroup on Usenet. Following the customs
of the land may help others help you better.
> The basic question was whether anyone had replicated the tests under
> COMMAND.COM, not just cmd.exe. [...] How would it treat ECHO/?
There is a command.com included with NT based windows, too, just not
the same as the old Win9x one.
For example, Echo. appears to work in Win9x even if a file named "echo"
exists. And Echo: works, too, even with an \..\etc\..\windows\calc.exe
argument. But Echo( fails with "bad command". Refer to jeb's post and
link for details on the above in NT-land.
As for Echo/?, it displays the help under all versions I can find.
Echo/ displays a blank line, Echo//? displays /? and Echo/* displays *.
Liviu
> "Frank" wrote on 2013-03-07 10:13
>> bha.la...@gmail.com:
>>> ... crediting the URL of this fine Google groups forum.
>> Your message may have been mis-sent: you have the header line
>> "Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group
>
>>> ... crediting the URL of this fine Google groups forum.
>> Your message may have been mis-sent: you have the header line
>> "Newsgroups: alt.msdos.batch.nt" so it was sent to the Usenet group
>
> Google automatically handled the posting.
> I found the forum accidentally through an ordinary Google search [...]
Please fix your quoting. Google doesn't make it easy, nor obvious, but
you have still posted to a newsgroup on Usenet. Following the customs
of the land may help others help you better.
> The basic question was whether anyone had replicated the tests under
There is a command.com included with NT based windows, too, just not
the same as the old Win9x one.
For example, Echo. appears to work in Win9x even if a file named "echo"
exists. And Echo: works, too, even with an \..\etc\..\windows\calc.exe
argument. But Echo( fails with "bad command". Refer to jeb's post and
link for details on the above in NT-land.
As for Echo/?, it displays the help under all versions I can find.
Echo/ displays a blank line, Echo//? displays /? and Echo/* displays *.
Liviu
0 new messages