From: csw AT epigram DOT com (Chris Warth)
Subject: sed bug - false alarm
19 Dec 1996 14:01:40 -0800
Sender: daemon AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199612191815.KAA10132.cygnus.gnu-win32@epigram.epigram.com>
Original-To: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com



Eeek! Embarassingly, I misattributed a bug in the MKS' version of sed
to the GNU version of sed.  The GNU version is fine and does not
append a '/r/n' to its output.  The problem was I had the MKS tools in
the same path as the GNU tools and didn't realize it.

It does look like that bash (or gnu-win32 - whoever) doesn't grok 
mount points on devices like "\\server\\sharename\"
only during PATH searches.  i.e. I have a mount point like

Device                   Directory     Type        Flags
\\server\sharename\usr   /usr          native      no-mixed,text!=binary

I can now 'cd /usr/local' and get to the right place.  

However if I put '/usr/local/bin' in my PATH, bash never seems to find
any executables there, the true path being '\\server\sharename\usr\local\bin'.

Instead, if I connect a network drive 'G:\' to '\\server\sharename'
and then mount 'G:\usr' as '/usr' PATH searches work fine and 'cd
/usr/local' still works as well.  The true path in that case would be
something like 'G:\usr\local\bin'


-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".