ITP dos2unix 5.2.1-1
Charles Wilson
cygwin@cwilson.fastmail.fm
Thu Mar 17 17:08:00 GMT 2011
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
More information about the Cygwin
mailing list