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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Original-To: "'Jim Balter'" Original-Cc: "'GNU-Win32'" 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. > >-- > - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".