From:	Ron AT OrCAD DOT com (Ron Forrester)
Subject:	RE: HOME and bash
23 Jan 1997 20:15:08 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<c=US%a=_%p=OrCAD%l=EXCHANGE_SERV-970124005426Z-4716.cygnus.gnu-win32@exchange-server.orcad.com>
Mime-Version:	1.0
Original-To:	"'Jim Balter'" <jqb AT netcom DOT com>
Original-Cc:	"'GNU-Win32'" <gnu-win32 AT cygnus DOT com>
X-Mailer:	Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

I get the same byte counts with ls and wc. 

I don't (anymore) define HOME in my .bashrc. I have a bash.cmd which I
run to launch bash, which is:

@echo off
set HOME=/usr/rjf
c:/usr/rjf/b17.1/h-i386-cygwin32/bin/bash.exe
exit

this has fixed that problem. See, I was running bash from Hamilton CSH
before, and HOME is a special variable to HCSH, and it has to have a
drive letter in it, so...

The only major problem I am having now is that NT Emacs will not find my
..emacs file (in $HOME) unless I run it from $HOME. Even though once in
emacs, it seems to evaluate $HOME to the right place (/usr/rjf).

I posted on this to the NT Emacs list to see if there are any
solutions...

Thanks!
rjf

>-----Original Message-----
>From:	Jim Balter [SMTP:jqb AT netcom DOT com]
>Sent:	Thursday, January 23, 1997 4:46 PM
>To:	Ron Forrester
>Cc:	'Gnu-Win32'
>Subject:	Re: HOME and bash
>
>Ron Forrester wrote:
>> 
>> I just installed b17.1, and so far things are overall really great!
>> 
>> However, I am trying to get the ~/ functionality from bash that I am
>> used to. In my .bashrc file, I have the following line:
>> 
>> export HOME=/usr/rjf
>> 
>> which is indeed where I want ~ to point.
>> 
>> After starting up bash, I see that the above is really in my
>> environment. Issuing the command cd ~/source, bash goes away for a while
>> (30+ seconds), then comes back with:
>> 
>> bash: c:usrrjf/source: No such file or directory
>
>Somewhere your HOME is being defined as c:\usr\rjf,
>and bash ignores the backslashes, yielding "c:usrrjf".
>
>What exactly does your .bashrc contain?  If it contains any carriage
>returns, you have hit an infamous bug, discussed recently on this list.
>Compare ls -l .bashrc to wc .bashrc; if they report different
>character counts, you have the problem.  You can filter out the
>CR's with any of various tools (not including tr, related to the
>same (text mode) problem, sigh), get the patch recently posted here,
>mount c: with the -b flag if you know what you are doing and are brave,
>or write a filter using some simple C code like
>
>	while ((c = getchar()) != EOF)
>		if (c != '\r')
>			putchar(c);
>
>
>[SOAPBOX MODE]
>Right now, there are dozens of bugs in the tools and their use due
>to text mode.  I suggest that this is an area that could use some
>careful rethinking.  My own opinion is that the tools should default
>to binary mode but should open in text mode when a filename has some
>special form, such as crnl:foo or dos:foo.  This wouldn't allow text
>opens via shell redirection, but that would be a small price to pay to
>make od, tr, gzip, tar, cat, etc. ad nauseam work properly with
>redirection.
>
>--
><J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -