RE: "The PATH problem"

RE: "The PATH problem"

[Schaible, Joerg]

Hi Soren,

>Cygwin doesn't allow modification or unset on the PATH variable after 
>login, so it has to be set right from 'Doze before bash gets fired up, no? 

Who has told you that? This is simply not true, but it depends on the shell
you're using.

sh (or ash):

PATH=/usr/local/bin:/bin
export PATH


bash or korn shell (ksh):

export PATH=/usr/local/bin:/bin


c shell (csh) and derivates (tcsh):

set path=(/usr/local/bin /bin)



Jorg

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: "The PATH problem"

[Soren Andersen]

On 12 Jan 2001, an entity purporting to be Schaible, Joerg [Schaible, Joerg 
<Joerg.Schaible@gft.com>] wrote [regarding RE: "The PATH problem"]  

> Hi Soren,
> 
> >Cygwin doesn't allow modification or unset on the PATH variable after 
> >login, so it has to be set right from 'Doze before bash gets fired up, no? 
> 
> Who has told you that? This is simply not true, but it depends on the shell
> you're using.

I am *quite* sure I just read it in documentation, but I am sorry, I have 
been multitasking at least a half-dozen projects for days now, and I do not 
have a pointer to cite to the location of this statement.

I exhaustively tried to alter my PATH inside bash (using statements 
identical to what you cited) before I found the documentary confirmation 
that it doesn't work.

   "YMMV".

   regards,
     soren andersen

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Earnie Boyd]

Soren Andersen wrote:
> 
> On 12 Jan 2001, an entity purporting to be Schaible, Joerg [Schaible, Joerg
> <Joerg.Schaible@gft.com>] wrote [regarding RE: "The PATH problem"]
> 
> > Hi Soren,
> >
> > >Cygwin doesn't allow modification or unset on the PATH variable after
> > >login, so it has to be set right from 'Doze before bash gets fired up, no?
> >
> > Who has told you that? This is simply not true, but it depends on the shell
> > you're using.
> 
> I am *quite* sure I just read it in documentation, but I am sorry, I have
> been multitasking at least a half-dozen projects for days now, and I do not
> have a pointer to cite to the location of this statement.
> 
> I exhaustively tried to alter my PATH inside bash (using statements
> identical to what you cited) before I found the documentary confirmation
> that it doesn't work.
> 
>    "YMMV".
> 

YMMV???  Joerg is correct.  This is an impartial nature of the shell,
all shells, including command.com and cmd.exe.  I don't think that your
systems are a special case, but YMMV.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Christopher Faylor]

On Fri, Jan 12, 2001 at 09:33:06AM -0500, Earnie Boyd wrote:
>Soren Andersen wrote:
>> 
>> On 12 Jan 2001, an entity purporting to be Schaible, Joerg [Schaible, Joerg
>> <Joerg.Schaible@gft.com>] wrote [regarding RE: "The PATH problem"]
>> 
>> > Hi Soren,
>> >
>> > >Cygwin doesn't allow modification or unset on the PATH variable after
>> > >login, so it has to be set right from 'Doze before bash gets fired up, no?
>> >
>> > Who has told you that? This is simply not true, but it depends on the shell
>> > you're using.
>> 
>> I am *quite* sure I just read it in documentation, but I am sorry, I have
>> been multitasking at least a half-dozen projects for days now, and I do not
>> have a pointer to cite to the location of this statement.
>> 
>> I exhaustively tried to alter my PATH inside bash (using statements
>> identical to what you cited) before I found the documentary confirmation
>> that it doesn't work.
>> 
>>    "YMMV".
>> 
>
>YMMV???  Joerg is correct.  This is an impartial nature of the shell,
>all shells, including command.com and cmd.exe.  I don't think that your
>systems are a special case, but YMMV.

Right.  There is *no* documentation which says that setting your PATH
inside of bash doesn't work.  This is simply not true.

What kind of UNIX emulation would Cygwin be if you couldn't modify your
PATH???

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Larry Hall (RFK Partners, Inc)]

At 09:50 AM 1/12/2001, Christopher Faylor wrote:
>What kind of UNIX emulation would Cygwin be if you couldn't modify your
>PATH???


This is clearly a rhetorical question but in case anyone isn't sure, the 
answer to the question is "a bad one", which Cygwin certainly is NOT.

(...now back to modifying my path from bash...;-))


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Christopher Faylor]

On Fri, Jan 12, 2001 at 10:31:13AM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 09:50 AM 1/12/2001, Christopher Faylor wrote:
>>What kind of UNIX emulation would Cygwin be if you couldn't modify your
>>PATH???
>
>
>This is clearly a rhetorical question but in case anyone isn't sure, the 
>answer to the question is "a bad one", which Cygwin certainly is NOT.
>
>(...now back to modifying my path from bash...;-))

