This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: CR/LF problems after upgrade

Dave Korn wrote:
> On 05 January 2007 18:45, fschmidt wrote:
>> from
>>> 2. d2u is your friend.  You can use it to convert any problematic script
>>> into binary line endings. 
>> Several people I work with, who are even less technical than I am, use
>> cygwin and edit scripts with various editors.  So this will not work.
>   You need to use /development methodology/ to solve this problem.  Either
> set
> their editors to use LFs, or if they like editors that cannot do CR/LFs
> try
> and offer them as similar an editor as you can find to use that does do
> LFs,
> or perhaps write a script for them to run that finds all the script files
> and
> automatically d2u's them, or convert files to LFs when you check them into
> version control... there are loads of possible solutions.

It was hard enough to convince people to use cygwin.  These people will not
change editors or run a global script to accomodate cygwin.

>> I don't know what mounts are, or how to use them.
>   That is entirely your own fault.  The solution to this problem is for
> you to
> be bothered to read the documentation.  No technical means can help you if
> you
> can't be bothered to employ it.

May I suggest adding a warning to the cygwin homepage like:

"Use of Cygwin requires unix system administration knowledge.  Please do not
use Cygwin if you are not familiar with unix system administration."

This would discourage people like me from using cygwin and would result in a
smaller, but more harmonious, cygwin community.

Yes it's true that I am not interested in learning unix file system
concepts.  All I want is a decent shell.  If cygwin can't provide this in a
relatively painless way, then I will look for an alternative.

>>> 4c. To affect all scripts, export the environment variable BASH_ENV,
>>> pointing to a file that sets the shell option as desired.  Bash will
>>> source this file on startup for every script.
>> I tried:
>> cd /etc
>> echo '(set -o igncr) 2>/dev/null && set -o igncr; # comment is needed'
>>> bash_env
>> export BASH_ENV=/etc/bash_env
>> This did not work.
>   WJFFM:  perhaps you need to "chmod x+x /etc/bash_env"?  Here's an
> example:
> ~ $ cd /tmp
> /tmp $ mkdir crlf
> /tmp $ cd crlf/
> /tmp/crlf $ touch
> /tmp/crlf $ write
> /tmp/crlf $ cat
> #!/bin/bash
> echo This is a script with CRLF endings
> ls
> pwd
> uname
> id
> /tmp/crlf $ u2d
> done.
> /tmp/crlf $ chmod a+x
> /tmp/crlf $ ./
> This is a script with CRLF endings
> : command not foundls
> : command not foundpwd
> : command not founduname
> : command not foundid
> /tmp/crlf $ echo '(set -o igncr) 2>/dev/null && set -o igncr; # comment is
> need
> ed' >> ./bash_env
> /tmp/crlf $ export BASH_ENV=/tmp/crlf/bash_env
> /tmp/crlf $ d2u bash_env
> bash_env: done.
> /tmp/crlf $ chmod a+x bash_env
> /tmp/crlf $ ./
> This is a script with CRLF endings
> bash_env
> /tmp/crlf
> uid=11165(dk) gid=10513(Domain Users)
> groups=0(root),544(Administrators),545(Use
> rs),1005(Debugger Users),11113(Artimi),10512(Domain Admins),10513(Domain
> Users),
> 10519(Enterprise Admins),11311(Exmergers),12171(Hardware_Share)
> /tmp/crlf $

This didn't work for me.  I tried:

cd /etc
echo '(set -o igncr) 2>/dev/null && set -o igncr; # comment is needed'
export BASH_ENV=/etc/bash_env
d2u bash_env
chmod a+x bash_env

And my scripts still don't work.

>>> 4d. Added in the bash-3.2-2 release: export the environment variable
>>> SHELLOPTS with igncr included in it.  It is read-only from within bash,
>>> but you can set it before invoking bash; once in bash, it auto-tracks
>>> the
>>> current state of 'set -o igncr' or 'shopt -s igncr'.  If exported, then
>>> all bash child processes inherit the same option settings.
>> I tried:
>> export SHELLOPTS=$SHELLOPTS:igncr
>> and got:
>> bash: SHELLOPTS: readonly variable
>   Well duh.  What on earth did you suppose it means up there where it says
> "It
> is read-only from within bash"?  Can you not see the words which are right
> in
> front of your face?

Okay, how can I set SHELLOPTS before invoking bash?  I tried it in the
/etc/profile but that didn't work.

View this message in context:
Sent from the Cygwin Users mailing list archive at

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]