Opened 9 years ago

Closed 9 years ago

Last modified 44 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: Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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 (http://pugscode.org)

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.

Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
Limbic_Region_2000@Yahoo.com

Change History (4)

comment:1 Changed 9 years ago by simonpj

Logged In: YES 
user_id=50165

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 
itself.

Simon


comment:2 Changed 9 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.

Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
Limbic_Region_2000@Yahoo.com

comment:3 Changed 9 years ago by simonmar

Logged In: YES 
user_id=48280

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

comment:4 Changed 9 years ago by simonmar

  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.