Phew.  I wasn't sure.  Thanks for clarifying this issue.  :-)

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Vladimir G Ivanovic]

Could you be confusing setting PATH with setting CYGWIN? A subsequent
message to this email list mentions that CYGWIN must be set before
cygwin1.dll is loaded.

---Vladimir

Vladimir G. Ivanovic                    http://www.leonora.org/~vladimir
2770 Cowper St.                                         vladimir@acm.org
Palo Alto, CA 94306-2447                                 +1 650 678 8014

"EB" == Earnie Boyd <earnie_boyd@yahoo.com> writes:

  EB> Soren Andersen wrote:
  >>
  >> On 12 Jan 2001, an entity purporting to be Schaible, Joerg
  >> [Schaible, Joerg <Joerg.Schaible@gft.com>] wrote [regarding RE:
  >> "The PATH problem"]
  >>
  >> > Hi Soren,
  >> >
  >> > >Cygwin doesn't allow modification or unset on the PATH variable
  >> > >after login, so it has to be set right from 'Doze before bash
  >> > >gets fired up, no?
  >> >
  >> > Who has told you that? This is simply not true, but it depends on
  >> > the shell you're using.
  >>
  >> I am *quite* sure I just read it in documentation, but I am sorry,
  >> I have been multitasking at least a half-dozen projects for days
  >> now, and I do not have a pointer to cite to the location of this
  >> statement.
  >>
  >> I exhaustively tried to alter my PATH inside bash (using statements
  >> identical to what you cited) before I found the documentary
  >> confirmation that it doesn't work.
  >>
  >> "YMMV".
  >>

  EB> YMMV??? Joerg is correct. This is an impartial nature of the
  EB> shell, all shells, including command.com and cmd.exe. I don't
  EB> think that your systems are a special case, but YMMV.

  EB> Cheers, Earnie.

  EB> __________________________________________________ Do You Yahoo!?
  EB> Talk to your friends online with Yahoo! Messenger.
  EB> http://im.yahoo.com

  EB> -- Want to unsubscribe from this list? Check out:
  EB> http://cygwin.com/ml/#unsubscribe-simple


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Christopher Faylor]

On Fri, Jan 12, 2001 at 10:02:38AM -0800, Vladimir G Ivanovic wrote:
>Could you be confusing setting PATH with setting CYGWIN? A subsequent
>message to this email list mentions that CYGWIN must be set before
>cygwin1.dll is loaded.

Probably.  For a while I generalized the proviso against setting CYGWIN in
a bash shell to mean that *no* commands would work at all unless I typed
them prior to running bash.  This seemed sort of silly and I almost
complained bitterly to the cygwin mailing list.

I spent many a long lonely night looking at the bash prompt and
wondering how I could get any work done, finally rebooting my machine so
that I could at least get back the Windows command window.  It finally
occurred to me that I should just try typing something to see if it
worked.

It did work, of course.  bash accepted commands just fine.  I guess that
makes sense in retrospect...

But now I'm really confused since the CYGWIN problem still seems to
be there.  I type CYGWIN at the command prompt and it says:

bash: CYGWIN: command not found

Go figure.

cgf

>"EB" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>
>  EB> Soren Andersen wrote:
>  >>
>  >> On 12 Jan 2001, an entity purporting to be Schaible, Joerg
>  >> [Schaible, Joerg <Joerg.Schaible@gft.com>] wrote [regarding RE:
>  >> "The PATH problem"]
>  >>
>  >> > Hi Soren,
>  >> >
>  >> > >Cygwin doesn't allow modification or unset on the PATH variable
>  >> > >after login, so it has to be set right from 'Doze before bash
>  >> > >gets fired up, no?
>  >> >
>  >> > Who has told you that? This is simply not true, but it depends on
>  >> > the shell you're using.
>  >>
>  >> I am *quite* sure I just read it in documentation, but I am sorry,
>  >> I have been multitasking at least a half-dozen projects for days
>  >> now, and I do not have a pointer to cite to the location of this
>  >> statement.
>  >>
>  >> I exhaustively tried to alter my PATH inside bash (using statements
>  >> identical to what you cited) before I found the documentary
>  >> confirmation that it doesn't work.
>  >>
>  >> "YMMV".
>  >>
>
>  EB> YMMV??? Joerg is correct. This is an impartial nature of the
>  EB> shell, all shells, including command.com and cmd.exe. I don't
>  EB> think that your systems are a special case, but YMMV.
>
>  EB> Cheers, Earnie.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Larry Hall (RFK Partners, Inc)]

