On December 7, 2000 at 21:48, Gerry Hickman wrote:
best is the latest cygwin bash.
What is cygwin bash?
<http://www.cygwin.com/>
A free Unix-like API ontop of Win32 including many of the GNU utilties.
But forward slashes do work on NT as pathname delimiters.
Yes, but I don't think I can use forward slashes for regex delimiters?
I do not understand this statement.
Use an OS with real command-line shells ;^)
This is not OS dependent. bash and tcsh work fine on NT.
I imagine on UNIX you can use -mhpattern '^*.CNM' and it will work.
Trouble is on NT it seems you must use double quotes.
Technically, it is a function of the shell. Unix-based shells tend to
be consistent on how quoting is done. Double quotes allow variable
interpolation to occur in the quoted string while single quotes do not
(btw, Perl is the same in this behavior). The Windows's shells do not
follow this convention. The other annoying thing is that Win shells do
not perform file globbing. There is nothing technically preventing M$
to have the command shells provide functionality similiar to Unix-based
shells, but they have not. Hence, people have ported the Unix shells
to Windows.
Who knows what the rules are in a Windows Scripting Host?
On the whole, WshShell.Run(strCmd); will run any complex command line
you throw at it, including long file names and file names with spaces.
It also handles redirection and returns an exit code so you can test if
the call succeeded. Unfortunately, the double quotes thing seems to be a
problem.
Is there an argv style version that allows you to explicitly set
the list of arguments, bypassing the command shell?
Is possible to have it call a wrapper
Perl(?) script that then calls MHonArc with arguments you need?
At present I'm getting round it by calling a new command interpreter.
This seems to allow the double quotes, but it means I loose the return
code from MHonArc.BAT.
Out of interest, does MHonArc have specific return codes, and do they
propogate back to the BAT file? This would be handly when updating
multiple archives on an unattended box as you could bomb out of the loop
upon an error.
MHonArc does return codes. It is up to the calling process to
handle it as they see fit. Once MHonArc exits, how the return code
is handled is out MHonArc's hand. In a nutshell, 0 is return when
processing was successful. A non-zero is returned on error. The
return code 75 is returned if no lock could be obtained on the
archive.
Is it correct that I'm using MHonArc.BAT, or should I maybe be using
MHonArc.PL instead?
Under WinNT, you can use mhonarc.pl. It should be more efficient
since perl should be invoked directly due to file type association.
It also avoids the shell redirection problems when depending on
mhonarc.bat.
--ewh
