Thanks a lot David and Ron,
I am aware of this way of bundling of multiple and running them by hard
linking, but my issue is bit different.
I have several script, one is master script and the others are called from
inside the master script.
one can imagine the structure as follows.
master.pl
-------------------
print "I am the master";
system ("perl a.pl");
system ("perl b.pl");
a.pl
------
print "I am the script a.pl";
b.pl
------
print "I am the script b.pl";
(For some reason, I can not put a.pl and b.pl as subrutine in the master.pl
.)
When I bundle them together using par-packer, i get master.pl, a.pl and b.pl
in the ./script folder. The resulting executable is master.exe as i need to
execute it externally. I want a.pl and b.pl should be able to run from
inside master.pl, which is not happening.
I tried the change the master.pl as follows:
master.pl
-------------------
print "I am the master";
system ("perl script/a.pl");
system ("perl script/b.pl");
This also does not do the job.
In each case, the error message is "perl scripts a.pl and b.pl not found."
Regards,
Bagdevi Mishra.
On Thu, Jul 24, 2014 at 6:54 PM, Ron W <[email protected]> wrote:
> On Thu, Jul 24, 2014 at 9:10 AM, David Mertens <[email protected]>
> wrote:
>
>> Bagdevi,
>>
>> If you rename the par-packed executable to "b.exe", then running it as
>> "b" should invoke the "b.pl" script. That is, the perl script that gets
>> invoked depends on the name of the executable itself. You can achieve the
>> same end on Unixen without renaming by using links; I am not sure if this
>> works on Windows, but I would be curious to know. :-)
>>
>
> I think the key is the value of what the *underlying* ARGV[0] (what Perl
> puts in$0) passed to the executable by exec.
>
> MS Windows Vista and newer support symbolic links like what "ln -s"
> creates on Linux/Unix/POSIX/etc. I don't know whether MS Windows' exec will
> put the supplied filename or the name of the file targeted by the symlink
> into the ARGV[0] it provides to the executable.
>
> As far as I know, even in the latest versions, MS Windows NTFS does not
> have "inodes" like Linux/Unix/etc use. Rather, it keeps that information in
> the directory for each file. As such, a "hard link" in MS Windows is not
> possible.
>
>