At 02:02 PM 1/12/2001, you wrote:
>On Fri, Jan 12, 2001 at 10:02:38AM -0800, Vladimir G Ivanovic wrote:
> >Could you be confusing setting PATH with setting CYGWIN? A subsequent
> >message to this email list mentions that CYGWIN must be set before
> >cygwin1.dll is loaded.
>
>Probably.  For a while I generalized the proviso against setting CYGWIN in
>a bash shell to mean that *no* commands would work at all unless I typed
>them prior to running bash.  This seemed sort of silly and I almost
>complained bitterly to the cygwin mailing list.
>
>I spent many a long lonely night looking at the bash prompt and
>wondering how I could get any work done, finally rebooting my machine so
>that I could at least get back the Windows command window.  It finally
>occurred to me that I should just try typing something to see if it
>worked.
>
>It did work, of course.  bash accepted commands just fine.  I guess that
>makes sense in retrospect...
>
>But now I'm really confused since the CYGWIN problem still seems to
>be there.  I type CYGWIN at the command prompt and it says:
>
>bash: CYGWIN: command not found
>
>Go figure.
>
>cgf


Hm, this really frightens me.  I think I'm going to put Cygwin away for a
while and go play with my other toys...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[DJ Delorie]

> Hm, this really frightens me.

We'll be taking a collection later for Chris's long overdue (and much
deserved) vacation ;-)

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Larry Hall (RFK Partners, Inc)]

At 03:02 PM 1/12/2001, DJ Delorie wrote:

> > Hm, this really frightens me.
>
>We'll be taking a collection later for Chris's long overdue (and much
>deserved) vacation ;-)



I'll chip in the profits from all the programs I've sold based on Cygwin....
Oops!  I guess I shouldn't have said that.  Now the GNU police will be
looking for me!;-)



Larry



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[DJ Delorie]

> I'll chip in the profits from all the programs I've sold based on Cygwin....
> Oops!  I guess I shouldn't have said that.  Now the GNU police will be
> looking for me!;-)

Jokes aside, there's no problem if you profit from selling
cygwin-based programs (or even cygwin itself).  GNU only cares that
the programs are modifiable and redistributable, not zero cost.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Larry Hall (RFK Partners, Inc)]

At 05:05 PM 1/12/2001, DJ Delorie wrote:

> > I'll chip in the profits from all the programs I've sold based on Cygwin....
> > Oops!  I guess I shouldn't have said that.  Now the GNU police will be
> > looking for me!;-)
>
>Jokes aside, there's no problem if you profit from selling
>cygwin-based programs (or even cygwin itself).  GNU only cares that
>the programs are modifiable and redistributable, not zero cost.


Yes. I want to thank DJ for pointing this out, since I was taking some 
liberties with the notion of the GNU GPL license.  DJ has proven time and 
again that he has a deep understanding of the GNU license and has been able 
to put to rest more than one long debate on this list about its function
(merits, benefits, validity, etc are still subjects that show up here now
and again as debate topics though!;-))  I, for one, am glad to have 
someone so well equipped in this area on this list.  For anyone not sure,
I do understand that the GNU GPL doesn't prohibit the sale of GNU GPL'd
software.  Also, I don't intend for this thread to open up some discussion
on the GPL.  Finally, I'd like to add that while I think it would be great
if we took up a collection so we could send Chris on a vacation (the original
comment that elicited my response), I haven't actually sold any software,
GNU GPL or otherwise, so I won't be able to contribute the profits to this
endeavor.  Sorry Chris!;-) 



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: "The PATH problem"

[Christopher Faylor]

On Fri, Jan 12, 2001 at 05:20:23PM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 05:05 PM 1/12/2001, DJ Delorie wrote:
>
>> > I'll chip in the profits from all the programs I've sold based on Cygwin....
>> > Oops!  I guess I shouldn't have said that.  Now the GNU police will be
>> > looking for me!;-)
>>
>>Jokes aside, there's no problem if you profit from selling
>>cygwin-based programs (or even cygwin itself).  GNU only cares that
>>the programs are modifiable and redistributable, not zero cost.
>
>
>Yes. I want to thank DJ for pointing this out, since I was taking some 
>liberties with the notion of the GNU GPL license.  DJ has proven time and 
>again that he has a deep understanding of the GNU license and has been able 
>to put to rest more than one long debate on this list about its function
>(merits, benefits, validity, etc are still subjects that show up here now
>and again as debate topics though!;-))  I, for one, am glad to have 
>someone so well equipped in this area on this list.  For anyone not sure,
>I do understand that the GNU GPL doesn't prohibit the sale of GNU GPL'd
>software.  Also, I don't intend for this thread to open up some discussion
>on the GPL.  Finally, I'd like to add that while I think it would be great
>if we took up a collection so we could send Chris on a vacation (the original
>comment that elicited my response), I haven't actually sold any software,
>GNU GPL or otherwise, so I won't be able to contribute the profits to this
>endeavor.  Sorry Chris!;-) 

That's ok.  Recent versions of the Cygwin license have a "If you use
this software you must send 5% of all of your profits to Chris Faylor",
so I should be covered.

I think that this change complies with the spirit of the GPL or at least I
really want it to do so, which is much the same thing.

