* $Bill Luebkert <dbecoll@[...].net>  [2005:10:28:16:54:19-0700] scribed:
>  Michael D Schleif wrote:
>  > * $Bill Luebkert <dbecoll@[...].net> [2005:10:28:07:21:26-0700] scribed:
<snip /> 

>  > I have cut-pasted your exact code.  Please, recognize that my real code
>  > does use tests of this nature.

Please, take careful note of the above statement.

>  If your mkdir is failing in the Perl script, could there be a permissions
>  problem ?  You're using /'s instead of \'s like the above right ?

As you know, this is a very complex problem.

[A] When my Perl code _always_ uses forward-slashes, then the Perl mkdir
    *DOES* work; but, the BAT cannot use the directory path argument
    passed to it.

[B] So, _ALL_ I change is the forward-to-back slashes, and _ONLY_ for
    the directory path argument.  Then, the Perl mkdir does *NOTHING*,
    and the Perl mkdir does *NOT* croak nor die.  On top of that, the
    code continues on into the BAT code, whereupon the BAT cannot do its
    job, because its job is to copy files into the dir that was to be
    created by the Perl mkdir -- follow the sequence in the sample code.

Yes, this is bizarre behavior.  Yes, this should be a simple case of
swapping slashes.  Unfortunately, this is _not_ that simple ;<

>  > Also, please, notice the anomaly I tried to describe in my last post,
>  > regarding whether or not this directory actually gets created (see
>  > below.)
<snip /> 

>  >> system $cmd;		# seems OK
>  > 
>  > Again, I get the same results that I have always had at this point.
>  > Your code has not affected my results ;<
>  > 
>  >> # my @res = `$cmd`;	# also tried this OK
>  >> #print "res='@res'\n";
>  > 
>  > The reason that this is *not* an option is, I need to use the exit codes
>  > from the call to batch file.
>  
>  You still can get the return code from `` calls:
>  
>      $CHILD_ERROR
>      $?      The status returned by the last pipe close, backtick (``) command,
>              successful call to wait() or waitpid(), or from the system()
>              operator. This is just the 16-bit status word returned by the wait()
>              system call (or else is made up to look like it). Thus, the exit
>              value of the subprocess is really ("$? >> 8"), and "$? & 127" gives
>              which signal, if any, the process died from, and "$? & 128" reports
>              whether there was a core dump. (Mnemonic: similar to sh and ksh.)

O, I see -- somehow, I thought that I had gone this route before, and
this was not the case.

I will have to test this, rather than system().  The true test must wait
until Monday, when I have access to the systems on which this must run.

>  > Please, understand: Whenever I use back-slashes -- however many, however
>  > quoted do far -- this directory does *NOT* get created!  Nor does the
>  > Perl code die at the mkdir test ?!?!
>  
>  Then don't use back slashes.  I created the dir without them - look at
>  the mkdir's above.

Creating the directory with forward-slashes is *NOT* the problem.  Why
is this so hard for me to explain?

The problem is, the BAT will not accept the first argument (%1) as a
directory path when I use forward slashes.  So, I am forced to change
the back-slashes *ONLY* for this argument; and when I do that, then the
previous mkdir does *NOT* happen.

What part of this do you not understand?  How can I make this clearer
for you?

>  > Here are my two (2) basic problems:
>  > 
>  > [A] The called batch file will not accept a file path with
>  >     forward-slashes; and
>  
>  So reverse them just before the system call.

That is _exactly_ what I am doing.  Don't you see that in the sample
code?

>  > [B] When I pass the directory string _with_ back-slashes, the mkdir :
>  
>  I thought the dir was already made before passing the args to the bat file ?
>  
>  >     - does *NOT* create a directory;
>  
>  The mkdir (in the Perl code) should have already created the dir and it
>  works fine with slashes, so use them there.

Again, this *IS* the crux of the problem!

>  I'm not following you - be more explicit on where the mkdir is - Perl or bat ?

Do you see the mkdir in the Perl sample code I have published?

That is the one and only mkdir -- period.

>  >     - does *NOT* die nor croak any warning;
>  >     - function is passed and do_prog() *IS* called;

Did you really read what I wrote there?  Literally, that is what I mean.
No, it does not make sense; but, that *IS* what happens.

>  >     Of course, since the batch file concatenates $dir and $dest into a
>  >     directory path, into which it tries to copy many files, the batch
>  >     file *ALWAYS* fails, because there is *NO* directory into which
>  >     those files can be copied.
>  
>  If that's true, you should first concentrate on getting the mkdir in
>  the Perl script to work so it's there - before you deal with the bat file.
<snip /> 

I am not allowed to modify the BAT code.  What it does is take two (2)
arguments; and, after some other processing, the BAT code concatenates
the two arguments, like this:

    %1\%2

Whereupon, it copies a bunch of files to that path.

Trust me, I would not be going to this trouble, if I am allowed to
bypass the BAT.  I have already implemented all of the BAT functionality
in one Perl code set.  As previously stated, my client will not accept
this; so, I must use the BAT code, such as it is ...

>  > What do you think?
>  
>  I think you're doin something wrong.  ;)

Yes, it could be.  Please, notice, as I have already stated, I
cut-pasted the sample code that I was using, and published that intact
and complete.  I cut-pasted your sample code intact and complete.  My
empirical results are invariable throughout all trials using both code
sets.

What do you think?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know.  The more I know, the more I know I don't know . . .
--