X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.2 required=5.0	tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_YG
X-Spam-Check-By: sourceware.org
Message-ID: <4D823D92.1000600@cwilson.fastmail.fm>
Date: Thu, 17 Mar 2011 12:57:54 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: ITP dos2unix 5.2.1-1
References: <4D7FE2A7 DOT 8080409 AT xs4all DOT nl> <4D7FE57A DOT 4020903 AT redhat DOT com> <4D806DCF DOT 5090803 AT xs4all DOT nl> <4D80C0B8 DOT 8090603 AT cwilson DOT fastmail DOT fm> <4D80CEB4 DOT 7090005 AT xs4all DOT nl> <20110316154913 DOT GA18995 AT ednor DOT casa DOT cgf DOT cx> <4D80DEAF DOT 6020307 AT xs4all DOT nl> <4D810FAF DOT 6040609 AT t-online DOT de> <20110316193249 DOT GA15365 AT ednor DOT casa DOT cgf DOT cx> <4D8117FD DOT 40507 AT cwilson DOT fastmail DOT fm> <20110316201821 DOT GA773 AT ednor DOT casa DOT cgf DOT cx> <4D812DBE DOT 1090607 AT cwilson DOT fastmail DOT fm> <4D81CED1 DOT 9050601 AT xs4all DOT nl> <4D820D62 DOT 4030403 AT cwilson DOT fastmail DOT fm> <4D821D89 DOT 5020105 AT xs4all DOT nl>
In-Reply-To: <4D821D89.5020105@xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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 3/17/2011 10:41 AM, Erwin Waterlander wrote:
> I do understand you very well, but I come from the other side. The
> dos2unix that I packed and maintain is around on Unix/Linux since 1989.
> I assume there are much more Linux users than Cygwin users. So I don't
> want to break things on Linux.

You want to replace a CYGWIN package.  I fail to see how that would
break anything on a linux machine.

My suggested (upstreamable) patches don't change the linux behavior at
all, except to add new option flags.  In the upstreamed patch, the
default behavior would remain as-is (--safe and --no-follow would be the
defaults; as today, --force would override these "defaults" with its
current behavior of [break symlink & make copy & modify copy] + always
convert even "binary" files).

I proposed an *additional* temporary, cygwin-only patch that is not
upstreamed, that changes the default behavior of the
--follow/--no-follow pair.  For a short time.

I might even suggest the following: assume dos2unix-5.2.3 is released
with the
	--follow
	--no-follow
	--safe
options added to "upstream".  Then, simultaneously release TWO packages
on cygwin:

	dos2unix-5.2.3-1  (that has a cygwin-specific patch to make
                          the default behavior, on cygwin, --follow)
	dos2unix-5.2.3-10 (that is stock upstream 5.2.3)

In your setup.hint, mark
	curr: 5.2.3-1
	test: 5.2.3-10
That way, if your users who are currently used to linux behavior
complain, you can say "it's a transition thing on cygwin, given their
old implementation.  For now, switch to the 'test' release which works
just like linux. In a few months, it'll be the default."

In the above, I left releases -2 thru -9 "open" for any necessary
bug-fixes with the new version, that might be required before the
flag-day switch to the linux-like behavior.

> Since Cygwin tries to be Linux-alike, I
> offer this package to the cygwin community. Personally I prefer to have
> the same on Cygwin as on Linux. The cygwin community may have got used
> to the current cygwin tailored implementation. But I bet there are many
> cygwin users who also work on Linux, so there is a big chance they are
> already familiar with the version I maintain.

Any confusion of behavior only applies in two places:

	1) a user's own memory and habits

	2) scripts that are SHARED or copied without change between
	   cygwin and linux environments

Regarding #1
============
Right now, any affected cygwin user ALREADY "knows" that cygwin d2u
behaves differently than unix d2u.  So...for an *existing* cygwin user,
making the new cygwin-d2u behave exactly like cygUTILS-d2u is a null
event.  No change. They used to adapt to the difference in behavior
between the two platforms; they need to continue to adapt to that
difference.  In fact, it's probably a habit by now.  (if this esoteric
--follow behavior matters to them).


NEW cygwin users might be surprised by the cygUTILS-d2u/new-cygwin-d2u
behavior.  But...there are far fewer of those in any given three month
period than there are existing cygwin users.  So it doesn't make sense
to say "well, since many cyg users are familiar with the linux version,
it's okay to change the one they are used to using on cygwin, to match
the one they are used to using on linux".

This argument applies to far more than just d2u, btw -- even limited to
the universe of linux software that also appears on cygwin.  But from
the broader universe:

Here's a story from 10 years ago: I'm used to using infix notation (2 +
4 =) on dumb 4-function calculators, but I LOVED my HP48's postfix (aka
reverse polish notation, or RPN) -- 2 enter 4 +.  I was VERY ANNOYED
when HP decided that, since people are used to infix notation on TI
calculators, they should switch all new HP scientific calcs to infix by
default.  Sure, I could deal with it...but I really didn't want to
retrain my fingers for my new (at the time) HP.  Fortunately the new one
could be switched back to RPN (but I eventually dumped it anyway and
went back to the trusty HP48, but that was because the build quality of
the new model sucked).  To finish the story now that my 20-year-old
HP48's screen is damaged -- I now have an HP48 emulator on my Android
phone.  But I miss my classic HP clicky keys; a touchscreen is just not
the same -- but apparently not even the newest model HP50g has restored
the classic key construction and feel. :-(

So, my brain says:
	dumb 4-function calc: infix
	HP scientific calc:   rpn
Right now, a lot of people may have trained themselves
	linux:  d2u works /this way/
	cygwin: d2u works /that way/
Don't change it unless you must, and only introduce ONE CHANGE at a
time. Right now, you're at the 'switch to alt implementation; add lots
of new features like -7 and --convert=CPxxxx' stage (as viewed from the
perspective of the cygwin distribution and users).

Save any other changes for later...even if that means you have to
temporarily patch the new impl to act like the old impl.

--- Takeaway:
I'm not against changing the default behavior. I'm against changing a
LOT of default behaviors all at once, and against changing defaults
without providing a way to return to the original.

Regarding #2
============
RIGHT NOW, any such shared script ALREADY must care for these
differences.  If you make a behavioral change, all such scripts will
need to be modified:

   case "$host_os" in
-  *linux*)    /do this/ ;;
-  *cygwin*)   /do that/ ;;
   *)          /do something else/ ;;
   esac
--
   case "$host_os" in
+  *linux* | *cygwin* ) /do this/ ;;
   *)                   /do something else/ ;;
   esac

It's actually worse than that. If the script is widely shared between
many cygwin installations (some of which may still have the old tool),
then they need to do:

   case "$host_os" in
   *linux* ) /do this/ ;;
   *cygwin* )
      if cygcheck -cd dos2unix | grep dos2unix >/dev/null
      then
        /do this/ ; # new dos2unix behaves like linux
      else
        /do that/ ; # old cygutils dos2unix
      fi
   *) /do something else/ ;;
   esac

Most probably won't bother; they just make the first change above and
require all cygwin clients to update to /latest/.


So, in arguing to make the behavior between cygwin and linux match, you
are arguing to force the owners of all existing scripts that care about
this behavior to change.

The only scripts this /helps/ are NEWLY written ones (that won't be
shared with an instance of cygwin that still provides the current
behavior).  It's a rule of thumb: the number of existing clients that
depend on a given behavior is always larger than you expect...don't
break 'em unless you have a really good reason.  And don't break 'em in
MULTIPLE WAYS all at the same time.



Final point: I realize nobody wants to maintain a non-upstreamable
forked version of software.  Everybody wants to be able to build
software on cygwin out of the box.

So...if the upstream people really really hate --follow/--no-follow and
won't accept it, then maybe an all-at-once change here on cygwin would
be okay.  Ditto --safe.

But...that's not an issue here, because *you* are the "upstream people"!

So let's rephrase: What is the "upstream" objection to providing a few
new options, with no change in upstream's current default behavior:

	--follow	follow symbolic links and modify the pointed-to
	                file. This differs from --force, which breaks
	                the symbolic link, replaces it with a local
	                copy, and modifies the copy. If --force, then
	                --follow has no effect.

	--no-follow	do not follow symbolic links.  If --force, then
	                --no-follow has no effect.
...
	--safe          Do not modify binary files; opposite of --force.
	                (default)

Time to create the patch?  Patch requires too many internal changes that
are too ugly, due to internal architecture (can't imagine this is the
objection to --safe; that's a two-liner)?  Style?

--
Chuck

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