I haven't seen any checks yet, but I've been monitoring my mailbox constantly
and I'm sure they'll arrive soon.

cgf
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
;-)

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

"The PATH problem"

[Soren Andersen]

[-- Attachment #1: Type: text/plain, Size: 7601 bytes --]

Hello,

Its interesting that Ehud Karni posted a shell script for mount tables and a 
request came in for suggestions about 'pushing Cygwin out' to many 
machines. I have been thinking a bit about Cygwin setup since I installed 
freshly three time over the year-end season, and each time the 
configuration I wanted to end up with was somewhat different. I learned a 
little more about Cygwin (still have a L O N G way to go).

logins are a funny thing -- users seem very specific and individualistic about 
that and everybody seems to have a slightly different preference. So my 
offering today might not be of much interest to the older users on this List, 
who long since made up their own minds how to do what they like on login. 
But newer users like I am might stumble across this message and I might 
even be so bold as to propose that my contribution be made known and 
available to them somehow.

As I see it the "PATH" problem is this: many people who use Cygwin are 
developers and developers, more than ordinary users (is such a thing?) 
often maintain multiple build environments (MinGW, Cygwin-DLL-based, 
etc), add new tools, and may do all sorts of frequent changes. In order to 
make such things easier there are diferent ways to go, I suppose. One could 
umount and then re-mount to different points everything that one needs, 
so that all the PATH-dependent processes unleashed by the hacker in a 
typical working session find the right places. Another way is to re-adjust the 
PATH list to point towards what one needs, precedence of course being of 
the essence especially where there are multiple versions of executables 
located in different branches on the filesystem.

Cygwin doesn't allow modification or unset on the PATH variable after 
login, so it has to be set right from 'Doze before bash gets fired up, no? This 
reality led me to concoct a little script to make setting up the PATH and 
guaranteeing no unpleasant surprises a bit easier. Rather than repeatedly 
typing in the needed SET commands every time before entering bash, I 
have Perl do it (such a thing could probably be done another way using a 
shell script but I am a Perl hacker .. not a `sed' wiz).

My script has a lot of points that one could single out and find a shortcoming 
or debatable. I just offer it, I don't claim it's elegant or perfect.

One such point is that some may want there not to be a dependency on a 
special Perl module that isn't part of standard core Perl and may need to be 
installed via CPAN before this will work. That module is "Tie::IxHash" (G. 
Sarathy, author) which allows one to employ the freak hybrid critter of a 
Perl "order [precedence]-retaining hash" (a tie-ed 'IxHash') in one's 
program. OTOH it's a simple install (no xs DLLs, simply copying the .pm file 
to the right location will suffice in a pinch). I have decided to simply attach 
the module to this message.

(PERL THEORY)This (use of such a module) is most desirable because the 
use of a hash is a means of cleanly eliminating duplicate entries without 
complex looping in one's script. At the same time, it is very good to be able 
to preserve the order of the entries in $PATH so that precedence works in 
one's favor.(/PERL THEORY)

Using this script one can "hard-code" paths which one needs to absolutely 
be present first in the PATH, followed by paths that already exist in there 
(like Windows/system[32]) and need to be retained -- but with no 
duplication.

Another point which might irritate the picky user is that a short but 
perceptible (on my system, maybe 1.5 sec) delay in accomplishing login is 
introduced.

The script prints out to STDOUT a list of the resulting {Windows-style} 
paths (and a user could want it to do more: to make a table showing both 
the styles corresponding, that's maybe a TO-DO) and writes to a ".file.bat" 
file (so named from the convention that a file beginning with a dot is a 
system configuration file that is written to/read from by processes and 
should be hidden most of the time) to accomplish the little trick of changing 
the PATH from inside a process that then ends (Perl beginner FAQ: there is 
no way [short of such hackery] to change the PATH from inside Perl so that 
it remains changed after program exit ...).

In order to do this, this requires TWO scripts, not a single file: 1 .BAT script 
which calls the perl and then reads-in the .file.bat after perl exists.

Script one ("cygwin.bat") follows:

-----  script  ----  watch for wrapping and low-flying owls ---
@ECHO OFF
D:\usr\local\bin\perl5.00503.exe D:\Cygwin\setpath.p

REM the next line sets the path from the file just written
REM by the Perl script above.
CALL D:\usr\.pathfix.bat
D:
SET CYGWIN=binmode tty ntea nontsec
@ECHO ON
\Cygwin\bin\bash --login -i

---- end script ----- cut here ---- use no hooks ----




Script two, the Perl script, follows:

---- start script -- watch for wrapping -----
#!D:\usr\local\bin\perl5.00503.exe -w  # <-- user configuration

# Perl script "setpath.p"
# Copyright (c)2001 Soren Andersen <libertador@flashmail.com>
# This is Free Software, it may be freely redistributed, modified,
# and copied, but this notice must be retained. NO warrantee,
# express or implied, is given; and the user assumes all risk from
# the use of this program.

use Tie::IxHash;

my ($HW, %Pash, $Pct, $Psep, @getP);
  $HW = 'hardwired';  $Pct = 1;
chdir 'D:\\Cygwin'; # User conguration here and next several lines
my $ixH = tie( %Pash, Tie::IxHash,
    	 q[D:\\Cygwin\\usr\\i686-pc-cygwin\\bin] => "$HW ". $Pct++,
		 q[D:\\usr\\local\\bin] => "$HW ". $Pct++,
		 q[D:\\Cygwin\\bin] => "$HW ". $Pct++,
          );
die qq[\nFailure to tie IxHash: $!] unless $ixH;
 if ($] =~m@5\.00503@i or $ENV{SHELL} =~m@/bin/sh/@)    {
      $Psep = ':';
      @getP = map {my $wP = `bin/cygpath -paw $_`; $wP;}
                             split $Psep, qx'echo $PATH';
 } else {
      $Psep = ';';
      @getP = split $Psep, $ENV{PATH};
 }
 for(@getP) {
      chomp $_;
      next if m@^\.$@;  # Cygwin adds dot '.' to end anyway, don't duplicate.
      $_ = ucfirst($_);
	  next if m@D:\\ActivePerl\\bin\Z@i;  # user configuration req'd (*see bottom)
	  $Pash{$_} = $Pct++ unless not -d $_ or exists $Pash{$_};
 }
 print STDERR qq[\n\n],'_' x 16,'  PATH VARIABLE  ' ,'_' x 16, qq[\n\n];

 open( BATF,q[> D:\\usr\\.pathfix.bat] ) or die $!;  # user configuration req'd
 
 print BATF qq[REM this file is generated automatically ],
            qq[each time Cygwin.bat is run\nSET PATH=];

 for (keys %Pash)   {
        if ($Pash{$_} =~m@^\d+$@) {
           printf STDERR "%2u", $Pash{$_};
        } else {
           printf STDERR "%s", $Pash{$_};
        }
        printf STDERR "%s", qq[ ~ $_\n];
		print BATF $_ , q[;];
 }
 print STDERR qq=The PATH has been adjusted for Cygwin use.\n=;
 close(BATF);

__END__


Notes:

I think this script is mostly self-explanatory and anyway I am
too busy to write proper pod right now ;-). But a note about *:
  The system setup I have is one in which several different
  versions of Perl are present, and I usually have one (the
  ActivePerl port) in use in my general 'Doze environment. But
  I need to remove it so that my Cygwin Perl is found instead, so
  the configuration of this script on MY system requires the use
  of the regex to remove such a PATH item. Similarly, other users
  (assuming adequate proficiency with perl regex's) could use the
  marked section to 'filter out' any undesirable PATH entries
  (as opposed to leaving them in but at low precedence).


---- end script ---- cut here ---- use no hooks -----

[-- Attachment #2: IxHash.pm --]
[-- Type: text/plain, Size: 13919 bytes --]

#
# Tie/IxHash.pm
#
# Indexed hash implementation for Perl
#
# See below for documentation.
#

require 5.003;

package Tie::IxHash;
use integer;
require Tie::Hash;
@ISA = qw(Tie::Hash);

$VERSION = $VERSION = '1.21';

#
# standard tie functions
#

sub TIEHASH {
  my($c) = shift;
  my($s) = [];
  $s->[0] = {};   # hashkey index
  $s->[1] = [];   # array of keys
  $s->[2] = [];   # array of data
  $s->[3] = 0;    # iter count

  bless $s, $c;

  $s->Push(@_) if @_;

  return $s;
}

#sub DESTROY {}           # costly if there's nothing to do

sub FETCH {
  my($s, $k) = (shift, shift);
  return exists( $s->[0]{$k} ) ? $s->[2][ $s->[0]{$k} ] : undef;
}

sub STORE {
  my($s, $k, $v) = (shift, shift, shift);
  
  if (exists $s->[0]{$k}) {
    my($i) = $s->[0]{$k};
    $s->[1][$i] = $k;
    $s->[2][$i] = $v;
    $s->[0]{$k} = $i;
  }
  else {
    push(@{$s->[1]}, $k);
    push(@{$s->[2]}, $v);
    $s->[0]{$k} = $#{$s->[1]};
  }
}

sub DELETE {
  my($s, $k) = (shift, shift);

  if (exists $s->[0]{$k}) {
    my($i) = $s->[0]{$k};
    for ($i+1..$#{$s->[1]}) {    # reset higher elt indexes
      $s->[0]{$s->[1][$_]}--;    # timeconsuming, is there is better way?
    }
    delete $s->[0]{$k};
    splice @{$s->[1]}, $i, 1;
    return (splice(@{$s->[2]}, $i, 1))[0];
  }
  return undef;
}

sub EXISTS {
  exists $_[0]->[0]{ $_[1] };
}

sub FIRSTKEY {
  $_[0][3] = 0;
  &NEXTKEY;
}

sub NEXTKEY {
  return $_[0][1][$_[0][3]++] if ($_[0][3] <= $#{$_[0][1]});
  return undef;
}



#
#
# class functions that provide additional capabilities
#
#

sub new { TIEHASH(@_) }

#
# add pairs to end of indexed hash
# note that if a supplied key exists, it will not be reordered
#
sub Push {
  my($s) = shift;
  while (@_) {
    $s->STORE(shift, shift);
  }
  return scalar(@{$s->[1]});
}

sub Push2 {
  my($s) = shift;
  $s->Splice($#{$s->[1]}+1, 0, @_);
  return scalar(@{$s->[1]});
}

#
# pop last k-v pair
#
sub Pop {
  my($s) = shift;
  my($k, $v, $i);
  $k = pop(@{$s->[1]});
  $v = pop(@{$s->[2]});
  if (defined $k) {
    delete $s->[0]{$k};
    return ($k, $v);
  }
  return undef;
}

sub Pop2 {
  return $_[0]->Splice(-1);
}

#
# shift
#
sub Shift {
  my($s) = shift;
  my($k, $v, $i);
  $k = shift(@{$s->[1]});
  $v = shift(@{$s->[2]});
  if (defined $k) {
    delete $s->[0]{$k};
    for (keys %{$s->[0]}) {
      $s->[0]{$_}--;
    }
    return ($k, $v);
  }
  return undef;
}

sub Shift2 {
  return $_[0]->Splice(0, 1);
}

#
# unshift
# if a supplied key exists, it will not be reordered
#
sub Unshift {
  my($s) = shift;
  my($k, $v, @k, @v, $len, $i);

  while (@_) {
    ($k, $v) = (shift, shift);
    if (exists $s->[0]{$k}) {
      $i = $s->[0]{$k};
      $s->[1][$i] = $k;
      $s->[2][$i] = $v;
      $s->[0]{$k} = $i;
    }
    else {
      push(@k, $k);
      push(@v, $v);
      $len++;
    }
  }
  if (defined $len) {
    for (keys %{$s->[0]}) {
      $s->[0]{$_} += $len;
    }
    $i = 0;
    for (@k) {
      $s->[0]{$_} = $i++;
    }
    unshift(@{$s->[1]}, @k);
    return unshift(@{$s->[2]}, @v);
  }
  return scalar(@{$s->[1]});
}

sub Unshift2 {
  my($s) = shift;
  $s->Splice(0,0,@_);
  return scalar(@{$s->[1]});
}

#
# splice 
#
# any existing hash key order is preserved. the value is replaced for
# such keys, and the new keys are spliced in the regular fashion.
#
# supports -ve offsets but only +ve lengths
#
# always assumes a 0 start offset
#
sub Splice {
  my($s, $start, $len) = (shift, shift, shift);
  my($k, $v, @k, @v, @r, $i, $siz);
  my($end);                   # inclusive

  # XXX  inline this 
  ($start, $end, $len) = $s->_lrange($start, $len);

  if (defined $start) {
    if ($len > 0) {
      my(@k) = splice(@{$s->[1]}, $start, $len);
      my(@v) = splice(@{$s->[2]}, $start, $len);
      while (@k) {
        $k = shift(@k);
        delete $s->[0]{$k};
        push(@r, $k, shift(@v));
      }
      for ($start..$#{$s->[1]}) {
        $s->[0]{$s->[1][$_]} -= $len;
      }
    }
    while (@_) {
      ($k, $v) = (shift, shift);
      if (exists $s->[0]{$k}) {
        #      $s->STORE($k, $v);
        $i = $s->[0]{$k};
        $s->[1][$i] = $k;
        $s->[2][$i] = $v;
        $s->[0]{$k} = $i;
      }
      else {
        push(@k, $k);
        push(@v, $v);
        $siz++;
      }
    }
    if (defined $siz) {
      for ($start..$#{$s->[1]}) {
        $s->[0]{$s->[1][$_]} += $siz;
      }
      $i = $start;
      for (@k) {
        $s->[0]{$_} = $i++;
      }
      splice(@{$s->[1]}, $start, 0, @k);
      splice(@{$s->[2]}, $start, 0, @v);
    }
  }
  return @r;
}

#
# delete elements specified by key
# other elements higher than the one deleted "slide" down 
#
sub Delete {
  my($s) = shift;

  for (@_) {
    #
    # XXX potential optimization: could do $s->DELETE only if $#_ < 4.
    #     otherwise, should reset all the hash indices in one loop
    #
    $s->DELETE($_);
  }
}

#
# replace hash element at specified index
#
# if the optional key is not supplied the value at index will simply be 
# replaced without affecting the order.
#
# if an element with the supplied key already exists, it will be deleted first.
#
# returns the key of replaced value if it succeeds.
#
sub Replace {
  my($s) = shift;
  my($i, $v, $k) = (shift, shift, shift);
  if (defined $i and $i <= $#{$s->[1]} and $i >= 0) {
    if (defined $k) {
      delete $s->[0]{ $s->[1][$i] };
      $s->DELETE($k) ; #if exists $s->[0]{$k};
      $s->[1][$i] = $k;
      $s->[2][$i] = $v;
      $s->[0]{$k} = $i;
      return $k;
    }
    else {
      $s->[2][$i] = $v;
      return $s->[1][$i];
    }
  }
  return undef;
}

#
# Given an $start and $len, returns a legal start and end (where start <= end)
# for the current hash. 
# Legal range is defined as 0 to $#s+1
# $len defaults to number of elts upto end of list
#
#          0   1   2   ...
#          | X | X | X ... X | X | X |
#                           -2  -1       (no -0 alas)
# X's above are the elements 
#
sub _lrange {
  my($s) = shift;
  my($offset, $len) = @_;
  my($start, $end);         # both inclusive
  my($size) = $#{$s->[1]}+1;

  return undef unless defined $offset;
  if($offset < 0) {
    $start = $offset + $size;
    $start = 0 if $start < 0;
  }
  else {
    ($offset > $size) ? ($start = $size) : ($start = $offset);
  }

  if (defined $len) {
    $len = -$len if $len < 0;
    $len = $size - $start if $len > $size - $start;
  }
  else {
    $len = $size - $start;
  }
  $end = $start + $len - 1;

  return ($start, $end, $len);
}

#
# Return keys at supplied indices
# Returns all keys if no args.
#
sub Keys   { 
  my($s) = shift;
  return ( @_ == 1
	 ? $s->[1][$_[0]]
	 : ( @_
	   ? @{$s->[1]}[@_]
	   : @{$s->[1]} ) );
}

#
# Returns values at supplied indices
# Returns all values if no args.
#
sub Values {
  my($s) = shift;
  return ( @_ == 1
	 ? $s->[2][$_[0]]
	 : ( @_
	   ? @{$s->[2]}[@_]
	   : @{$s->[2]} ) );
}

#
# get indices of specified hash keys
#
sub Indices { 
  my($s) = shift;
  return ( @_ == 1 ? $s->[0]{$_[0]} : @{$s->[0]}{@_} );
}

#
# number of k-v pairs in the ixhash
# note that this does not equal the highest index
# owing to preextended arrays
#
sub Length {
 return scalar @{$_[0]->[1]};
}

#
# Reorder the hash in the supplied key order
#
# warning: any unsupplied keys will be lost from the hash
# any supplied keys that dont exist in the hash will be ignored
#
sub Reorder {
  my($s) = shift;
  my(@k, @v, %x, $i);
  return unless @_;

  $i = 0;
  for (@_) {
    if (exists $s->[0]{$_}) {
      push(@k, $_);
      push(@v, $s->[2][ $s->[0]{$_} ] );
      $x{$_} = $i++;
    }
  }
  $s->[1] = \@k;
  $s->[2] = \@v;
  $s->[0] = \%x;
  return $s;
}

sub SortByKey {
  my($s) = shift;
  $s->Reorder(sort $s->Keys);
}

sub SortByValue {
  my($s) = shift;
  $s->Reorder(sort { $s->FETCH($a) cmp $s->FETCH($b) } $s->Keys)
}

1;
__END__

=head1 NAME

Tie::IxHash - ordered associative arrays for Perl


=head1 SYNOPSIS

    # simple usage
    use Tie::IxHash;
    tie HASHVARIABLE, Tie::IxHash [, LIST];
    
    # OO interface with more powerful features
    use Tie::IxHash;
    TIEOBJECT = Tie::IxHash->new( [LIST] );
    TIEOBJECT->Splice( OFFSET [, LENGTH [, LIST]] );
    TIEOBJECT->Push( LIST );
    TIEOBJECT->Pop;
    TIEOBJECT->Shift;
    TIEOBJECT->Unshift( LIST );
    TIEOBJECT->Keys( [LIST] );
    TIEOBJECT->Values( [LIST] );
    TIEOBJECT->Indices( LIST );
    TIEOBJECT->Delete( [LIST] );
    TIEOBJECT->Replace( OFFSET, VALUE, [KEY] );
    TIEOBJECT->Reorder( LIST );
    TIEOBJECT->SortByKey;
    TIEOBJECT->SortByValue;
    TIEOBJECT->Length;


=head1 DESCRIPTION

This Perl module implements Perl hashes that preserve the order in which the
hash elements were added.  The order is not affected when values
corresponding to existing keys in the IxHash are changed.  The elements can
also be set to any arbitrary supplied order.  The familiar perl array
operations can also be performed on the IxHash.


=head2 Standard C<TIEHASH> Interface

The standard C<TIEHASH> mechanism is available. This interface is 
recommended for simple uses, since the usage is exactly the same as
regular Perl hashes after the C<tie> is declared.


=head2 Object Interface

This module also provides an extended object-oriented interface that can be
used for more powerful operations with the IxHash.  The following methods
are available:

=over 8

=item FETCH, STORE, DELETE, EXISTS

These standard C<TIEHASH> methods mandated by Perl can be used directly.
See the C<tie> entry in perlfunc(1) for details.

=item Push, Pop, Shift, Unshift, Splice

These additional methods resembling Perl functions are available for
operating on key-value pairs in the IxHash. The behavior is the same as the
corresponding perl functions, except when a supplied hash key already exists
in the hash. In that case, the existing value is updated but its order is
not affected.  To unconditionally alter the order of a supplied key-value
pair, first C<DELETE> the IxHash element.

=item Keys

Returns an array of IxHash element keys corresponding to the list of supplied
indices.  Returns an array of all the keys if called without arguments.
Note the return value is mostly only useful when used in a list context
(since perl will convert it to the number of elements in the array when
used in a scalar context, and that may not be very useful).

If a single argument is given, returns the single key corresponding to
the index.  This is usable in either scalar or list context.

=item Values

Returns an array of IxHash element values corresponding to the list of supplied
indices.  Returns an array of all the values if called without arguments.
Note the return value is mostly only useful when used in a list context
(since perl will convert it to the number of elements in the array when
used in a scalar context, and that may not be very useful).

If a single argument is given, returns the single value corresponding to
the index.  This is usable in either scalar or list context.

=item Indices

Returns an array of indices corresponding to the supplied list of keys.
Note the return value is mostly only useful when used in a list context
(since perl will convert it to the number of elements in the array when
used in a scalar context, and that may not be very useful).

If a single argument is given, returns the single index corresponding to
the key.  This is usable in either scalar or list context.

=item Delete

Removes elements with the supplied keys from the IxHash.

=item Replace

Substitutes the IxHash element at the specified index with the supplied
value-key pair.  If a key is not supplied, simply substitutes the value at
index with the supplied value. If an element with the supplied key already
exists, it will be removed from the IxHash first.

=item Reorder

This method can be used to manipulate the internal order of the IxHash
elements by supplying a list of keys in the desired order.  Note however,
that any IxHash elements whose keys are not in the list will be removed from
the IxHash.

=item Length

Returns the number of IxHash elements.

=item SortByKey

Reorders the IxHash elements by textual comparison of the keys.

=item SortByValue

Reorders the IxHash elements by textual comparison of the values.

=back


=head1 EXAMPLE

    use Tie::IxHash;

    # simple interface
    $t = tie(%myhash, Tie::IxHash, 'a' => 1, 'b' => 2);
    %myhash = (first => 1, second => 2, third => 3);
    $myhash{fourth} = 4;
    @keys = keys %myhash;
    @values = values %myhash;
    print("y") if exists $myhash{third};
    
    # OO interface
    $t = Tie::IxHash->new(first => 1, second => 2, third => 3);
    $t->Push(fourth => 4); # same as $myhash{'fourth'} = 4;
    ($k, $v) = $t->Pop;    # $k is 'fourth', $v is 4
    $t->Unshift(neg => -1, zeroth => 0); 
    ($k, $v) = $t->Shift;  # $k is 'neg', $v is -1
    @oneandtwo = $t->Splice(1, 2, foo => 100, bar => 101);
    
    @keys = $t->Keys;
    @values = $t->Values;
    @indices = $t->Indices('foo', 'zeroth');
    @itemkeys = $t->Keys(@indices);
    @itemvals = $t->Values(@indices);
    $t->Replace(2, 0.3, 'other');
    $t->Delete('second', 'zeroth');
    $len = $t->Length;     # number of key-value pairs

    $t->Reorder(reverse @keys);
    $t->SortByKey;
    $t->SortByValue;


=head1 BUGS

You cannot specify a negative length to C<Splice>. Negative indexes are OK,
though.

Indexing always begins at 0 (despite the current C<$[> setting) for 
all the functions.


=head1 TODO

Addition of elements with keys that already exist to the end of the IxHash
must be controlled by a switch.

Provide C<TIEARRAY> interface when it stabilizes in Perl.

Rewrite using XSUBs for efficiency.


=head1 AUTHOR

Gurusamy Sarathy        gsar@umich.edu

Copyright (c) 1995 Gurusamy Sarathy. All rights reserved.
This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.


=head1 VERSION

Version 1.21    20 Nov 1997


=head1 SEE ALSO

perl(1)

=cut