Opened 12 years ago

Closed 12 years ago

Last modified 48 years ago

#417 closed bug (Fixed)

Hardcoded path to perl.exe

Reported by: nobody Owned by: nobody
Priority: normal Milestone:
Component: None Version: 6.4
Keywords: Cc:
Operating System: Architecture:
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I apologize in advance for not selecting a proper
category but as I am an extreme neophyte - I didn't
know what to select.

I use GHC primarily to build Pugs (

I got frustrated that on Win32, the current working
directory supercedes the %PATH variable and the
perl.exe in the GHC root directory was getting used
instead of my freshly installed 5.8.7

I deleted the file and corresponding perl56.dll and
everything appeared to be working fine and yet Pugs
would fail to build spitting out a cryptic 0x01 error
(not exactly sure what the code was but it wasn't helpful).

Since I had deleted the files instead of renaming them
(hindsight always being 20/20) and not wanting to
install GHC all over again just to see if for some
strange reason that was the problem - I copied over the
perl.exe and perl58.dll and what do you know - it worked.

My bug report then is this - if there is some valid
reason to hardcode a path to the GHC root directory for
perl instead of looking in %PATH as a backup plan -
then please make any error message more descriptive.

Note:  Not being very familiar with GHC, it might be
that the error message was very informative and that it
is the Pugs build process fault for not carrying it
over.  If that is the case then please disregard and
please forgive.

Joshua Gatcomb
a.k.a. Limbic~Region

Change History (4)

comment:1 Changed 12 years ago by simonpj

Logged In: YES 

Can you explain why this is a problem for you? 

We consider it a feature, not a bug, that GHC invokes its own 
private copy of perl when GHC runs its own private perl 
scripts (actually, I think the only perl script is the Evil 
Mangler).  That way we aren't exposed to version skew in 
perl, nor do we require users to even have perl installed.

Why does it cause a problem for you?  Perhaps GHC's perl 
doesn't run on your box.  But I wonder why not.... The only 
script it's being asked to run is the one that comes with GHC 


comment:2 Changed 12 years ago by nobody

Logged In: NO 

I need to apologize again.  As a non-registered user, I
suspect my reply will be posted under the root thread
instead of simonpj

It is a problem for a handful of reasons.

1.  When I in the GHC root directory, that version takes
precedence over any system installed perl.  In addition to
being a different version, it does not have access to all
the modules installed in the system perl's @INC

2.  The error message that the executable is missing in no
way tells me that is what the problem is.  As I indicated
previously, it may be that the Pugs build process just
wasn't passing on the information correctly - but I don't
suspect this is the case.

3.  I am not saying that GHC should not include its own copy
of the perl executable for many of the same reasons you
indicated.  I am saying that it would be more user friendly
if it looked in %PATH if it wasn't found in the hard coded
path as backup.  Alternatively, renaming it.

As a command line biggot, this is primarily only a problem
on Win32 as the current directory takes precedence over the
PATH environment variable.  Making this more user friendly
can, in my neophyte opinion, be done without a negative
impact to GHC's goals.

Joshua Gatcomb
a.k.a. Limbic~Region

comment:3 Changed 12 years ago by simonmar

Logged In: YES 

The error message for a missing Perl is improved in later
GHCs, and we're considering renaming some of GHC's private

comment:4 Changed 12 years ago by simonmar

Status: assignedclosed
Note: See TracTickets for help on using tickets.