X-Spam-Check-By: sourceware.org
Date: Tue, 19 Sep 2006 11:38:37 -0400 (EDT)
From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: "Williams, Gerald S (Jerry)" <gsw AT agere DOT com>
cc: cygwin AT cygwin DOT com
Subject: RE: Read not honouring "-r"?
In-Reply-To: <4C89134832705D4D85A6CD2EBF38AE0F7B0E05@PAUMAILU03.ags.agere.com>
Message-ID: <Pine.GSO.4.63.0609191111200.26721@access1.cims.nyu.edu>
References: <4C89134832705D4D85A6CD2EBF38AE0F7B0E05 AT PAUMAILU03 DOT ags DOT agere DOT com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Tue, 19 Sep 2006, Williams, Gerald S (Jerry) wrote:

> Doug Irwin wrote:
> > One would expect a "read -r fs t2 t3" to process this without
> > attempting to expand slashes.  But I can't seem to get this bit
> > working... And I can't seem to find any doco on doing that in Cygwin.
> >
> > I've attached the files I am testing with in the hope that someone
> > can help me work this out.
> >
> > No doubt I have missed something rather obvious.
>
> "-r" has nothing to do with it: CR/LF line endings are the
> culprit.
>
> This seems to be particularly tied to ksh, and specifically
> when you use "<" to redirect a file. If you simply pipe the
> output of grep to the while loop, it works. Interestingly,
> sh, bash, and zsh all give the behavior you were expecting.

Thanks for the detective work, Jerry -- I almost missed the textmode
issue.

> So for the short term, run d2u on filesystems.cfg. If you
> plan to continue using ksh, you may want to follow up and
> try to understand the discrepancy--there may be an option
> that allows you to get the behavior you want (and if not,
> it may be worth having KSH's behavior changed to be more
> consistent with other shells, but that's something for
> the maintainer and/or upstream KSH support to decide).

Unfortunately, there is no option to control this.  Neither is there any
upstream KSH support.  The "quick fix" I mentioned in the previous message
simply disables seeking and buffering everywhere in PDKsh, so expect
slowdowns with large scripts/data files in the new version.  But at least
it'll be correct.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/