spb54 has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks

This worked on Windows XP but is not working on Windows 7.

So, I have a file open in XMetaL and having edited, parsed and saved the file, I need to check internal links are ok. The script "check.pl" does this.

This is from my XMetal Macro:

sub CheckMarkup
{
    # document must be saved
    unless ($ActiveDocument->{Saved})
    {
        $Application->Alert("Document must be saved before checking");
        return;
    }

    # document must be valid
    unless ($ActiveDocument->{IsValid})
    {
        $Application->Alert("Document must be valid before checking (r
+un Validate)");
        return;
    }

    # get the path to this document
    my $path = $ActiveDocument->{FullName};

    # run the check script
    my $shell = Win32::OLE->new('WScript.Shell');
    unless ($shell)
    {
        $Application->Alert("Can't make WScript.Shell object");
        return;
    }

    $shell->Run("I:\\...\\check.bat \"$path\"", 5);
}

[download]

This is the content of the check.bat file:

perl -w I:\...\xml2sgm.pl %1

perl -w I:\...\check.pl %1

The check.bat file is being found ok, but %1 comes up empty.

It certainly appears Windows 7 is the culprit as nothing else has changed.

Incidentally I: is a mapped drive to our Unix server.

Can anyone help with this problem? Your collective wisdom would be most appreciated.

  • Comment on perl subroutine in XMetaL macro - $path not being passed to batch file on Windows 7
  • Download Code

Replies are listed 'Best First'.
Re: perl subroutine in XMetaL macro - $path not being passed to batch file on Windows 7
by BrowserUk (Patriarch) on Dec 15, 2014 at 03:47 UTC

    This isn't a Perl problem, or anything that can be fixed by Perl. The problem is well know and even effects calling Wscript from VisualBasic: Can't use Wscript.Shell when moved to Win7 x64

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Thanks for the reply. Yes, I'm aware it's not a Perl problem. The only change to my environment is the migration from WinXP 32bit to Win7 64bit.

      I believe it has to do with the Win32:OLE declaration.

      Does this invoke the 32bit or 64bit process? My research on this is confusing.

      If so, what is the correct call here?

[reply]

        Sorry, but I haven't got to Windows 7 yet, so I've not had to look for a solution to this. You'll need to look/ask elsewhere (try MS forums?).

        1. I do have to wonder why you have to use OLE to start wscript when you can do that directly from perl:
              system 'wscript arg1 arg2';

          [download]
        2. And why do you you need to use Wscript to run a batch file, when that can be done directly from Perl:
              system q[x:\path\to\thebatch.bat];

          [download]
        3. And why do you need to run a batch file in order to run perl.exe, when that can be done directly from Perl:
              system qq[$^X c:\\path\\to\\thePerlScript.pl arg1 arg2];

          [download]

        But I assumed that there must be very special circumstances for what you are doing because no one could arrive at that level of unnecessary indirection by accident.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom