RE: DOS vs. Unix line endings

	Free Downloads, Community Forum, FAQs and Developer Resources

Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

All Forums	Register	Login	Search	Subscriptions	My Profile	Inbox
Tool Warehouse	FAQs	Resources	Help	Member List	Address Book	Logout

RE: DOS vs. Unix line endings

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [SFU / Interix / SUA Technology] >> SFU / Interix - Getting Started >> RE: DOS vs. Unix line endings

Page: << < prev 1 [2]

Message

<< Older Topic Newer Topic >>

RE: DOS vs. Unix line endings - May 20, '06, 1:49:52 AM

Rodney

Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

It's something about the '\r' being in the middle of a statement.
Yes, with "good constructs" <-- One can always hope otherwise

, but that isn't the case.
A short stab at the code shows it'll take a block of time to trace it down (no it wasn't
the "obvious" whitespace skip code). That'll have to be next week as I'm trying to get
a milestone cleared.

(in reply to woehlkmp)

Post #: 21

RE: DOS vs. Unix line endings - May 20, '06, 3:02:48 PM

dpchrist

Posts: 9
Joined: May 9, '06,
Status: offline

Rodney wrote:
> It's something about the '\r' being in the middle of a statement.

Looking at [1] p. 112, if/else is demonstrated as:

if condition
then
    statements
[elif condition
    then statements...]
[else
    statements]
fi

So, I assume your statement "It's something about the '\r' being in the middle of a statement" means the error is with lines like:

    91  if [ -d $HOME/share/man ] ; then

I forget where I picked up that style, but it seems to work fine on Cygwin, Debian, and Slackware versions of Bash, and on SFU Bash if I change the line endings to Unix.

[1] includes a BNF description of Bash syntax. It's been a while since I've looked at techno like that, but it's my understanding that bash sytax is free-form (e.g. does not mandate line endings in the syntax).

Changing the if/then style to [1] throughout and using DOS line endings, SFU bash still complains:

Welcome to the Interix UNIX utilities.

DISPLAY=localhost:0.0
: command not found
bash: /dev/fs/C/cygwin/home/dpchrist/.bash_profile: line 113: syntax error: unexpected end of file
bash-3.00$ wc .bash_profile
     112     235    2224 .bash_profile

So, it sounds like the problem is with the SFU bash parser when dealing with DOS line endings.

My entire .bash_profile follows FYI.

David

References:

[1] Cameron Newhan & Bill Rosenblatt, 1998, "Learning of tbash Shell", 2 e., O'Reilly, ISBN 1-56592-347-2.

# $Id: .bash_profile,v 1.34 2006/05/20 18:55:31 dpchrist Exp $

if [ -f ~/.bashrc ]
then
        . ~/.bashrc
fi

##### Hurricane Electric:
if [ "$HOSTNAME" = "cloud.he.net" ]
then

    ##### he.net installed CVS for me locally
    export PATH=$PATH:$HOME/cvs/bin

    ##### he.net doesn't support TERM=Cygwin; this sort of works
    #export TERM=vt100
fi

##### root user on Linux boxes:
if [ "$USER" = "root" ]
then
    ##### prevent users from sending messages via write(1):

    ##### Debian 3.0r3:
    if [ "$MACHTYPE" = "i386-pc-linux-gnu" ]
    then
        PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11

        mesg n
    fi

    ##### Slackware 9.1:
    if [ "$MACHTYPE" = "i486-slackware-linux-gnu" ]
    then
        PATH=/usr/local/sbin:/usr/sbin:/sbin
        PATH=$PATH:/usr/local/bin:/usr/bin:/bin
        PATH=$PATH:/usr/X11R6/bin:/usr/games
    fi
fi

if [ "$OSTYPE" = "cygwin" ]
then
    ##### Work-around for perldoc page formating on Cygwin.  See
    #####     http://www.cygwin.com/ml/cygwin/2004-10/msg01454.html
    export LESS=-R

    ##### add /usr/sbin to path
    PATH=${PATH}:/usr/sbin
fi

if [ -d ${HOME}/bin ]
then
    PATH=${HOME}/bin:${PATH}
fi

export PATH

if [ -d $HOME/lib/perl ]
then
    PERL5LIB=${PERL5LIB}:$HOME/lib/perl
fi

if [ -d $HOME/lib/perl5/5.8.0 ]
then
    PERL5LIB=${PERL5LIB}:$HOME/lib/perl5/5.8.0
fi

if [ -d $HOME/lib/perl5/site_perl/5.8.0 ]
then
    PERL5LIB=${PERL5LIB}:$HOME/lib/perl5/site_perl/5.8.0
fi

if [ -d $HOME/share/perl ]
then
    PERL5LIB=$PERL5LIB:$HOME/share/perl
fi

if [ -d $HOME/share/perl/5.6.1 ]
then
    PERL5LIB=$PERL5LIB:$HOME/share/perl/5.6.1
fi

export PERL5LIB

##### Make cpan work through firewalls:
export FTP_PASSIVE=1

##### I forget which system needed this...
unset USERNAME

export EDITOR=vim
export HISTCONTROL=ignoredups
export LANG=C
export OSTYPE
export PS1='\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '

if [ -d $HOME/cvs/man ]
then
    MANPATH=$MANPATH:$HOME/cvs/man
fi

if [ -d $HOME/man ]
then
    MANPATH=$MANPATH:$HOME/man
fi

if [ -d $HOME/share/man ]
then
    MANPATH=$MANPATH:$HOME/share/man
fi

export MANPATH=:$HOME/local/man

(in reply to Rodney)

Post #: 22

RE: DOS vs. Unix line endings - May 21, '06, 12:15:21 AM

Rodney

Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

There's nothing wrong with using the style of:

    91  if [ -d $HOME/share/man ] ; then

it's pretty common sh style.

There are no changes to the bash source code that is for Interix (except
that one I just did last week). So it's likely something really small that needs
a tweak.

> ...but it's my understanding that bash sytax is free-form...

Well, bash didn't have any choice with that because it wanted to be
clone of the sh (Steve Bourne) shell plus csh and ksh bits.

It looks like something to do with whitespace because if \r's within statements
are removed, but left at the end, then it all works. It'll work out.
The truely odd thing I find is that with bash 3.0 this isn't a default.
Many other shells do this already (tcsh, pdksh, ksh).

(in reply to Rodney)

Post #: 23

RE: DOS vs. Unix line endings - Jul. 19, '06, 11:45:28 PM

Rodney

Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

Well, it took longer for me to get back to this than anticipated.
But the good news is that this is all wrapped up now with version 3.0.0.8
as a package. The "'\r' in the middle" is all handled now. Even in a file
that has a mixture of Unix and DOS line endings.

(in reply to Rodney)