Re: ITP dos2unix 5.2.1-1
On 3/18/2011 2:53 AM, Charles Wilson wrote: On 3/17/2011 4:36 PM, Charles Wilson wrote: OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. FYI, the first four patches 0001-cygwin-makefile-fixes.patch 0002-cygwin-defines-WIN32-but-isn-t.patch 0003-Rationalize-logic-flow.patch 0004-Add-safe-option-opposite-of-force.patch now have patch tracker items at sourceforge.net: 0001-cygwin-makefile-fixes.patch http://bit.ly/eJU32U 0002-cygwin-defines-WIN32-but-isn-t.patch http://bit.ly/fczran 0003-Rationalize-logic-flow.patch http://bit.ly/gU32y2 0004-Add-safe-option-opposite-of-force.patch http://bit.ly/gO7n9Y I'm going to delay the other patches until these are either accepted (in whatever form) or rejected, because the remaining patches are have too many overlaps with these to allow simultaneous discussion (svn is not good at 'patch sequencing' of uncommitted patches). -- 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
Re: ITP dos2unix 5.2.1-1
Charles Wilson schreef, Op 17-3-2011 21:36: On 3/17/2011 4:08 PM, Eric Blake wrote: On 03/17/2011 01:56 PM, Erwin Waterlander wrote: I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. There's two sets of patches being talked about here: 1) What temporary (3-month?) patches are needed to make the dos2unix package a drop-in replacement to the existing cygwin dos2unix, so that people can start testing if it really was a drop-in. 2) What patches (permanent) are worth adding to upstream, to fix deficiencies in the usability of upstream when compared to what cygwin has. OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. Hi, I will create a branch for cygwin. I think that for temporary and redundant options it may be better to silently accept them and not document them. Existing scripts will not break, but usage of temporary options is discouraged and it saves work on translations. Usage of such an option may even trigger a warning that it will be removed in a future release. Then people have time to adapt. Useful options will end up in trunk. In the end there will be a single source for Cygwin and Linux, and both will take advantage of it. With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. Standby... Do you want d2u/u2d to run conv, or the new dos2unix/unix2dos? Erwin -- 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
Re: ITP dos2unix 5.2.1-1
On 3/17/2011 4:36 PM, Charles Wilson wrote: OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. Fair warning: I've developed this patch set, and made a cygport-based package...but I have NOT TESTED the apps at all. More later, but it's way past my bed time... The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch === 01-avoid-hardlink-exist-error.patch Makefile |2 ++ 1 file changed, 2 insertions(+) === 02-cygwin-defines-win32-but-isnt.patch dos2unix.c | 10 +- unix2dos.c | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) === 03-add--safe-option.patch dos2unix.c |3 +++ unix2dos.c |3 +++ 2 files changed, 6 insertions(+) === 04-add-follow-no-follow--infile-only.patch dos2unix.c | 25 ++--- unix2dos.c | 25 ++--- 2 files changed, 44 insertions(+), 6 deletions(-) === 05-rationalize-logic-flow.patch dos2unix.c | 27 --- unix2dos.c | 27 --- 2 files changed, 32 insertions(+), 22 deletions(-) === 06-add-ResolveSymbolicLink-function.patch dos2unix.c | 94 ++ unix2dos.c | 94 ++ 2 files changed, 188 insertions(+) === 07-support-follow-no-follow--outfile.patch dos2unix.c | 72 +-- unix2dos.c | 72 +-- 2 files changed, 132 insertions(+), 12 deletions(-) === 08-use-canonicalize-file-name-glibc24-cygwin17.patch dos2unix.c | 13 + unix2dos.c | 13 + 2 files changed, 26 insertions(+) Assuming they work (natch) I think these are suitable for upstream. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. === dos2unix-5.2.1-1.src.patch dos2unix.c |2 +- unix2dos.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Obviously, this one would eventually disappear, and would never go upstream. Then, of course, there's the purely packaging related patch: === dos2unix-5.2.1-1.cygwin.patch dos2unix.README | 95 setup.hint |7 2 files changed, 102 insertions(+) With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. cygport script handles this. So... http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1.tar.bz2 ...but be warned...ZERO testing so far. -- 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
Re: ITP dos2unix 5.2.1-1
Op 18-3-2011 7:53, Charles Wilson schreef: On 3/17/2011 4:36 PM, Charles Wilson wrote: OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. Fair warning: I've developed this patch set, and made a cygport-based package...but I have NOT TESTED the apps at all. More later, but it's way past my bed time... The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch === 01-avoid-hardlink-exist-error.patch Makefile |2 ++ 1 file changed, 2 insertions(+) === 02-cygwin-defines-win32-but-isnt.patch dos2unix.c | 10 +- unix2dos.c | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) === 03-add--safe-option.patch dos2unix.c |3 +++ unix2dos.c |3 +++ 2 files changed, 6 insertions(+) === 04-add-follow-no-follow--infile-only.patch dos2unix.c | 25 ++--- unix2dos.c | 25 ++--- 2 files changed, 44 insertions(+), 6 deletions(-) === 05-rationalize-logic-flow.patch dos2unix.c | 27 --- unix2dos.c | 27 --- 2 files changed, 32 insertions(+), 22 deletions(-) === 06-add-ResolveSymbolicLink-function.patch dos2unix.c | 94 ++ unix2dos.c | 94 ++ 2 files changed, 188 insertions(+) === 07-support-follow-no-follow--outfile.patch dos2unix.c | 72 +-- unix2dos.c | 72 +-- 2 files changed, 132 insertions(+), 12 deletions(-) === 08-use-canonicalize-file-name-glibc24-cygwin17.patch dos2unix.c | 13 + unix2dos.c | 13 + 2 files changed, 26 insertions(+) Assuming they work (natch) I think these are suitable for upstream. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. === dos2unix-5.2.1-1.src.patch dos2unix.c |2 +- unix2dos.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Obviously, this one would eventually disappear, and would never go upstream. Then, of course, there's the purely packaging related patch: === dos2unix-5.2.1-1.cygwin.patch dos2unix.README | 95 setup.hint |7 2 files changed, 102 insertions(+) With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. cygport script handles this. So... http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1.tar.bz2 ...but be warned...ZERO testing so far. Hi Chuck, Thank you very much for your hard work! I will have a look at it and do some testing. Erwin -- 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
Re: ITP dos2unix 5.2.1-1
On 3/18/2011 2:47 AM, Erwin Waterlander wrote: I will create a branch for cygwin. I think that for temporary and redundant options it may be better to silently accept them and not document them. We are still not communicating. I do NOT propose that the new options -- whether you call the redundant or not -- be temporary or cygwin specific. I propose that they be adopted, wholesale, for all platforms. I think the --follow option is a valuable alternate behavior that is different and distinct from anything the current option set allows. I believe --no-follow and --safe, being opposites of the new option and and existing option, respectively, are necessary for proper CLI design. Just like rm has both -i and -f. The ONLY part that I propose be temporary, and /NOT/ be committed to any source repository anyway, and simply carried as part of the cygwin packaging until no longer needed, is the bit that switches the default behavior on cygwin from --no-follow (as everywhere else) to --follow. Existing scripts will not break, but usage of temporary options is discouraged and it saves work on translations. Usage of such an option may even trigger a warning that it will be removed in a future release. Then people have time to adapt. Since I propose that the new options all stay, and propagate, I realize this means extra translation work. I'm not qualified for that, but I CAN cut-n-paste in all the translations those that correspond to new lines of code which were themselves cut-n-pasted from existing lines of code (several of the new error messages are cut-n-paste like this). I didn't have time to do this last night, and I can't help with the entirely new tranlatable strings, but I figured code first, .pot files later. In discussing these: 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch ignore the fact that some were developed to mimic cygutils' existing behavior. Some are just plan bugfixes (01, 02). One (05) is an attempt to make the code flow in *NewFile() and *OldFile() similar (and bugfix: set error retval even when Quiet, if there's an error). The rest (03, 04, 06-08) add new and IMO valuable options to the dos2unix package without changing current behavior. Don't bother with a special cygwin-only branch. Let's just discuss these patches, for trunk, on their own merits. BTW, do you have a more appropriate forum for those discussions, than this mailing list? A dedicated list or something? Useful options will end up in trunk. In the end there will be a single source for Cygwin and Linux, and both will take advantage of it. As I said, I see no need for a branch, that differs from trunk only by: - pFlag-Follow = 0; + pFlag-Follow = 1; in two places. With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. Standby... Do you want d2u/u2d to run conv, or the new dos2unix/unix2dos? The new versions. -- 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
Re: ITP dos2unix 5.2.1-1
On Wed, 2011-03-16 at 17:38 -0400, Charles Wilson wrote: So: I don't see any insurmountable problems with entirely replacing cygutils' unix2dos/dos2unix/u2d/d2u programs with these other versions. (I would hope that cygwin's package would provide a u2d.exe hardlinked to unix2dos.exe, etc) +1 Yaakov
Re: ITP dos2unix 5.2.1-1
On 03/16/2011 10:38 PM, Charles Wilson wrote:
Moved to main cygwin list for more feedback.
Background: currently the following utilities
unix2dos
dos2unix
u2d
d2u
are all provided by the cygutils package. They are, in fact, all
hardlinks/copies of the same 'conv.exe' program, developed specifically
for cygwin.
We have a proposal to provide the dos2unix package instead, and
removing these utilities from cygutils. For more info, see:
http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html
and following.
On 3/16/2011 4:18 PM, Christopher Faylor wrote:
Ah, right.
I didn't get that Eric was referring to this scenario but, regardless,
I should have remembered that alternatives means using symlinks. Given
the use that d2u is put, I don't think we want to make it a symlink.
So, I guess that means that we poll the community if we want to go ahead
with this. Either that or the binaries in the new package are given a
different name to avoid conflicts.
Given that the unix2dos package supports pipe operation, the only real
difference is the command line options (and following symlinks on
converted files).
So, compare:
unix2dos 5.1.1 (2010-08-18)
Usage: unix2dos [-fhkLlqV] [-c convmode] [-o file ...] [-n infile
outfile ...]
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
That is an old version. Here is the latest:
dos2unix 5.2.1 (2011-03-04)
Usage: dos2unix [options] [file ...] [-n infile outfile ...]
-ascii convert only line breaks (default)
-iso conversion between DOS and ISO-8859-1 character set
-1252 Use Windows code page 1252 (Western European)
-437 Use DOS code page 437 (US) (default)
-850 Use DOS code page 850 (Western European)
-860 Use DOS code page 860 (Portuguese)
-863 Use DOS code page 863 (French Canadian)
-865 Use DOS code page 865 (Nordic)
-7 Convert 8 bit characters to 7 bit space
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
vs.
unix2dos is part of cygutils version 1.4.4
converts the line endings of text files from
UNIX style (0x0a) to DOS style (0x0d 0x0a)
Usage: unix2dos [OPTION...] [input file list...]
Main options (not all may apply)
-A, --auto Output format will be the opposite of the autodetected
source
format
-D, --u2d Output will be in DOS format
--unix2dos Output will be in DOS format
-U, --d2u Output will be in UNIX format
--dos2unix Output will be in UNIX format
--forceIgnore binary file detection
--safe Do not modify binary files
Help options
-?, --help Show this help message
--usageDisplay brief usage message
--version Display version information
--license Display licensing information
Other arguments
[input file list...] for each file listed, convert in place.
If none specified, then use stdin/stdout
Now, of the cygutils options, we don't need
-D, --u2d, --unix2dos
-U, --d2u, --dos2unix
because...those really only apply to the generic 'conv.exe' application.
cygutils' unix2dos app is really only supposed to be used in, well,
unix2dos mode! So, unix2dos explicitly disallows the use of the
opposite options (--dos2unix etc) and --auto; similarly dos2unix:
if (progtype == CT_UNIX2DOS) {
if (opts.ConvType != CT_UNIX2DOS) {
fprintf(stderr,
%s: cannot accept any conversion
Re: ITP dos2unix 5.2.1-1
On 03/16/2011 10:38 PM, Charles Wilson wrote:
Moved to main cygwin list for more feedback.
Background: currently the following utilities
unix2dos
dos2unix
u2d
d2u
are all provided by the cygutils package. They are, in fact, all
hardlinks/copies of the same 'conv.exe' program, developed specifically
for cygwin.
We have a proposal to provide the dos2unix package instead, and
removing these utilities from cygutils. For more info, see:
http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html
and following.
On 3/16/2011 4:18 PM, Christopher Faylor wrote:
Ah, right.
I didn't get that Eric was referring to this scenario but, regardless,
I should have remembered that alternatives means using symlinks. Given
the use that d2u is put, I don't think we want to make it a symlink.
So, I guess that means that we poll the community if we want to go ahead
with this. Either that or the binaries in the new package are given a
different name to avoid conflicts.
Given that the unix2dos package supports pipe operation, the only real
difference is the command line options (and following symlinks on
converted files).
So, compare:
unix2dos 5.1.1 (2010-08-18)
Usage: unix2dos [-fhkLlqV] [-c convmode] [-o file ...] [-n infile
outfile ...]
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
That is an old version. Here is the latest:
dos2unix 5.2.1 (2011-03-04)
Usage: dos2unix [options] [file ...] [-n infile outfile ...]
-ascii convert only line breaks (default)
-iso conversion between DOS and ISO-8859-1 character set
-1252 Use Windows code page 1252 (Western European)
-437 Use DOS code page 437 (US) (default)
-850 Use DOS code page 850 (Western European)
-860 Use DOS code page 860 (Portuguese)
-863 Use DOS code page 863 (French Canadian)
-865 Use DOS code page 865 (Nordic)
-7 Convert 8 bit characters to 7 bit space
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
vs.
unix2dos is part of cygutils version 1.4.4
converts the line endings of text files from
UNIX style (0x0a) to DOS style (0x0d 0x0a)
Usage: unix2dos [OPTION...] [input file list...]
Main options (not all may apply)
-A, --auto Output format will be the opposite of the autodetected
source
format
-D, --u2d Output will be in DOS format
--unix2dos Output will be in DOS format
-U, --d2u Output will be in UNIX format
--dos2unix Output will be in UNIX format
--forceIgnore binary file detection
--safe Do not modify binary files
Help options
-?, --help Show this help message
--usageDisplay brief usage message
--version Display version information
--license Display licensing information
Other arguments
[input file list...] for each file listed, convert in place.
If none specified, then use stdin/stdout
Now, of the cygutils options, we don't need
-D, --u2d, --unix2dos
-U, --d2u, --dos2unix
because...those really only apply to the generic 'conv.exe' application.
cygutils' unix2dos app is really only supposed to be used in, well,
unix2dos mode! So, unix2dos explicitly disallows the use of the
opposite options (--dos2unix etc) and --auto; similarly dos2unix:
if (progtype == CT_UNIX2DOS) {
if (opts.ConvType != CT_UNIX2DOS) {
fprintf(stderr,
%s: cannot accept any conversion
Re: ITP dos2unix 5.2.1-1
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
Re: ITP dos2unix 5.2.1-1
Moved to main cygwin list for more feedback. Background: currently the following utilities unix2dos dos2unix u2d d2u are all provided by the cygutils package. They are, in fact, all hardlinks/copies of the same 'conv.exe' program, developed specifically for cygwin. We have a proposal to provide the dos2unix package instead, and removing these utilities from cygutils. For more info, see: http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html and following. Personally I'd rather have the same tool in Cygwin as in Linux, because it maximizes the portability of my (common) shell startup scripts and aliases. Changing those one time to eliminate a special case is no problem. That said, this isn't a tool I have to use much, so my investment in it is pretty light. -- 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
Re: ITP dos2unix 5.2.1-1
On 03/17/2011 02:32 PM, Charles Wilson wrote: Dropped cygwin-apps. 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. Hi Chuck, 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. 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. Erwin -- 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
Re: ITP dos2unix 5.2.1-1
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=CP' 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
Re: ITP dos2unix 5.2.1-1
On Thu, Mar 17, 2011 at 10:13:51AM -0400, Andrew Schulman wrote: Moved to main cygwin list for more feedback. Background: currently the following utilities unix2dos dos2unix u2d d2u are all provided by the cygutils package. They are, in fact, all hardlinks/copies of the same 'conv.exe' program, developed specifically for cygwin. We have a proposal to provide the dos2unix package instead, and removing these utilities from cygutils. For more info, see: http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html and following. Personally I'd rather have the same tool in Cygwin as in Linux, because it maximizes the portability of my (common) shell startup scripts and aliases. Changing those one time to eliminate a special case is no problem. That said, this isn't a tool I have to use much, so my investment in it is pretty light. We're really looking for specific observations here not general. We're trying not to break things for people who already are used to the Cygwin behavior. Are you saying that you've actually had to modify scripts because of differences in behavior between Cygwin and Linux's dos2unix? If so, that actually sounds like you've made accommodations which could break if dos2unix were to change. cgf -- 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
Re: ITP dos2unix 5.2.1-1
Op 17-3-2011 17:57, Charles Wilson schreef: 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: --followfollow 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? Hi Chuck, I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. best regards, Erwin -- 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
Re: ITP dos2unix 5.2.1-1
On 03/17/2011 03:56 PM, Erwin Waterlander wrote: Op 17-3-2011 17:57, Charles Wilson schreef: 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: --followfollow 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-followdo 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? Hi Chuck, I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. My 2cents worth: I for one look forward to the new package. All of the software we develop runs on both platforms and I personally use the dos2unix, etc tools often. Same tools on both platforms gets my vote anytime. roger wells best regards, Erwin -- 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 -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@saic.com -- 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
Re: ITP dos2unix 5.2.1-1
On 03/17/2011 01:56 PM, Erwin Waterlander wrote: So let's rephrase: What is the upstream objection to providing a few new options, with no change in upstream's current default behavior: I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. There's two sets of patches being talked about here: 1) What temporary (3-month?) patches are needed to make the dos2unix package a drop-in replacement to the existing cygwin dos2unix, so that people can start testing if it really was a drop-in. 2) What patches (permanent) are worth adding to upstream, to fix deficiencies in the usability of upstream when compared to what cygwin has. But having re-read this conversation, my original objection based on duplication of effort seems pretty weak; you've convinced me that the biggest reason to switch to dos2unix is that it has more features. However, I say that with reservation - I agree with Chuck that you need a transition period where we make the switch but preserve cygwin behavior, to minimize the variables. I'm definitely in agreement with making a phased switch to the upstream package. My personal habits are 'd2u file', without regards to the message it prints. So I definitely want the d2u shortcut to be part of the package (it apparently is not provided by upstream, and I'm too used to 'ln -s `which dos2unix` ~/bin/d2u' when installing a new machine). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: ITP dos2unix 5.2.1-1
On 3/17/2011 4:08 PM, Eric Blake wrote: On 03/17/2011 01:56 PM, Erwin Waterlander wrote: I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. There's two sets of patches being talked about here: 1) What temporary (3-month?) patches are needed to make the dos2unix package a drop-in replacement to the existing cygwin dos2unix, so that people can start testing if it really was a drop-in. 2) What patches (permanent) are worth adding to upstream, to fix deficiencies in the usability of upstream when compared to what cygwin has. OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. Standby... -- 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
Re: ITP dos2unix 5.2.1-1
On 03/15/2011 11:17 PM, Eric Blake wrote: dos2unix is already part of cygwin. 'cygcheck -p dos2unix' shows that it is part of cygutils, so I see no reason to repackage it as an alternative build. Hi, dos2unix on cygwin is different, it is 'conv'. The implementation I propose is used on major Linux distributions. You could keep 'conv' on cygwin. I propose to obsolete the links dos2unix and unix2dos to conv, and replace them with the dos2unix implementation as used on Linux. Erwin
Re: ITP dos2unix 5.2.1-1
On 3/16/2011 3:59 AM, Erwin Waterlander wrote: dos2unix on cygwin is different, it is 'conv'. The implementation I propose is used on major Linux distributions. You could keep 'conv' on cygwin. I propose to obsolete the links dos2unix and unix2dos to conv, and replace them with the dos2unix implementation as used on Linux. Then you're going to have to explain why the other implementation is better (not just but that's the one the linux people use: cygwin is not linux) AND ensure that the new version is capable of ALL the modes of operation that the old version supports. Otherwise, you may break people's existing usage patterns. Offhand, I can think of several (there might be more): * The --safe and --force options * The ability to operate as part of a pipe (stdin/stdout) * --auto mode (with 3 formats, dos/unix/mac, there is no opposite) but that doesn't really matter for the explicit d2u/u2d variants. Only 'conv' needs to worry about --auto) Now, I'm not opposed to removing u2d/d2u/dos2unix/unix2dos from cygutils. Less apps to support makes life easier for me. I just don't want to break anyone's existing setup, usage patterns, or scripts. -- Chuck cygutils maintainer
Re: ITP dos2unix 5.2.1-1
On 03/16/2011 02:52 PM, Charles Wilson wrote: Then you're going to have to explain why the other implementation is better (not just but that's the one the linux people use: cygwin is Hi Chuck, I think it's a good argument. Most cygwin programs are ported from Unix/Linux. Scripts that come from Linux don't need to be modified for dos2unix any more with the version I propose. Quota from http://cygwin.com Cygwin is: * a collection of tools which provide a Linux look and feel environment for Windows. not linux) AND ensure that the new version is capable of ALL the modes of operation that the old version supports. Otherwise, you may break people's existing usage patterns. Offhand, I can think of several (there might be more): * The --safe and --force options Dos2unix is by default safe, with an option to force conversion. * The ability to operate as part of a pipe (stdin/stdout) Yes. And in-place and paired conversion. * --auto mode (with 3 formats, dos/unix/mac, there is no opposite) but that doesn't really matter for the explicit d2u/u2d variants. Only 'conv' needs to worry about --auto) There is no auto mode. But dos/unix/mac conversion is supported. I propose to keep 'conv'. So people who like conv's auto mode can still use it. Additional features: * keep file date. * ISO and 7bit conversion like on SunOS * Internationalisation. Now, I'm not opposed to removing u2d/d2u/dos2unix/unix2dos from cygutils. Less apps to support makes life easier for me. I just don't want to break anyone's existing setup, usage patterns, or scripts. The command-line options are not compatible, but the difference is not very big. Most people will use it without options I guess. It depends on what you are used to. If you come from Linux or Cygwin. best regards, Erwin
Re: ITP dos2unix 5.2.1-1
On Wed, Mar 16, 2011 at 03:52:36PM +0100, Erwin Waterlander wrote: On 03/16/2011 02:52 PM, Charles Wilson wrote: Then you're going to have to explain why the other implementation is better (not just but that's the one the linux people use: cygwin is Hi Chuck, I think it's a good argument. Most cygwin programs are ported from Unix/Linux. Scripts that come from Linux don't need to be modified for dos2unix any more with the version I propose. It's only a good argument if you can point to messages where people have been demonstrably confused or have needed to change scripts to deal with different behavior. Quota from http://cygwin.com Cygwin is: * a collection of tools which provide a Linux look and feel environment for Windows. That is true but these tools have been in the distro for years and I don't recall any complaints. That argues for a pragmatic it's not broke philosophy. * --auto mode (with 3 formats, dos/unix/mac, there is no opposite) but that doesn't really matter for the explicit d2u/u2d variants. Only 'conv' needs to worry about --auto) There is no auto mode. But dos/unix/mac conversion is supported. I propose to keep 'conv'. So people who like conv's auto mode can still use it. cygwin-apps comprises only a limited subset of people who could be using these tools. We shouldn't just resolve to change behavior. If it is decided that this is something that needs to be addressed then we'll have to poll the community. Additional features: * keep file date. * ISO and 7bit conversion like on SunOS * Internationalisation. Now, I'm not opposed to removing u2d/d2u/dos2unix/unix2dos from cygutils. Less apps to support makes life easier for me. I just don't want to break anyone's existing setup, usage patterns, or scripts. The command-line options are not compatible, but the difference is not very big. Most people will use it without options I guess. It depends on what you are used to. If you come from Linux or Cygwin. This is, again, something that you can't assume. We don't know how people use these tools. So, if we do decide to make the switch, you will have to be dedicated to being active in responding to problem reports on the mailing list. And, if people here think it's a good idea to move this along, we'll need to get some feedback from the larger community. cgf
Re: ITP dos2unix 5.2.1-1
On 03/16/2011 04:49 PM, Christopher Faylor wrote: This is, again, something that you can't assume. We don't know how people use these tools. So, if we do decide to make the switch, you will have to be dedicated to being active in responding to problem reports on the mailing list. And, if people here think it's a good idea to move this along, we'll need to get some feedback from the larger community. I'm fine with that. I made this package, because a cygwin user asked me. For me it's a small effort to maintain a cygwin package for this. I am committed to solve problems. If the cygwin community doesn't want to switch, that's fine too. Erwin
Re: ITP dos2unix 5.2.1-1
Erwin Waterlander wrote: On 03/16/2011 04:49 PM, Christopher Faylor wrote: This is, again, something that you can't assume. We don't know how people use these tools. So, if we do decide to make the switch, you will have to be dedicated to being active in responding to problem reports on the mailing list. And, if people here think it's a good idea to move this along, we'll need to get some feedback from the larger community. I'm fine with that. I made this package, because a cygwin user asked me. For me it's a small effort to maintain a cygwin package for this. I am committed to solve problems. If the cygwin community doesn't want to switch, that's fine too. An alternative would be to modify cygutils+dos2unix packages such that the user can select the flavor of dos2unix/unix2dos commands with /usr/sbin/alternatives. If cygutils is the default if installed this should not break anything. Christian
Re: ITP dos2unix 5.2.1-1
On Wed, Mar 16, 2011 at 08:29:51PM +0100, Christian Franke wrote: Erwin Waterlander wrote: On 03/16/2011 04:49 PM, Christopher Faylor wrote: This is, again, something that you can't assume. We don't know how people use these tools. So, if we do decide to make the switch, you will have to be dedicated to being active in responding to problem reports on the mailing list. And, if people here think it's a good idea to move this along, we'll need to get some feedback from the larger community. I'm fine with that. I made this package, because a cygwin user asked me. For me it's a small effort to maintain a cygwin package for this. I am committed to solve problems. If the cygwin community doesn't want to switch, that's fine too. An alternative would be to modify cygutils+dos2unix packages such that the user can select the flavor of dos2unix/unix2dos commands with /usr/sbin/alternatives. If cygutils is the default if installed this should not break anything. Hey, good idea, assuming that Chuck is amenable. I'd be happy to just let the package in given that proviso if so. cgf
Re: ITP dos2unix 5.2.1-1
On 3/16/2011 3:32 PM, Christopher Faylor wrote: On Wed, Mar 16, 2011 at 08:29:51PM +0100, Christian Franke wrote: An alternative would be to modify cygutils+dos2unix packages such that the user can select the flavor of dos2unix/unix2dos commands with /usr/sbin/alternatives. If cygutils is the default if installed this should not break anything. Except you would no longer be able to run dos2unix/unix2dos/d2u/u2d from a non-cygwin context, such as 'naked' cmd.exe or some IDE like Eclipse. Hey, good idea, assuming that Chuck is amenable. I'd be happy to just let the package in given that proviso if so. Uh, let's think about that a minute. cygutils is pulled in as part of Base (cygutils is not in the Base category, but it is required by a packages that is: cygwin-doc). Adding alternatives as a dep of cygutils would then make alternatives an implicit part of Base. alternatives itself brings in no other unsavory dependencies. This would be a change, since although alternatives is used by some very common packages [vim, automake], it's not in the default Base-only (actually, Base+requirements) installation. It also means that cygwin's dos2unix could no longer be executed from a non-cygwin context, because of the symlinks. Finally, Eric Blake already referenced this possibility, I think: I see no reason to repackage it as an alternative build. If everybody else is ok with that, then I have no objections...but I think we should hear from folks about these (possible) issues before making a decision. -- Chuck
Re: ITP dos2unix 5.2.1-1
On Wed, Mar 16, 2011 at 04:05:17PM -0400, Charles Wilson wrote: On 3/16/2011 3:32 PM, Christopher Faylor wrote: On Wed, Mar 16, 2011 at 08:29:51PM +0100, Christian Franke wrote: An alternative would be to modify cygutils+dos2unix packages such that the user can select the flavor of dos2unix/unix2dos commands with /usr/sbin/alternatives. If cygutils is the default if installed this should not break anything. Except you would no longer be able to run dos2unix/unix2dos/d2u/u2d from a non-cygwin context, such as 'naked' cmd.exe or some IDE like Eclipse. Hey, good idea, assuming that Chuck is amenable. I'd be happy to just let the package in given that proviso if so. Uh, let's think about that a minute. cygutils is pulled in as part of Base (cygutils is not in the Base category, but it is required by a packages that is: cygwin-doc). Adding alternatives as a dep of cygutils would then make alternatives an implicit part of Base. alternatives itself brings in no other unsavory dependencies. This would be a change, since although alternatives is used by some very common packages [vim, automake], it's not in the default Base-only (actually, Base+requirements) installation. It also means that cygwin's dos2unix could no longer be executed from a non-cygwin context, because of the symlinks. Finally, Eric Blake already referenced this possibility, I think: I see no reason to repackage it as an alternative build. If everybody else is ok with that, then I have no objections...but I think we should hear from folks about these (possible) issues before making a decision. Ah, right. I didn't get that Eric was referring to this scenario but, regardless, I should have remembered that alternatives means using symlinks. Given the use that d2u is put, I don't think we want to make it a symlink. So, I guess that means that we poll the community if we want to go ahead with this. Either that or the binaries in the new package are given a different name to avoid conflicts. cgf
Re: ITP dos2unix 5.2.1-1
Christopher Faylor wrote: On Wed, Mar 16, 2011 at 04:05:17PM -0400, Charles Wilson wrote: On 3/16/2011 3:32 PM, Christopher Faylor wrote: On Wed, Mar 16, 2011 at 08:29:51PM +0100, Christian Franke wrote: An alternative would be to modify cygutils+dos2unix packages such that the user can select the flavor of dos2unix/unix2dos commands with /usr/sbin/alternatives. If cygutils is the default if installed this should not break anything. Except you would no longer be able to run dos2unix/unix2dos/d2u/u2d from a non-cygwin context, such as 'naked' cmd.exe or some IDE like Eclipse. Hey, good idea, assuming that Chuck is amenable. I'd be happy to just let the package in given that proviso if so. Uh, let's think about that a minute. cygutils is pulled in as part of Base (cygutils is not in the Base category, but it is required by a packages that is: cygwin-doc). Adding alternatives as a dep of cygutils would then make alternatives an implicit part of Base. alternatives itself brings in no other unsavory dependencies. This would be a change, since although alternatives is used by some very common packages [vim, automake], it's not in the default Base-only (actually, Base+requirements) installation. It also means that cygwin's dos2unix could no longer be executed from a non-cygwin context, because of the symlinks. ... Ah, right. I didn't get that Eric was referring to this scenario but, regardless, I should have remembered that alternatives means using symlinks. Given the use that d2u is put, I don't think we want to make it a symlink. Agree, symlinks should be avoided. Another alternative: Keep hard links as is if cygutils is installed only. If dos2unix is also installed assume that user opted-in to replace the dos2unix and unix2dos commands (and only these) with the linux variant. Undo this change if dos2unix is uninstalled. This may be possible to handle this in the postinstall/preremove scripts of both packages as follows (dos2unix case only, not tested): cygutils*.tar: remove dosunix2.exe but keep d2u.exe. dosunix*.tar: Install dos2unix.exe as e.g. dos2unix-linux.exe # /etc/postinstall/cygutils.sh: if cmp -s /usr/bin/dos2unix-linux.exe /usr/bin/dos2unix.exe; then :; else ln -f /usr/bin/conv.exe /usr/bin/dos2unix.exe fi # /etc/preremove/cygutils.sh: if cmp -s /usr/bin/conv.exe /usr/bin/dos2unix.exe; then rm -f /usr/bin/dos2unix.exe fi # /etc/postinstall/dos2unix.sh: ln -f /usr/bin/dos2unix-linux.exe /usr/bin/dos2unix.exe # /etc/preremove/dos2unix.sh: if cmp -s /usr/bin/dos2unix-linux.exe /usr/bin/dos2unix.exe; then if test -f /usr/bin/conv.exe; then ln -f /usr/bin/conv.exe /usr/bin/dos2unix.exe else rm -f /usr/bin/dos2unix.exe fi fi Christian
Re: ITP dos2unix 5.2.1-1
Moved to main cygwin list for more feedback.
Background: currently the following utilities
unix2dos
dos2unix
u2d
d2u
are all provided by the cygutils package. They are, in fact, all
hardlinks/copies of the same 'conv.exe' program, developed specifically
for cygwin.
We have a proposal to provide the dos2unix package instead, and
removing these utilities from cygutils. For more info, see:
http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html
and following.
On 3/16/2011 4:18 PM, Christopher Faylor wrote:
Ah, right.
I didn't get that Eric was referring to this scenario but, regardless,
I should have remembered that alternatives means using symlinks. Given
the use that d2u is put, I don't think we want to make it a symlink.
So, I guess that means that we poll the community if we want to go ahead
with this. Either that or the binaries in the new package are given a
different name to avoid conflicts.
Given that the unix2dos package supports pipe operation, the only real
difference is the command line options (and following symlinks on
converted files).
So, compare:
unix2dos 5.1.1 (2010-08-18)
Usage: unix2dos [-fhkLlqV] [-c convmode] [-o file ...] [-n infile
outfile ...]
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
vs.
unix2dos is part of cygutils version 1.4.4
converts the line endings of text files from
UNIX style (0x0a) to DOS style (0x0d 0x0a)
Usage: unix2dos [OPTION...] [input file list...]
Main options (not all may apply)
-A, --auto Output format will be the opposite of the autodetected
source
format
-D, --u2d Output will be in DOS format
--unix2dos Output will be in DOS format
-U, --d2u Output will be in UNIX format
--dos2unix Output will be in UNIX format
--forceIgnore binary file detection
--safe Do not modify binary files
Help options
-?, --help Show this help message
--usageDisplay brief usage message
--version Display version information
--license Display licensing information
Other arguments
[input file list...] for each file listed, convert in place.
If none specified, then use stdin/stdout
Now, of the cygutils options, we don't need
-D, --u2d, --unix2dos
-U, --d2u, --dos2unix
because...those really only apply to the generic 'conv.exe' application.
cygutils' unix2dos app is really only supposed to be used in, well,
unix2dos mode! So, unix2dos explicitly disallows the use of the
opposite options (--dos2unix etc) and --auto; similarly dos2unix:
if (progtype == CT_UNIX2DOS) {
if (opts.ConvType != CT_UNIX2DOS) {
fprintf(stderr,
%s: cannot accept any conversion type argument other\n \
Similarly, we don't need
-A, --auto
because, again, it really only makes sense for the generic conv.exe app
(and u2d/d2u/etc explicitly disallow its use).
All that leaves are the informational options (--help, -?, --usage,
--version, --license) which, if they go missing or renamed, I doubt that
will break any scripts.
Finally, we have
--forceIgnore binary file detection
--safe Do not modify binary files
All of cygutils' conversion progs operate in safe mode by default, so
the --safe option is a bit redundant (it was added so that if somebody
aliased unix2dos as 'unix2dos --force', they could override on the cmd
line using --safe if necessary).
The proposed package provides a similar --force option, but no --safe.
So, the only real issues are
1) somebody is (redundantly) specifying --safe
2) how does the unix2dos binary detection algorithm differ
from cygutils'?
3) Does the unix2dos package handle setmode() on stdio properly?
4) Ditto for O_BINARY on physical files?
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
6) dos2unix foo.h foo.c (cygutils), but
Re: ITP dos2unix 5.2.1-1
Moved to main cygwin list for more feedback.
Background: currently the following utilities
unix2dos
dos2unix
u2d
d2u
are all provided by the cygutils package. They are, in fact, all
hardlinks/copies of the same 'conv.exe' program, developed specifically
for cygwin.
We have a proposal to provide the dos2unix package instead, and
removing these utilities from cygutils. For more info, see:
http://cygwin.com/ml/cygwin-apps/2011-03/msg00067.html
and following.
On 3/16/2011 4:18 PM, Christopher Faylor wrote:
Ah, right.
I didn't get that Eric was referring to this scenario but, regardless,
I should have remembered that alternatives means using symlinks. Given
the use that d2u is put, I don't think we want to make it a symlink.
So, I guess that means that we poll the community if we want to go ahead
with this. Either that or the binaries in the new package are given a
different name to avoid conflicts.
Given that the unix2dos package supports pipe operation, the only real
difference is the command line options (and following symlinks on
converted files).
So, compare:
unix2dos 5.1.1 (2010-08-18)
Usage: unix2dos [-fhkLlqV] [-c convmode] [-o file ...] [-n infile
outfile ...]
-c --convmodeconversion mode
convmode ascii, 7bit, iso, mac, default to ascii
-f --force force conversion of all files
-h --helpgive this help
-k --keepdatekeep output file date
-L --license display software license
-l --newline add additional newline
-n --newfile write to new file
infile original file in new file mode
outfileoutput file in new file mode
-o --oldfile write to old file
file ... files to convert in old file mode
-q --quiet quiet mode, suppress all warnings
always on in stdio mode
-V --version display version number
vs.
unix2dos is part of cygutils version 1.4.4
converts the line endings of text files from
UNIX style (0x0a) to DOS style (0x0d 0x0a)
Usage: unix2dos [OPTION...] [input file list...]
Main options (not all may apply)
-A, --auto Output format will be the opposite of the autodetected
source
format
-D, --u2d Output will be in DOS format
--unix2dos Output will be in DOS format
-U, --d2u Output will be in UNIX format
--dos2unix Output will be in UNIX format
--forceIgnore binary file detection
--safe Do not modify binary files
Help options
-?, --help Show this help message
--usageDisplay brief usage message
--version Display version information
--license Display licensing information
Other arguments
[input file list...] for each file listed, convert in place.
If none specified, then use stdin/stdout
Now, of the cygutils options, we don't need
-D, --u2d, --unix2dos
-U, --d2u, --dos2unix
because...those really only apply to the generic 'conv.exe' application.
cygutils' unix2dos app is really only supposed to be used in, well,
unix2dos mode! So, unix2dos explicitly disallows the use of the
opposite options (--dos2unix etc) and --auto; similarly dos2unix:
if (progtype == CT_UNIX2DOS) {
if (opts.ConvType != CT_UNIX2DOS) {
fprintf(stderr,
%s: cannot accept any conversion type argument other\n \
Similarly, we don't need
-A, --auto
because, again, it really only makes sense for the generic conv.exe app
(and u2d/d2u/etc explicitly disallow its use).
All that leaves are the informational options (--help, -?, --usage,
--version, --license) which, if they go missing or renamed, I doubt that
will break any scripts.
Finally, we have
--forceIgnore binary file detection
--safe Do not modify binary files
All of cygutils' conversion progs operate in safe mode by default, so
the --safe option is a bit redundant (it was added so that if somebody
aliased unix2dos as 'unix2dos --force', they could override on the cmd
line using --safe if necessary).
The proposed package provides a similar --force option, but no --safe.
So, the only real issues are
1) somebody is (redundantly) specifying --safe
2) how does the unix2dos binary detection algorithm differ
from cygutils'?
3) Does the unix2dos package handle setmode() on stdio properly?
4) Ditto for O_BINARY on physical files?
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
6) dos2unix foo.h foo.c (cygutils), but
ITP dos2unix 5.2.1-1
Hi, I propose package 'dos2unix' for cygwin. Dos2unix is part of Fedora, Suse, Debian, Ubuntu, Gentoo, Slackware, and Arch Linux. The homepage is http://www.xs4all.nl/~waterlan/dos2unix.html I have prepared packages which can be downloaded from http://www.xs4all.nl/~waterlan/cygwin/dos2unix/ It is the first time I've created Cygwin packages. Any comment is welcome. There are no patches. It compiles out-of-the-box on Cygwin. There are conflicts with package 'cygutils', which contains utilities dos2unix and unix2dos. These are links to 'conv'. sdesc: DOS/Mac to Unix and vice versa text file format converter ldesc: DOS/Mac to Unix and vice versa text file format converter category: Utils requires: libintl8 libiconv2 cygwin -- Erwin Waterlander Eindhoven
Re: ITP dos2unix 5.2.1-1
On 03/15/2011 04:05 PM, Erwin Waterlander wrote: Hi, I propose package 'dos2unix' for cygwin. Dos2unix is part of Fedora, Suse, Debian, Ubuntu, Gentoo, Slackware, and Arch Linux. The homepage is http://www.xs4all.nl/~waterlan/dos2unix.html dos2unix is already part of cygwin. 'cygcheck -p dos2unix' shows that it is part of cygutils, so I see no reason to repackage it as an alternative build. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
