Dropped cygwin-apps.
On 3/17/2011 5:05 AM, Erwin Waterlander wrote:
> On 03/16/2011 10:38 PM, Charles Wilson wrote:
>> 5) cygutils always follows symlinks. This new package does not,
>> unless --force, according to the man page (which is
>> unfortunate: the same option means "follow symlinks" AND
>> "convert everything even if you think it is binary"
> The new package does not follow symlinks, so you don't damage files on
> other locations. If you force conversion a copy is created. The symlink
> target remains unmodified. There is not a separate option to force
> conversion of symlinks. Perhaps the creation of copies should be default.
>> 5: if the new package is used, I think we should patch it to always
>> follow symlinks (or add a new option, and make it default to follow).
>
> I would propose a new option to follow symlinks. By default not follow,
> but copy (don't damage files on other locations).
Erwin, you don't seem to understand the importance of not changing
current behavior, when replacing existing apps. I'm trying to point out
(a) how little your proposed package actually differs from the current
cygutils implementations, and (b) what needs to change to make the new
version a drop-in replacement.
Because that's what you're trying to do: make a drop in replacement.
Regardless of whether some current behavior of cygutils-dos2unix is good
or bad, CHANGE is worse -- since people have been relying on the current
behavior for years.
Now, if you REALLY feel strongly about some particular point, then I
would suggest a stepwise conversion. FIRST, patch and release the new
package, dos2unix, such that it is a drop-in replacement with NO
expected changes in behavior (other than, obviously, its new
capabilities like 7bit, iso, etc).
For instance, a --no-follow / --follow pair of options, where --follow
is the default (to match the behavior of cygutils-dos2unix), but users
can specify --no-follow if they want.
Then, after a suitable time has elapsed -- 1 month? 3 months? -- change
the default to be --no-follow, and make a BIG DEAL of this behavior
change in your announcement.
Rule:
Users don't like change. Only make one change at a time.
So, change #1: switch from cygutils-dos2unix to the new package.
change #2, somewhat later: change the default "follow" behavior.
BTW: I *guarantee* that there will be some behavioral change in your
"drop in" replacement that we missed. A bug, packaging oops, SOMETHING.
You'll want to use the 1-month (3?) grace period to wait for those
reports, and fix 'em, before introducing any new, deliberate, behavior
changes. (BTW, you'll want to test the behavior of the apps, on files,
on pipes with redirection to a file, etc, on DOS mounts in addition to
UNIX ones...voice of experience... :-(
Note also that my proposal (TWO new options, where one reasserts the
default -- whatever that default may be) is similar to the
--force/--safe pair. Good command-line option design usually requires
these paired options, so that the CLI doesn't change even when/if you
(later) decide to change the default. It's not about overriding an
Administrative alias; it's about easily overriding MY OWN alias, if I
generally like the opposite default from what the base executable does
but SOMETIMES want to behave the "other way". Sure, I can use
full-path-to-exe to avoid the alias, but given
alias d2u='/usr/bin/d2u --force --follow'
/usr/bin/d2u *
vs d2u --safe --no-follow *
The latter is more expressive: HERE'S what I want to do right now,
rather than "Oh yeah, my alias does X but the default app does !X, so to
get !X I need to override some alias in my ~/.bashrc that I haven't
edited in years, and just usually take for granted as THE behavior of
that app..."
Or, "interactively I like --follow, but I don't want scripts to run
amuck, so I'll alias d2u to 'd2u --follow' but explicitly use 'd2u
--no-follow' in scripts so they DTRT regardless of any alias settings."
Or, my alias sets LOTS of (anti-)defaults, and I just want to reassert
the real default behavior for ONE of them:
d2u --safe (but keep the alias --follow behavior)
Think '-i' vs. '-f' for 'rm'
FYI, I think a patch to add --safe, plus the patch to add
--follow/--no-follow (where --follow does NOT also imply --force) would
be suitable patches to go upstream. Assuming that patch was adopted
upstream, the only (temporary) difference between cygwin's new package
and upstream would be the default behavior of the follow/no-follow pair.
--
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
