Re: B.20.1 bash question - paths sent to #!

["Soren Andersen" <soren dot andersen at mindspring dot com>]

On 1 Feb 00, an entity purporting to be Al and Patricia [Al and Patricia 
<carat@earthlink.net>] wrote [regarding B.20.1 bash question - paths sent 
to #!]  

> I looked in the archives and did not see a solution to this issue:
> 
> I have 3 drives on my NT 4.0 system: C: D: E:.
> I have a perl script that has "#!/usr/bin/perl" in it.
> I am trying to put the perl script in my path, so that I can run it from
> any drive. I am using ActiveState Perl.

First of all, its been suggested that you had best install another Perl 
(Cygwin-built Perl) and only use it from Cygwin. That's not a bad 
suggestion, but I can easily imagine circumstances and preferences in which 
someone wouldn't want to do this. I myself have installed that Cygwin Perl 
and its fine but it is core Perl without many, many "goodies" that 
ActiveState installs for you (I am installing mods for it a bit at a time).  

> Here is the situation.  First, my perl script is called "pop3", and it
> resides in /e/perl/bin.  If I put /e/perl/bin in my path, then I believe
> that bash calls /usr/bin/perl with the file name as /e/perl/bin/pop3.
> However, AS Perl can't interpret this file name and gives a "file not
> found" error.
> 
> I tried putting /perl/bin/ in my path, and this works, as long as I am
> "on" the e drive.  When I go to another drive, /perl/bin does not exist,
> and calling pop3 fails again.
> 
> So what I'd like is to have bash convert the Posix path of the called
> script to win32 when using the #! syntax, so that AS Perl (and other
> interpreters) will have a path it can work with.  Is there a workaround?

There's no standard workaround for path problems that i know of. This 
general issue thus becomes the occasion for my first posting to this List.

Basically you can see the same thing happen if it isn't invoking Perl that you 
are trying to do, but let's say "just" invoking humble Windoze Explorer. Try 
this:
  explore.exe /E, /usr/bin
and you'll get either an unpredictable result or an error message from 
Windows telling you that there is no valid directory to explore at "/usr/bin" 
or something. The bash shell and the Cygwin innards and the Windows 
command interpretor don't all play together nicely; they speak different 
lingos. You (all) know this already.

I have a workaround. Its not pretty, maybe, but it address some long-
standing problems i have been having with shells (especially Cygwin bash) 
and Windows. This fix might be adaptable to other shells but right now i 
only guarantee that it works in bash (Cygwin b-20) and only if you either 
have an env var HOMEDRIVE set correctly (I think it was defined by 
default -- in WinNT ONLY -- upon OS installation: look in START | 
SETTINGS | CONTROL PANEL| SYSTEM | ENVIRONMENT) *or* you 
hand-edit the root drive variable $RootDrv (which on my setup is D:  
whereas on some other people's would be C:  or anything else).


ex()    {
	local RootDrv="$HOMEDRIVE"'/'
local DSpec=`echo "$1" | sed s=^/== | sed s=^'\([a-zA-Z]\)''\/'='\1:'/= `
	if [ ! $( echo "$DSpec" | grep --regexp=^[A-Za-z]':/' ) ]; then
		DSpec="$RootDrv""$DSpec"
	fi
	DSpec=$(echo $DSpec | sed s+/+'\\'+g)
	command Explorer /e,/root,$DSpec
}

Put this function in your .bashrc file (watch out for emailer line-wrapping 
messup of course)  and login to bash. It should Do The Right Thing (it opens 
an Explorer window with the specified Win-style path as the "ceiling", to get 
a normal navigatible two-pane Explorer just omit the ",/root," part).

Now, to fix things for ActivePerl:


px()    {
	local RootDrv="$HOMEDRIVE"'/'
local DSpec=`echo "$1" | sed s=^/== | sed s=^'\([a-zA-Z]\)''\/'='\1:'/= `
	if [ ! $( echo "$DSpec" | grep --regexp=^[A-Za-z]':/' ) ]; then
		DSpec="$RootDrv""$DSpec"
	fi
	DSpec=$(echo $DSpec | sed s+/+'\\'+g)
	command perl $DSpec
}

If I enter this, for instance:
  px /e/scr/test_path.p
I get the right result (the script, which actually exists on my system, is run 
by Perl).

The key is that sed is nearly completely *broken* in its Cygwin incarnation. 
The quoting gymnastics are required and represent hours of trial and error 
to arrive at the empirical results demonstrated above (so I would 
recommend that the traditional 'flame the List newbie' flames be withheld 
or directed to /dev/null) ...

  HTH,
      soren andersen


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com