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: trouble with bash / if in recent release / update ?

Eric Blake <ebb9 <at>> 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 <ebb9 <at>> 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 

> > 
> > 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 

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.


Unsubscribe info:
Problem reports:

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