returning output from perl to batch variable; pass variable from perl

[poly4life]

Hello,

Is there a way I can pass the output of a Perl script to a batch file? I'm running a batch and I call a perl script from within that batch. Inside the Perl script, I set a variable. I want to capture said variable as output and and input it into a batch variable.

Not really pseudo code, just conceptual:

i..e
REM I'm in a batch file
SET Batch_Input_Var = Perl.exe Capture_Perl_Output.pl;

To put it another way (not any particular language):

Function Foo()
{
Output = 1;
return Output;
}

Input = Foo();
print Input; // 1

Thank you.

Edited March 29, 2011 by poly4life

[Yzöwl]

It suppose it depends on what the perl script is used for, if it is used only to output the variable then you may be able to run the perl script as a command within a FOR loop saving the IN output within the DO. You could also just output the perl created variable to a file and then read that back in with the batch file.

[allen2]

Mixing scripting langages often create strange behaviour so i would avoid that and use either perl or batch. In most cases, it would probably be easier to have a perl script to do all the work and it would also be faster.

[poly4life]

It suppose it depends on what the perl script is used for, if it is used only to output the variable then you may be able to run the perl script as a command within a FOR loop saving the IN output within the DO. You could also just output the perl created variable to a file and then read that back in with the batch file.

Well,they say one of perl's typical uses is "gluing" code together. But what I would say to use one or the other is these are my orders; I'm just the messenger. Could you please elaborate on your first suggestion?

Like this:

@echo off
FOR /F "delims=" %%I IN ('perl.exe -e "my $string='Hello World'; print STDOUT $string;"') DO set var=%%I
echo %var%

I tested it and it looks like it captures it--I'm thinking it's using batch's STDOUT stream or CONSOLE stream. In general, this would be useful for straight batch files, no? To have the ability to capture output from batch's STDOUT or CONSOLE stream by employing batch's STDIN stream. I tried that before using ">","<", and "|" characters but I had no luck.

Thank you.

[gunsmokingman]

Here is a cmd batch that gets it date varible back from a vbs file, sorry I do not know how to code in pearl

@Echo Off
CLS
Mode 55,9
Color F9
Title Demo Pass Varibles Cmd-Vbs-Cmd

Set VBS="%Temp%\Var.vbs"
Set Cmd1="%Temp%\Var.cmd"

Echo Dim T, T1, T2, T3 > %VBS% 
Echo Dim Act :Set Act = CreateObject("Wscript.Shell") >> %VBS% 
Echo Dim Fso :Set Fso = CreateObject("Scripting.FileSystemObject") >> %VBS% 
Echo T = Split(Date,"/") >> %VBS% 
Echo '/-> Check Month And Add A Zero If Less Then 10 >> %VBS% 
Echo  If Len(T(0)) = 1 Then :T1 = "0" ^& T(0) :Else : T1 = T(0) :End If >> %VBS% 
Echo '/-> Check Day Date And Add A Zero If Less Then 10 >> %VBS% 
Echo  If Len(T(1)) = 1 Then :T2 = "0" ^& T(1) :Else : T2 = T(1) :End If >> %VBS% 
Echo  Dim Cmd, Ts >> %VBS% 
Echo  Set Ts= Fso.CreateTextFile(%Cmd1%) >> %VBS% 
Echo  Ts.WriteLine "@Echo OFF" >> %VBS% 
Echo  Ts.WriteLine "Set Tme=" ^& T1 ^& "-" ^& T2 ^& "-" ^& T(2)>> %VBS% 
Echo  Ts.Close >> %VBS% 

:: Run The VBS To Build The Cmd Varibles To Be Passed Backed 
:: To The Original Cms Script 
%VBS% 
call %Cmd1%
:: Display The Time Varible
CLS
Echo.
Echo  %Tme%
Del %Cmd1%
Del %VBS%
pause

It would be alot more efficient if you where to use only one langauge, then mutiple langauges.

If you post what you are trying to accomplish, we may be able to help alot better.

[Yzöwl]

Like this:

@echo off
FOR /F "delims=" %%I IN ('perl.exe -e "my $string='Hello World'; print STDOUT $string;"') DO set var=%%I
echo %var%

I tested it and it looks like it captures it--I'm thinking it's using batch's STDOUT stream or CONSOLE stream. In general, this would be useful for straight batch files, no? To have the ability to capture output from batch's STDOUT or CONSOLE stream by employing batch's STDIN stream. I tried that before using ">","<", and "|" characters but I had no luck.

Thank you.

Just one thing to be wary of, there may be some characters in your command which could be mistaken by the batch file as pertinent to it (as opposed to the actual command). I'd suggest, at least in the case above, using:

FOR /F "USEBACKQ delims=" %%I IN (`perl.exe -e "my $string='Hello World'; print STDOUT $string;"`) DO set var=%%I

