Minimise DOS prompts
Adrian
I used to be able to do it in 95/98, but can't see how in
2000.
Please replay by email too..
Thanx.
Musafir
start "myScript" /MIN myScript.bat
Warm regards,
Sharad Agarwal 'Musafir'
Ritchie
> I used to be able to do it in 95/98, but can't see how in
> 2000.
In case you're using COMMAND.COM, use CMD.EXE instead. As Musafir
has already said, use the START command with the /MIN switch. If
you want the script to always run minimized regardless of how it
has was launched, add something like this to the top of the script
(it basically relaunches the script minimized): -
@set !=||(set !=1&start "%~dpnx0" /min %comspec%/c %0 %*&set !=&goto :EOF)
--
Ritchie
Musafir
Hi,
Very neat trick. Works very well. Couple of questions:
1. Why does (@set !=) set an errorlevel if ! is not already defined?
2. The working of the || operator seems to go out of synch with the
errorlevel. For example:
======
C:\>echo %errorlevel%
1
C:\>set !=1||echo ERROR!
C:\>echo %errorlevel%
1
======
Thanks in advance,
Sharad Agarwal 'Musafir'
Ritchie
> 1. Why does (@set !=) set an errorlevel if ! is not already defined?
Its CMD's way of letting you know you just tried to undefine a
variable that was already defined:-
==================screen dump====================
d:\data\bat\help>echo/%errorlevel%
0
d:\data\bat\help>set a=123
d:\data\bat\help>echo/%errorlevel%
0
d:\data\bat\help>set a=
d:\data\bat\help>echo/%errorlevel%
0
d:\data\bat\help>set a=
d:\data\bat\help>echo/%errorlevel%
1
==================screen dump====================
> 2. The working of the || operator seems to go out of synch with the
> errorlevel. For example:
>
> ======
> C:\>echo %errorlevel%
> 1
>
> C:\>set !=1||echo ERROR!
>
> C:\>echo %errorlevel%
> 1
> ======
I see what you're getting at. Here's whats happening:
The || and && operators do not decide whether the preceeding
command succeeded or failed by just looking at the errorlevel
after the command has finished.
What happens is that CMD.EXE runs that command and if the command
did not return an errorlevel, then it considers the command to
have succeeded. Only if the command returns a non-zero errorlevel,
is the command deemed to have failed.
--
Ritchie
Garry Deane
<qiournvdlirh...@hotmail.com> wrote:
>I see what you're getting at. Here's whats happening:
>The || and && operators do not decide whether the preceeding
>command succeeded or failed by just looking at the errorlevel
>after the command has finished.
>
>What happens is that CMD.EXE runs that command and if the command
>did not return an errorlevel, then it considers the command to
>have succeeded. Only if the command returns a non-zero errorlevel,
>is the command deemed to have failed.
I think you're on the right track but not 100%. I'm sure you're right
that Cmd checks the return code and bases its success or failure
conditional action on whether the return code is 0 or not. However
setting of the errorlevel variable is a separate step.
For external programs, Cmd always appears to copy the return code to
%errorlevel%. However for internal commands, it doesn't always copy
the return code to %errorlevel% even though it will branch to && ||
conditionals correctly.
SET is an example where %errorlevel% will be set on failure but not on
success. POPD is another but is even weirder as the following example
shows.
Garry
@echo off
setlocal
:: Set errorlevel to 0
ver > nul
set var=0
set /a %var% 2>nul && echo %var% is numeric || echo %var% is not
numeric
echo Errorlevel is %errorlevel% because SET/A didn't fail
set var=123a
set /a %var% 2>nul && echo %var% is numeric || echo %var% is not
numeric
echo Errorlevel is %errorlevel% because SET/A produced an error
set var=-123
set /a %var% 2>nul && echo %var% is numeric || echo %var% is not
numeric
echo Errorlevel is still %errorlevel% even though SET/A didn't fail
echo:
ver > nul
pushd %temp%
echo Errorlevel is %errorlevel% because PUSHD didn't fail
popd && echo POPD didn't fail || echo POPD failed
echo Errorlevel after POPD is %errorlevel%
popd
echo Errorlevel after POPD is %errorlevel%
popd && echo POPD didn't fail || echo POPD failed
echo Errorlevel after POPD is %errorlevel%
Musafir
> On Thu, 17 Apr 2003 23:02:17 +0100, "Ritchie"
> <qiournvdlirh...@hotmail.com> wrote:
>
> >I see what you're getting at. Here's whats happening:
> >The || and && operators do not decide whether the preceeding
> >command succeeded or failed by just looking at the errorlevel
> >after the command has finished.
> I think you're on the right track but not 100%. I'm sure you're right
> that Cmd checks the return code and bases its success or failure
> conditional action on whether the return code is 0 or not. However
> setting of the errorlevel variable is a separate step.
>
> For external programs, Cmd always appears to copy the return code to
> %errorlevel%. However for internal commands, it doesn't always copy
> the return code to %errorlevel% even though it will branch to && ||
> conditionals correctly.
>
> SET is an example where %errorlevel% will be set on failure but not on
> success. POPD is another but is even weirder as the following example
Good ideas. I guess it would be safe to summarize:
For internal commands, occasionally the %ErrorLevel% is not updated
with the return code (examples - SET does not update on success; POPD
does not update on failure). To capture these conditions, we should
use the conditional operators (&& ||) which function against the
return code (rather than the %ErrorLevel%).
It might also be worthwhile to note that the following NEVER change
the %ErrorLevel% :
a) ECHO - This internal command never changes the %ErrorLevel%
b) GOTO :Label - This internal command never changes the %ErrorLevel%
I get inconsistent behaviour for the '/?' switch.
<Command> /? - For many commands this never changes the %ErrorLevel%
For example - net, vol, date. For others, it resets the %ErrorLevel%
to 0 - more, help, xcopy.
Warm regards,
Sharad Agarwal 'Musafir'
PS: I would suspect that we could attempt to these _explain_ these
'idiosyncrasies':
1. SET - It might be that some commands (rather their authors) assume
that the current errorlevel is '0' when they were invoked. Hence, they
do not bother to copy a success return code to %ErrorLevel%. This
might also explain the inconsistent behaviour of the '/?' switch.
2. POPD - Trying to exit from a PUSHD directory stack from it's root.
Even though the command returns a code (to let you know that something
out of the ordinary has occurred), it is not really an Error. You just
remain where you are. Or maybe, the implementer was just careless.
Musafir
solution?
====== Begin Teaser Number 1
C:\>echo %errorlevel%
9009
C:\>del t
Could Not Find C:\t
C:\>echo %errorlevel%
0
C:\>del t || echo WOO
Could Not Find C:\t
C:\>
====== End Teaser Number 1
I suppose this is just another bug - DEL seems to reset the
%ErrorLevel% to 0 and _always_ succeeds (except in the case 'del /?'
where it chooses to leave the %ErrorLevel% alone).
====== Begin Teaser Number 2
C:\>echo %errorlevel%
0
C:\>popd.exe
C:\>echo %errorlevel%
0
C:\>popd.exe || echo WOO
WOO
C:\>echo %errorlevel%
1
C:\>
====== End Teaser Number 2
From the first two commands, it would seem that POPD.exe passes a
return code but the %ErrorLevel% is not being set. But then, how do we
explain the third command? How does using a conditional cause the
%ErrorLevel% to be set?
Al Dunbar
> Here are some more teasers. Can anyone offer even a plausible
> solution?
>
> ====== Begin Teaser Number 1
> C:\>echo %errorlevel%
> 9009
>
> C:\>del t
> Could Not Find C:\t
>
> C:\>echo %errorlevel%
> 0
>
> C:\>del t || echo WOO
> Could Not Find C:\t
>
> C:\>
> ====== End Teaser Number 1
>
> I suppose this is just another bug - DEL seems to reset the
> %ErrorLevel% to 0 and _always_ succeeds (except in the case 'del /?'
> where it chooses to leave the %ErrorLevel% alone).
Not so much a bug, as an intrinsic difference between what *you* think
ERRORLEVEL means and what MS thinks. Not all commands (or even programs)
universally set the error code such that any type of error results in a
non-zero error code. In this case, however, one incidental result of the del
t command is that, afterwards, file "t" does not exist! ;-)
The team that wrote the del code probably thought to themselves that "hey it
is easier, and more logically correct, to deduce success or failure of the
del command based on the existence status of the file before and after than
to base it on an error code. The fact that it appears to actually reset the
code to zero has probably something to do with how the code is exited. Since
they were not (apparently) concerned with the error code, returning a zero
for all cases but "del /?" makes sense. Given the inconsistent way commands
and executables treat the errorlevel code, a person would be a fool to defer
the test of the successful completion of one command until after running
some other command, i.e.:
myprog.exe > myprog.txt
del myprog.txt
if errorlevel 1 echo/myprog.exe failed!
"cool" regards,
Al Dunbar 'Al Dunbar
Marty List
I disagree, for me the DEL command has always exited with 0 on success and 1
on failure:
C:\>Echo %ERRORLEVEL%
0
C:\>Del
The syntax of the command is incorrect.
C:\>Echo %ERRORLEVEL%
1
C:\>Del /?>NUL
C:\>Echo %ERRORLEVEL%
1
C:\>Del t
Could Not Find C:\t
C:\>Echo %ERRORLEVEL%
1
C:\>Ver>NUL
C:\>Echo %ERRORLEVEL%
0
C:\>Del t
Could Not Find C:\t
C:\>Echo %ERRORLEVEL%
1
C:\>Echo Test>Test.txt
C:\>Del Test.txt
C:\>Echo %ERRORLEVEL%
0
"Al Dunbar" <Luigi...@hotmail.com> wrote in message
news:u4gxXUE...@TK2MSFTNGP12.phx.gbl...
Garry Deane
wrote:
Interesting. It looks like this behaviour has changed from NT (which I
and I think Musafir are on) to W2k/XP (which you are presumably on).
D:\>echo %errorlevel%
0
D:\>del t
Could Not Find D:\t
D:\>echo %errorlevel%
0
D:\>type nul > t
D:\>attrib +r t
D:\>echo %errorlevel%
0
D:\>del t
D:\t
Access is denied.
D:\>echo %errorlevel%
18
D:\>del /? > nul
D:\>echo %errorlevel%
18
D:\>del q
Could Not Find D:\q
D:\>echo %errorlevel%
0
I guess the bottom line is test the behaviour of errorlevel across
different OS's before relying on the result.
Garry
Marty List
VERY interesting. I don't have access to NT4 at the moment, I will
tomorrow.
It seems it's broken again in Windows Server 2003 release candidate 2:
C:\>Echo %ERRORLEVEL%
0
C:\>Del dsfds
Could Not Find C:\dsfds
C:\>Echo %ERRORLEVEL%
0
C:\>Del /?>NUL
C:\>Echo %ERRORLEVEL%
0
C:\>Del C:\Pagefile.sys
Could Not Find C:\Pagefile.sys
C:\>Echo %ERRORLEVEL%
0
C:\>Del /a C:\Pagefile.sys
C:\Pagefile.sys
The process cannot access the file because it is being used by another
process.
C:\>Echo %ERRORLEVEL%
0
"Garry Deane" <garrydeane_at_yahoo.com.au> wrote in message
news:3ea4a088...@192.168.0.2...
Musafir
can summarize this discussion:
The command
C:\>del NonExistentFile
NT: sets the %ErrorLevel% to 0
Win2K: sets the %ErrorLevel% to 1
WinXP: sets the %ErrorLevel% to 0
(Al - let me put it like this, the bug was fixed and then
re-introduced ;-) ).
Since the behaviour varies across versions, to capture this condition
we should use other means (like checking for existence of the file
before deleting it).
While this is an interesting muse, each version of Windows is
consistent within itself and, as Al mentioned, different people have
different opinions on what constitutes an error. It is Teaser Number 2
that really confounds. Here it is again:
====== Begin Teaser Number 2 - both NT and 2K
C:\>echo %errorlevel%
0
C:\>popd
C:\>echo %errorlevel%
0
C:\>popd || echo WOO
WOO
C:\>echo %errorlevel%
1
C:\>
====== End Teaser Number 2
Put in words - POPD does not set an %ErrorLevel% when invoked from the
root of the directory stack. But, when you use the conditional
operator with it, suddenly the %ErrorLevel% is set. How does this
%ErrorLevel% get set?
Marty List
I sure hope some of the Microsoft developers are reading this thread. It
would be great if they actually interacted like the WMI team does.
"Musafir" <bh...@mailcity.com> wrote in message
news:ddfbb7a7.03042...@posting.google.com...
Musafir
Ritchie TED) do @echo Wake up %%a !!
This one is for you ...
[snip]
> It is Teaser Number 2
> that really confounds. Here it is again:
>
> ====== Begin Teaser Number 2 - both NT and 2K
> C:\>echo %errorlevel%
> 0
>
> C:\>popd
>
> C:\>echo %errorlevel%
> 0
>
> C:\>popd || echo WOO
> WOO
>
> C:\>echo %errorlevel%
> 1
>
> C:\>
> ====== End Teaser Number 2
>
> Put in words - POPD does not set an %ErrorLevel% when invoked from the
> root of the directory stack. But, when you use the conditional
> operator with it, suddenly the %ErrorLevel% is set. How does this
> %ErrorLevel% get set?
>
> Warm regards,
> Sharad Agarwal 'Musafir'
[/snip]
Clay Calvert
>[snip]
>> It is Teaser Number 2
>> that really confounds. Here it is again:
>>
>> ====== Begin Teaser Number 2 - both NT and 2K
>> C:\>echo %errorlevel%
>> 0
>>
>> C:\>popd
>>
>> C:\>echo %errorlevel%
>> 0
>>
>> C:\>popd || echo WOO
>> WOO
>>
>> C:\>echo %errorlevel%
>> 1
>>
>> C:\>
>> ====== End Teaser Number 2
>>
>> Put in words - POPD does not set an %ErrorLevel% when invoked from the
>> root of the directory stack. But, when you use the conditional
>> operator with it, suddenly the %ErrorLevel% is set. How does this
>> %ErrorLevel% get set?
>>
>> Warm regards,
>> Sharad Agarwal 'Musafir'
>[/snip]
I have no idea why this occurs. I wish it did make sense, but it
doesn't... at least not yet.
Walter Zackery wrote up a list of "Windows NT tricks, traps and
undocumented features" about NT.
http://groups.google.com/groups?selm=7s8dru%245gmu%241%40newssvr04-int.news.prodigy.com
Maybe the redirected PopD error could be another for the list?
Clay Calvert
CCal...@Wanguru.com
Replace "W" with "L"
Phil Robyn
Here's another POPD anomaly:
- - - - - - - - - - begin screen capture - - - - - - - - - -
<Win2000> c:\cmd>pushd %temp%
<Win2000> C:\temp>popd
<Win2000> C:\CMD>
- - - - - - - - - - end screen capture - - - - - - - - - -
Why does the case of 'C:\CMD' change from lower to upper?
--
Phil Robyn
Univ. of California, Berkeley
u n z i p m y a d d r e s s t o s e n d e - m a i l
Ritchie
> - - - - - - - - - - begin screen capture - - - - - - - - - -
> <Win2000> c:\cmd>pushd %temp%
>
> <Win2000> C:\temp>popd
>
> <Win2000> C:\CMD>
> - - - - - - - - - - end screen capture - - - - - - - - - -
>
> Why does the case of 'C:\CMD' change from lower to upper?
Maybe COMMAND.COM is now the current interpreter??? sounds
unlikely, but its all I can think of at the moment. BTW,
POPD doesn't change the case of my prompt (w2k.sp3)!
- - - - - - - - - - begin screen capture - - - - - - - - - -
D:\data\bat\help>ver
Microsoft Windows 2000 [Version 5.00.2195]
D:\data\bat\help>pushd %temp%
D:\static\Temp>popd
D:\data\bat\help>command
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-1999.
D:\DATA\BAT\HELP>exit
D:\data\bat\help>
- - - - - - - - - - end screen capture - - - - - - - - - -
--
Ritchie
Phil Robyn
Hi, Ritchie!
I was using Win2000 CMD.EXE on an NT4.0 system at home.
Microsoft Windows 2000 [Version 4.00.1381]
The same thing happens with NT4.0 CMD.EXE. I'm on vacation
for two days, but I'll try it at work (Win2000, sp whatever
Windows Update has put on the box) when I go back.
Ritchie
> I was using Win2000 CMD.EXE on an NT4.0 system at home.
>
> Microsoft Windows 2000 [Version 4.00.1381]
I just tried it on NT4.SP6a using its native cmd processor
and that from Win 2000. I still get the same results - that
is the case of the prompt does not change!
> The same thing happens with NT4.0 CMD.EXE. I'm on vacation
> for two days, but I'll try it at work (Win2000, sp whatever
> Windows Update has put on the box) when I go back.
If you've left the box unattended with WU running you'll be
lucky if you can logon let alone run a script :)
--
Ritchie
Ritchie
> Ritchie TED) do @echo Wake up %%a !!
Hi Musafir,
I thought this was resolved? Anyway, what about this one. Its
based on Garry Deane's observation of my Hangman script. Make
two identical copies of the script below, one with a .bat
extension, the other with a .cmd extension:-
--------- start of a.bat/a.cmd ------------
@echo off&setlocal ENABLEEXTENSIONS
call :func&&echo/cmd||echo/bat
goto :EOF
:func
md;2>nul
set var=1
--------- end of a.bat/a.cmd ---------------
--------- <screengrab> ------------------
D:\data\bat\help>a.bat
bat
D:\data\bat\help>a.cmd
cmd
--------- </screengrab> ------------------
Some scripts are created more equally than others :)
--
Ritchie
Musafir
...
> --------- start of a.bat/a.cmd ------------
> @echo off&setlocal ENABLEEXTENSIONS
> call :func&&echo/cmd||echo/bat
> goto :EOF
>
> :func
> md;2>nul
> set var=1
> --------- end of a.bat/a.cmd ---------------
>
> --------- <screengrab> ------------------
> D:\data\bat\help>a.bat
> bat
>
> D:\data\bat\help>a.cmd
> cmd
> --------- </screengrab> ------------------
>
> Some scripts are created more equally than others :)
A little experimentation boils it down to the following:
In a .cmd, if you SET a variable correctly, the errorlevel is reset to
'0'.
In a .bat, if you SET a variable correctly, the errorlevel is left
unchanged.
From the prompt, if you SET a variable correctly, the errorlevel is
left unchanged.
I guess this, quite unambiguously, puts to rest all speculation that
in NT+ .cmd and .bat are exactly the same. Congratulations!
I tried changing the ASSOC for .bat to 'cmdfile' (FTYPE for both is
the same) but its behaviour did not change. So, the difference is at a
lower level still.
Musafir
> Ritchie wrote:
> > "Phil Robyn" <zipp...@uclink.berkeley.edu> wrote in message news:ua3n2TtD...@TK2MSFTNGP11.phx.gbl...
> >
> >>- - - - - - - - - - begin screen capture - - - - - - - - - -
> >><Win2000> c:\cmd>pushd %temp%
> >>
> >><Win2000> C:\temp>popd
> >>
> >><Win2000> C:\CMD>
> >>- - - - - - - - - - end screen capture - - - - - - - - - -
> >>
> >>Why does the case of 'C:\CMD' change from lower to upper?
I could not reproduce it on NT4.0 or Win2K. I am assuming that the
name of the directory is in lower case ('cmd')?
Warm regards,
Sharad Agarwal
Jonathan de Boyne Pollard
Because (most likely) the actual spelling of the directory name is
"CMD", whereas the spelling of the working directory name in the
shortcut that you used to start the command interpreter is "cmd".
Marty List
I don't know about everyone else, but this thread and a couple others have
made me lose faith in native shell scripting. I always knew there were some
minor anomalies, but IMO these are serious bugs. I don't think I will feel
confident doing anything important with batch files any more.
"Musafir" <bh...@mailcity.com> wrote in message
news:ddfbb7a7.03043...@posting.google.com...
Torgeir Bakken (MVP)
> I don't know about everyone else, but this thread and a couple others have
> made me lose faith in native shell scripting. I always knew there were some
> minor anomalies, but IMO these are serious bugs. I don't think I will feel
> confident doing anything important with batch files any more.
Does that mean that we will see more of you over at the vbscript/wsh groups <g>?
--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide: http://www.microsoft.com/technet/scriptcenter
Marty List
That's right, in fact I just added a subscription to
'microsoft.public.scripting.wsh' in Outlook Express, how funny. This group
and 'alt.msdos.batch.nt' are the only ones I read daily, but I spend a lot
if time in C++, C# and WMI groups.
I found several for Perl, but none that were specific to Win32. I couldn't
find anything at all for KiXtart, but http://www.kixtart.org/ and
http://boards.cramsession.com/boards/vbt.asp?b=45 are good enough.
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:3EB081F0...@hydro.com...
Garry Deane
<qiournvdlirh...@hotmail.com> wrote:
<snip>
> Make two identical copies of the script below, one with a .bat
>extension, the other with a .cmd extension:-
>
>--------- start of a.bat/a.cmd ------------
>@echo off&setlocal ENABLEEXTENSIONS
>call :func&&echo/cmd||echo/bat
>goto :EOF
>
>:func
>md;2>nul
>set var=1
>--------- end of a.bat/a.cmd ---------------
>
>--------- <screengrab> ------------------
>D:\data\bat\help>a.bat
>bat
>
>D:\data\bat\help>a.cmd
>cmd
>--------- </screengrab> ------------------
>
>Some scripts are created more equally than others :)
Hi Ritchie,
I've been away for a few days so am just catching up. That was one
hell of a catch - whoda thunk it.
Garry
Ritchie
>
> I don't know about everyone else, but this thread and a couple others have
> made me lose faith in native shell scripting. I always knew there were some
> minor anomalies, but IMO these are serious bugs. I don't think I will feel
> confident doing anything important with batch files any more.
I guess you're referring to the subtle difference between .cmd and
.bat files mentioned here and in the hangman thread. I don't think
you should be too concerned about that issue. After all, it is an
undocumented 'feature' and only came to light as a result of a poorly
written function in the hangman script that was based on a number of
assumptions (thanks Garry/Musafir).
I can't really say that I now have more faith in native shell
scripting, but I certiainly don't have any less. With a better
understanding of the command shell nuances, it should be possible
to write more reliable scripts.
<gets on high horse>
Anyone serious about writing reliable shell scripts should
consider the use of self-contained 100% re-usable functions for
all but the simplest of scripts. The use of functions minimize
the number of 'global' variables and the functions themselves
can be tweaked without upsetting anything else.
The hangman script isn't exactly rocket science, but can you
imagine trying to debug it after making a few changes if those
functions weren't self-contained? Fixing one thing would just
break something else.
</gets on high horse>
--
Ritchie
Marty List
I haven't been following the hangman thread, and I'm not sure how your
references to global variables and the use of functions relate here, those
statements are true but ture of any language or coding practices. But it's
not only the differences between .bat & .cmd, it's also the inconsistent
return codes between different commands and different versions of the
operating systems. If I'm using basic commands like DEL I don't think I
should have to test the batch file on every version of the OS. If we were
talking about a couple bugs that were fixed I would be willing to deal with
that, but for example the DEL return code is broke in NT4, fixed in 2000/XP,
but broke again in Server 2003.
If I can't rely on the most basic functionality working, I'm not going to
waste much time writing batch files. After all, that's the whole reason I
was willing to put up with a limited and immature scripting language,
because the scripts would run natively and reliably on each version of the
OS. This may not seem like a big problem to some, but over the years I've
been slowly getting tired of all the little "nuances" and this is like the
"last straw".
Ritchie
> OS. This may not seem like a big problem to some, but over the years I've
> been slowly getting tired of all the little "nuances" and this is like the
> "last straw".
Fair comment. If you stop writing batch files then I hope you don't also
stop writing for batch.nt and cmdprompt.admin.
--
Ritchie
Marty List
Gee thanks Ritchie. I feel wanted and safe here, and people like me! ;-)
I didn't mean to imply I was going to stop writing batch files entirely, I
just don't feel comfortable using them for anything important or writing
them for clients, etc. They're still the best thing for small simple jobs
that won't cause too much harm if they break, I'll just be less trusting and
use them less often. I still plan on hanging out here to help out others
and keep my skills sharp!
"Ritchie" <qiournvdlirh...@hotmail.com> wrote in message
news:b8r679$cjpe6$1...@ID-156657.news.dfncis.de...
Bill Stewart
> I don't know about everyone else, but this thread and a couple others
> have made me lose faith in native shell scripting. I always knew there
> were some minor anomalies, but IMO these are serious bugs. I don't think
> I will feel confident doing anything important with batch files any more.
FWIW, I have come to the same sort of conclusion myself -- native batch
files just don't cut it for anything more than very simple scripting jobs.
There are just too many inconsistencies. Like you, I still use simple shell
scripting for small jobs, and I still read these newsgroups to keep my
skills sharp, but scripting with cmd just isn't robust enough for my needs.
Musafir
> "Ritchie" <qiournvdlirh...@hotmail.com> wrote in message
> news:b8qsbh$cr1en$1...@ID-156657.news.dfncis.de...
> > <gets on high horse>
> >
> > Anyone serious about writing reliable shell scripts should
> > consider the use of self-contained 100% re-usable functions for
> > all but the simplest of scripts. The use of functions minimize
> > the number of 'global' variables and the functions themselves
> > can be tweaked without upsetting anything else.
Well said. I fully agree. I know this is a huge undertaking, but what
say we pool the collective wisdom/scripts available at this NG and set
up a free library. It would be much more than a FAQ could ever be!
> > </gets on high horse>
Ok. I am off the horse now, but I wasn't horsing around ;-) It would
take some effort. We would need to categorize the scripts, decide on
code conventions and the like.
...
> But it's
> not only the differences between .bat & .cmd, it's also the inconsistent
> return codes between different commands and different versions of the
> operating systems. If I'm using basic commands like DEL I don't think I
> should have to test the batch file on every version of the OS. If we were
> talking about a couple bugs that were fixed I would be willing to deal with
> that, but for example the DEL return code is broke in NT4, fixed in 2000/XP,
> but broke again in Server 2003.
>
> If I can't rely on the most basic functionality working, I'm not going to
> waste much time writing batch files. After all, that's the whole reason I
> was willing to put up with a limited and immature scripting language,
> because the scripts would run natively and reliably on each version of the
> OS. This may not seem like a big problem to some, but over the years I've
> been slowly getting tired of all the little "nuances" and this is like the
> "last straw".
What have I done!
But, a lot of good has come out of this. As others have mentioned, I
am also undergoing a change of 'religion' here. Batch is good for
small tasks. It is great to have a command on it (comes in handy even
in day to day programming). It is fine even for some larger tasks as
long as we are very careful to test all assumptions in the
environment(s) we plan to run in.
I think I am going to stick around because I have learnt a lot in this
NG and the reasons in the previous paragraph. But I am planning to
move on to a better scripting language for more serious tasks. I have
done a bit of Perl. I hear good things about Python. Any suggestions
folks?
Mark V
>
> Gee thanks Ritchie. I feel wanted and safe here, and people like
> me! ;-)
>
> I didn't mean to imply I was going to stop writing batch files
> entirely, I just don't feel comfortable using them for anything
> important or writing them for clients, etc. They're still the
> best thing for small simple jobs that won't cause too much harm if
> they break, I'll just be less trusting and use them less often. I
> still plan on hanging out here to help out others and keep my
> skills sharp!
That's Good! Your input is too valuable to lose entirely.
Phil Robyn
<<<<<<<<<snip>>>>>>>>>
>
> I think I am going to stick around because I have learnt a lot in this
> NG and the reasons in the previous paragraph. But I am planning to
> move on to a better scripting language for more serious tasks. I have
> done a bit of Perl. I hear good things about Python. Any suggestions
> folks?
Have you ever tried Rexx? Or if you're familiar with Perl and Python,
what about Ruby?
>
> Warm regards,
> Sharad Agarwal 'Musafir'
Mark V
> Musafir wrote:
> <<<<<<<<<snip>>>>>>>>>
>>
>> I think I am going to stick around because I have learnt a lot in
>> this NG and the reasons in the previous paragraph. But I am
>> planning to move on to a better scripting language for more
>> serious tasks. I have done a bit of Perl. I hear good things
>> about Python. Any suggestions folks?
>
> Have you ever tried Rexx? Or if you're familiar with Perl and
> Python, what about Ruby?
I believe REXX is an excellent choice unless you are Windows-only.
Started with it in OS/2 1.2 and available on very nearly every
platform.
Ritchie
> Well said. I fully agree. I know this is a huge undertaking, but what
> say we pool the collective wisdom/scripts available at this NG and set
> up a free library. It would be much more than a FAQ could ever be!
FREE! Are you mad? We could charge a buck less than Mount Guard :)
Anyway, at this rate there won't be anyone here to use it.
--
Ritchie
Jonathan de Boyne Pollard
PR> Have you ever tried Rexx? Or [...]
MV> I believe REXX is an excellent choice unless you are Windows-only.
REXX is an excellent choice even if one _is_ Windows-only.
Mark V
news:3EB62CD0...@tesco.net:
> M> Any suggestions folks?
>
> PR> Have you ever tried Rexx? Or [...]
>
> MV> I believe REXX is an excellent choice unless you are
> Windows-only.
Nah, the Windows-only crowd wants VB* don't they? <G>
(Sorry Jeff G). -MV-
> REXX is an excellent choice even if one _is_ Windows-only.
I retract my former (half-joking) statement and endorse this one as
correct and true.
--
Mark V
Musafir
> > REXX is an excellent choice even if one _is_ Windows-only.
>
> I retract my former (half-joking) statement and endorse this one as
> correct and true.
Did a bit of research:
http://www.ipd.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
http://www.rubygarden.org/iowa/faqtotum/abcjoKXUnsM2/b/1.11.7.2.5
If anyone can point me towards more/better links to objective
analysis, please do so.
Also, there seems to be a large Python community out there. I am
leaning towards Python. As a friend has on his home page:
"Bash for ten-liners, Perl for hundred-liners, Python for
thousand-liners and Java for million-liners. I have replaced C by
Python as my general purpose programming language over last couple of
years, primarily because it integrates so well with both Java and C ."
John Brock
Jeff Glatt <jgl...@spamgone-borg.com> wrote:
>>here seems to be a large Python community out there. I am
>>leaning towards Python.
>
>with the benefit of hindsight in its design. For example python lets
>you perform operations with strings in the same way as numbers, so
>it's more consistent than REXX:
>
>Python:
>PRINT 2 + 2
>PRINT "hello " + "world"
>
>REXX:
>SAY 2 + 2
>SAY "hello" "world" /* or SAY "hello" || "world", but not SAY "hello"
>+ "world" */
>
>And that's just one example of where the designers of Python learned
>from, and improved upon, REXX.
I have to quibble with your language: the Rexx approach wasn't a
mistake, something to be improved upon by Python, it was an
inescapable consequence of a fundamental design decision in Rexx.
In Rexx everything is a string. This has the advantage of great
simplicity -- no black boxes! There is a lot be be said for this
choice, and I do think it's the easiest for novice programmers.
But as a consequence you can't overload operators, which means you
*need* two distinct operators here: one to return "4" and the
other to return "22". In Python, as I understand it, everything
is an object. This is a *huge* step upward in complexity, and I
think it is a great tribute to the design of Python that it still
has a reputation for being easy to use.
>And Python but has much better support than REXX.
>
>It seems like a fairly easy language to learn/use for a novice. (I'm
>not sure if I'd advise an advanced programmer to use it, especially if
>creating a program that needs to be very complex in its design and
>functionality. But for a novice programmer creating small utilities,
>it could be a very good choice).
>
>(To be honest, if I had run across www.python.org before I put so much
>work into the Regina REXX sources, I'd have skipped REXX and gone to
>Python)
No argument here. Python sounds really nice, and I wish I had a
good excuse to spend some time with it. Instead I'm stuck using
Perl, which..., how can I put this delicately?... is a wonderful
programming language for people who love surprises....
--
John Brock
jbr...@panix.com