Computer Hope
Microsoft => Microsoft DOS => Topic started by: Salmon Trout on April 21, 2010, 02:11:09 PM
-
... with one gotcha: no labels. I make no great claims for this, I just present it as a curiosity. There are other ways of doing this.
A leading colon in a batch file is ignored because it denotes a label; it is ignored in VBscript because it is a command separator. Thus the batch script can search itself for lines beginning with a colon and write them out to a temporary vbs file and then execute it.
@echo off
echo This is batch
:wscript.echo "This VBScript"
:wscript.echo "Today is " & day(date) & "-" & month(date) & "-" & year(date)
findstr "^:" "%~sf0">temp.vbs & cscript //nologo temp.vbs & del temp.vbs
echo This is batch again
This is batch
This VBScript
Today is 21-4-2010
This is batch again
Maybe you want to use some GUI feature of wscript e.g. to get user input
@echo off
:wscript.echo InputBox("Enter your name")
findstr "^:" "%~sf0">temp.vbs & for /f "delims=" %%N in ('cscript //nologo temp.vbs') do set name=%%N & del temp.vbs
echo You entered %name%
-
Neat!
Worked firs time!
-
but why does anyone want to write hybrids in the first place? i don't understand.
1) makes code uneasy to read and troubleshoot
2) have to take care of different syntax between vbscript and batch.
3) creation of temp files everytime the batch is run. why not just write one vbscript and run it instead.
-
ghostdog74 ,
Your point of view is valid. Many will agree with you.
Yet others will just love the way he put it all in one box.A large number of everyday real world coders often use hybrid methods.
The novelty of this batch file is that it is a legal batch file!
The concept is by no means new. Some COBOL Programs had FORTRAN embedded in the source code. There was COBOL statement to invoke the FORTRAN compiler for some calculations.
-
but why does anyone want to write hybrids in the first place? i don't understand.
1) makes code uneasy to read and troubleshoot
2) have to take care of different syntax between vbscript and batch.
3) creation of temp files everytime the batch is run. why not just write one vbscript and run it instead.
I make no great claims for this, I just present it as a curiosity. There are other ways of doing this.
1) makes code uneasy to read and troubleshoot
As opposed to, of course, the perfectly easy to read perl.
2) have to take care of different syntax between vbscript and batch.
perl programmers have no problem taking care of the different syntax between perl and Regular Expressions. .NET programmers have no problem differentiating language constructs from those provided by LINQ, and I hardly see batch+VBS as a exceptional case.
3) creation of temp files everytime the batch is run. why not just write one vbscript and run it instead.
As surprising as this may sound there is a lot of functionality in batch (particularly in the various NT extensions) that, while doable in VBScript, are far more verbose. also, we cannot forget that a a good number of the very tools you recommend (sed, gawk, and a few others) are at their best when combined with the shell in which they run- piping output to and from SED is it's very purpose, just like find and sort, both of which have functionality that is verbose and prone to errors when attempting to duplicate in VBScript. also, this allows one to combine Batch with SED and other tools of that nature with VBScript.
There is a rather large downside, and that is the extraneous use of find in order to "extract" the vbscript, but one can generally assume that a batch files run-time is far less important then it's results, and unless it is run extensively and/or with a large batch file it's usually of little consequence.
The concept is by no means new. Some COBOL Programs had FORTRAN embedded in the source code. There was COBOL statement to invoke the FORTRAN compiler for some calculations.
I embed machine code instructions in my Visual basic programs in the form of a string variable or constant, and then use that as a Window Procedure for subclassing; The Machine Code is given access to the Vtable of a specific Interface and calls the methods on that interface, which I implement elsewhere. (in a class module, for example).
VB6 of course has built-in "support" for callback routines (in the form of the addressof Operator) however, one can only use addressof on functions/routines in public modules; managing and dispatching each callback to the appropriate object that is to receive it is nothing short of difficult. Also, it means that using the debugging tools (break, stop, breakpoints, etc) will cause a instant Fault and VB will crash. Using a String variable containing Machine code has two advantages- first, it can be used without a module (meaning each class is self-contained) and second, since the string pointer remains valid, it doesn't crash the IDE when the break/end etc. buttons are used. My first concern using this technique was that it might somehow trigger DEP (data execution) but it didn't, and it's worked fine so far.
A prime example of this facility in use was a class I wrote for better control of window sizing- namely, to allow for the handling of the WM_GETMINMAXINFO; the class itself simply needs to be instantiated, given a form/hwnd, and it does the rest; allowing the use of properties to control the minimum and maximum size of the form/window. I've used this mechanism extensively in a number of classes designed for various features, They generally implement a particular feature, such as, for example, handling combobox histories, or listview sorting messages, etc.
Of course newer languages (such as .NET) have most of these features built in, (namely, I speak of the ability to handle WndProc for nearly any hWnd) but such luxuries come at a price- the installation of the framework, which is not always quick, small, or always error-free.
I'm not sure about Python, But I do know that Perl was intentionally designed in a way dissimilar to most languages. Most languages make you think of your problem in terms of the language, Perl is designed to allow you to think of your problem and code your solution to the problem.
it's not about what language you use, it's about solving the problem. Wether a batch file, a python script, a perl script, VBScript, or even a batch file with VBS inside solves it is completely irrelevant.
-
Yet others will just love the way he put it all in one box.A large number of everyday real world coders often use hybrid methods.
in one box? what do you mean ? when you write a pure vbscript script, you are also putting them in one box right?
-
it's not about what language you use, it's about solving the problem. Wether a batch file, a python script, a perl script, VBScript, or even a batch file with VBS inside solves it is completely irrelevant.
That's not true. The language you use have a part to play as well. Yes, all of these you mention , including batch, are able to solve problems, but there are many ways to arrive at the solution to that problem, especially if its a complex one. With good language features, you arrive at the solution faster and with much ease than others. A good language helps the user(programmer/sysadmin etc) increase productivity(every where and anywhere)
-
Can have labels that start with a certain string
@echo off
:wscript.echo InputBox("Enter your name")
findstr "^:" "%~sf0" | findstr /i /v ":label" >temp.vbs & for /f "delims=" %%N in ('cscript //nologo temp.vbs') do set name=%%N & del temp.vbs
echo You entered %name%
:label1