How to pass values from script to external batch files

I've a batch file and a ps1 script

Test1.bat
powershell somescripts.ps1
robocopy c:\ d:\ <filename.txt>

Somescripts.ps1
$filename = "abc.txt"

After ps1 completes, i wish to pass the $filename abc.txt *outside* to
robocopy command . Note that abc.txt was created in c:\ drive

How do i do that ? Must i use process.start method in the script ?

On Nov 6, 2:53*am, "IT Staff" <jkk...@xxxxxx> wrote: Powershell doesn't have a chance to help you because the limiting
factor is Test1.bat.
CMD doesn't have functionality that lets you do what you want
directly.
I can think of 4 answers.
The simplest is to put 'robocopy c:\ d:\ <filename.txt>' in
somescripts.ps1.
The next simplest is to convert Test1.bat to PowerShell.
You could also run SomeScripts.ps1 outside Test1.bat and have it call
Test1.bat with your values as arguments.
If you really MUST use CMD the way you've described I can only think
of an ugly way.
Have somescripts.ps1 write the value to a file then use FOR /F in
your .bat to retrieve/use it.

Just a slightly more convenient procedure for the "ugly way":
Write an external temp.bat from ps1 containing
set filename=abc.txt
and add the statement
call temp.bat
to your test1.bat. This makes %filename% directly available in your
test1.bat environment

But as Rick already recommends: Better migrate the whole job to
somescripts.ps1 and do not mix ps1 and bat if they need to interact.

--
Gerd


"RickB" wrote:

I see, so it is better to put all batch statements into ps1 and have only
one script running ...



"Gerd Schneider" <GerdSchneider@xxxxxx> wrote in message
news:0DB8E844-7DD2-42A0-AB3C-05997D31DC66@xxxxxx

If you find some reason to break up a script into pieces there is
nothing intrinsically wrong with that. Just be sure the top most one
is PowerShell. IOW call a .bat from .ps1, not the other way around.

On Nov 6, 7:03*pm, "IT Staff" <jkk...@xxxxxx> wrote:

Good advice, but, imho, the limitation still exists that the called script
cannot easily pass information back to the calling script, regardless of
which is batch and which is powershell. Given that powershell encapsulates
just about every feature of batch (and then some) the best approach would be
to convert everything to powershell.

It's a bit different with a combination, for example, of batch and vbscript.
Although vbscript is much better than batch at some things (complex logic,
object programming, text parsing, etc.), it is often easier to code some
things in batch (or just leave existing code in batch), especially in the
area of file processing.


/Al

"RickB" <rbielaws@xxxxxx> wrote in message
news:77080eae-62d5-42d4-8aef-05c1dffe149e@xxxxxx
If you find some reason to break up a script into pieces there is
nothing intrinsically wrong with that. Just be sure the top most one
is PowerShell. IOW call a .bat from .ps1, not the other way around.

On Nov 6, 7:03 pm, "IT Staff" <jkk...@xxxxxx> wrote:

Good advice, but, imho, the limitation still exists that the called script
cannot easily pass information back to the calling script, regardless of
which is batch and which is powershell. Given that powershell encapsulates
just about every feature of batch (and then some) the best approach would be
to convert everything to powershell.

It's a bit different with a combination, for example, of batch and vbscript.
Although vbscript is much better than batch at some things (complex logic,
object programming, text parsing, etc.), it is often easier to code some
things in batch (or just leave existing code in batch), especially in the
area of file processing.


/Al

"RickB" <rbielaws@xxxxxx> wrote in message
news:77080eae-62d5-42d4-8aef-05c1dffe149e@xxxxxx
If you find some reason to break up a script into pieces there is
nothing intrinsically wrong with that. Just be sure the top most one
is PowerShell. IOW call a .bat from .ps1, not the other way around.

On Nov 6, 7:03 pm, "IT Staff" <jkk...@xxxxxx> wrote: