I'm sure I'm not alone in thinking that there is likely to be a better
design for your goal than this. However, I will refrain from offering
suggestions until you ask. :-)
On Fri, Jul 25, 2014 at 1:55 AM, Bagdevi <bagdevi.mis...@gmail.com> wrote:
>
> 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 <ronw.m...@gmail.com> wrote:
>
>> On Thu, Jul 24, 2014 at 9:10 AM, David Mertens <dcmertens.p...@gmail.com>
>> 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.
>>
>>
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
