From:	ld AT netrix DOT com (Long Doan)
Subject:	Re: HOME and bash
24 Jan 1997 13:43:09 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<32E8D370.7409.cygnus.gnu-win32@netrix.com>
References:	<c=US%a=_%p=OrCAD%l=EXCHANGE_SERV-970124005426Z-4716 AT exchange-server DOT orcad DOT com>
Mime-Version:	1.0
X-Mailer:	Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m)
Original-To:	Ron Forrester <Ron AT OrCAD DOT com>
Original-Cc:	"'Jim Balter'" <jqb AT netcom DOT com>, "'GNU-Win32'" <gnu-win32 AT cygnus DOT com>
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Ron,

I have a setup similar to yours, so maybe this will help. I set the HOME
variable via the control panel, like HOME=/home/ld, and in my emacs.bat
(NTEmacs's startup file) I set HOME=%HOMEDRIVE%%HOMEPATH%, which is
D:\home\ld. If you want to invoke NTEmacs via some icon, just tell that
icon to invoke the .bat file.

Hope that helps,
Long.

Ron Forrester wrote:
> 
> 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".
-
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 -