X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Daniel Brockman Subject: Re: trouble with bash / if in recent release / update ? Date: Tue, 30 Jan 2007 18:20:12 +0000 (UTC) Lines: 121 Message-ID: References: <45BF45FE DOT 2080406 AT byu DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Eric Blake byu.net> writes: > > According to Daniel Brockman on 1/30/2007 12:18 AM: > > A blank line in the script file produces err msg Eric, I am glad there are people like you, knowledgable and deeply interested. Clearly you have given much thought to the consistency and efficiency of Cygwin/ Linux. All of us benefit from your valuable efforts. I'm sincerely grateful. I think we may have disagreement on values and objectives, and perhaps some (hopefully temporary) conflict of personal interests. I hope we can cooperate, in the spirit of children of the Enlightment, in rational discourse leading to a generally beneficial solution. I'm a user of Cygwin. I installed it on Windows because I wanted Unix functionality in Windows. And Cygwin delivered it quite nicely. I don't keep up with the topics in the forums, and I don't follow the announcements. I'm way downstream from all that. I work on unrelated topics to which I couldn't do justice if I spent a lot of time engineering Linux/Cygwin/Unix. I had shell scripts that had worked quite nicely several days per week for years. After I updated Cygwin over the weekend, those scripts didn't work. I have experienced a very serious (for me) loss of functionality. That's why I call this event a bug in bash. I realize the "enhancement" is intended to achieve 1. more efficient use of system resources in processing 2. greater consistency with an ideal of Unix implementation However, I'm less interested in getting top system performance and efficiency. If I wanted speed, I wouldn't use a shell script. I want a program that runs reliably and not too terribly long. Whether it runs at 30 mph instead of a possible 40 mph has little significance for me. I want a Unix that works on and with Windows. This Unix may be inconsistent with other Unixes that don't work with Windows. I want practical usefulness. Adherence to ideal forms would be nice, and I will sacrifice that adherence to get utility. Further comments below... Eric Blake byu.net> writes: > > According to Daniel Brockman on 1/30/2007 12:18 AM: > > A blank line in the script file produces err msg > > > > : command not found > > > > I can't figure out a way to make the new version of sh.exe work. Imho, it's > > broken. > ... > > > > I found this in the archive... > > > > 4a. For a single affected script, add this line just after the she-bang: > > (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed > > You were correct - it is not sh that is broken, it was your scripts. And > have you considered point 2, that running d2u might be easier than using > igncr? No I haven't considered it. I barely know what d2u is and I never heard of igncr before. I don't want to run d2u every time I create or modify a script. Nor do I want to go through my inventory of scripts and modify them all. In the environment in which I work, both Cygwin and Windows programs create and modify files. > > > > > The value of the latest enhancement isn't immediately apparent to me. > > READ THE ARCHIVES! This topic has been talked to death in the past two I have limited time available to me to read the archives. I still object to having to cope with this interruption to functionality on which I have relied. > months. The value is the fact that Cygwin on binary mount points is > _designed_ to emulate Linux, and on Linux, you will get the _same_ syntax > errors with raw carriage returns in your scripts; furthermore, this change I'm running on Windows. I expect Cygwin bash to tolerate the raw carriage returns without generating errors, like it did last week. I don't understand the distinction between "text mounts" and "binary mounts", and I don't think it's relevant to my business, which is the business of my clients. These are engineering considerations of minimal interest to end users. > was made in response to a performance bug. In my opinion, text mode files An alternate approach to the performance bug might be to make the raw-carriage- return-handler more efficient, rather than to eliminate it. Another alternate might be to make the sensitivity to raw carriage returns, and the associated performance enhancement, an option to the shell, rather than default behavior. > are a hack for people unable to follow Linux semantics; either use text Exactly. It's a valuable hack, if you must use that pejorative term. I suggest that those concerned adopt it as a functional specification. I consider it indispensible to the quest for dominance over Microsoft. > mount points, or specifically ask bash to operate in text mode; either > way, it should help make it clear to yourself that you are moving away > from Linux behavior and getting slower performance as a result. I will accept slower performance in exchange for usefulness and backward compatibility. I request that zsh be kept free of the performance improvements and emulations of Linux that have somewhat disabled the usefulness of bash and sh. Again, Eric, I value your interest and your desire for excellence in the Cygwin platform. I thank you for your efforts. db -- 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/