[CoffeeFiend]

I'm running a batch and I call a perl script from within that batch

Is there a reason why you must always somehow use more than one scripting language of some sort? It really seems to add pointless complexity (a hodge-podge of scripts trying to pass infos from one to another) with exactly *zero* added benefit. There's really nothing batch files can do that you can't accomplish with another language (and often in far better/modern ways), including perl.

In most cases, it would probably be easier to have a perl script to do all the work and it would also be faster.

^ What he said.

It would be alot more efficient if you where to use only one langauge, then mutiple langauges.

^ Ditto.

Well,they say one of perl's typical uses is "gluing" code together.

Well, I've never seen a "Windows shop" that actually uses perl for anything like that (then again, hardly anybody in the Windows-centric world uses perl at all). That's *much* more of a Linux thing, and then again it's more to "glue" the output from actual applications, mainly because the way of doing things in the Linux world is based on parsing text passed by a bunch of different tools (via piping) to accomplish a job, whereas in the "Windows world" when it comes to scripts we have object passing in powershell, or direct manipulation of most things using technologies like WMI, ADSI, COM, etc and that most tools simply aren't meant to work the same way. We don't tend to string together a bunch of tools to do a job but rather have a specialized tool meant for the one particular job instead. And even in the Linux world, you don't often write scripts that use a bunch more scripts (which all do completely trivial things) when you can typically have one small to medium script that just does the job.

Honestly, batch files are the last thing I'd be using these days (it's not 1985 anymore and the MS-DOS era is long gone -- I mean, we've had vbscript built-in for over a decade), and while perl isn't bad per se it's not exactly a common choice for Windows admins. The *only* place I've seen it used is guys writing VmPerl to admin vmware machines, but even then that was *heavily* outnumbered by folks using VmCOM (the COM based interface). It mainly seems to add a pointless dependency as it's not built-in, and also far less admins know perl. What you guys are doing (scripts that call scripts that call scripts) isn't so typical. It sounds like your boss is one of those "I only know Linux, so let's try to use everything as if it was Linux" guys (by using brute force and a bunch of ugly hacks). It looks like you're already having quite a bit of "fun" (mainly working against the tools, in ways that pretty much nobody else does), and judging by your posts I don't this is going to change anytime soon so good luck to you (I'm glad my boss doesn't impose such strange language constraints on me, it would feel kind of like juggling in a straight jacket)

It would be easy to help if we knew what the actual problem to solve is (we really try to help too -- I mean, like here where I've written 6 scripts in 5 different languages to do a particular job for one guy), but here it just seems like we're wasting time by trying to help you work in a very atypical, inefficient and perplexing way.

[poly4life]

I would LOVE to use just one tool to get the job done. But I am just the messenger. The powers that be want it in a batch file. It is crazy, but sometimes, as a coder, you have to hack things together to get the job done under these types of situations (working for others using strange premises). If this was for me and/or I was given more freedom and time, I would do things much differently.

The reason I brought up calling some other langauge, like perl, with these batches, is one of the tasks I am doing is reading in an excel file. vbs has support for excel, but I had already started using perl earlier in this task and it's too late for me to go back and rewrite perl code into vbs. Besides, the perl modules for manipulating excel files is pretty good and sufficient enough for reading it in. The excel file will essentially be treated like a flat database, (i.e. A1 correlates to B1, A2 correlates to B2, and so on, until EOF). There's some "garbage" data in the excel file I have to filter out, so it's not exactly 1-1 but that's not difficult). So, I'll loop through each cell mappings, line by line, and use those cell values to perform some other processing.

Again, if this was my choice, I'd use some other construct.

Edited March 30, 2011 by poly4life

[allen2]

If you're working with xls files, then you should use vba to create a macro that would do you need. Because perl will launch excel with OLE to process your files and it will be slower using perl or any other language and it will be a lot easier to maintain to have everything in excel.

Edited March 30, 2011 by allen2

[Yzöwl]

@ALL

Although I'm aware of your intent, an entire response tree of 'your requirements do not meet with how we'd do it' is starting to look more like an attack. It appears that poly4life received the information they needed in my first response and have stated that the tool choice isn't theirs so lets accept that and move on.

[CoffeeFiend]

vbs has support for excel, but I had already started using perl earlier in this task and it's too late for me to go back and rewrite perl code into vbs. Besides, the perl modules for manipulating excel files is pretty good and sufficient enough for reading it in

There's no need for a fancy module or library to do that. Any language that can use any old database can do it natively in a handful of lines, using the ACE OLEDB provider. MS Office doesn't have to be installed either, it just needs the related database driver which is free.

Personally, I do this kinda stuff in C#. LINQ -- and its extension methods along with lambda expressions, anonymous methods and other bits functional programming-styled (declarative, somewhat MapReduce-like) code -- makes processing the contents at least 10x faster than using almost everything else in most cases.