DD converts LF -> CR / LF

Eric Blake ebb9@byu.net
Fri May 6 13:27:00 GMT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 5/6/2005 2:06 AM:
> Sebastian Schuberth wrote:
> 
>>my mounts are all text mode, i.e. the "Default Text File
>>Type" is "DOS". Nevertheless, shouldn't
>>
>>dd if=test_unix.txt of=text.txt
>>
>>create an exact copy of "test_unix.txt"? It seems DD doesn't open the
>>file in binary mode
>>
>>I already tried several of the "conv=" arguments to DD with no luck.
> 
> 
> Yeah, that does seem a bit broken.  You can solve that with something
> like the following:
> 
> --- dd.c.orig   2005-05-06 01:03:01.125000000 -0700
> +++ dd.c        2005-05-06 01:00:07.265625000 -0700
> @@ -136,8 +136,12 @@
>  static int conversions_mask = 0;
>  
>  /* Open flags for the input and output files.  */
> -static int input_flags = 0;
> -static int output_flags = 0;
> +#ifndef O_BINARY
> +#define O_BINARY 0
> +#endif
> +
> +static int input_flags = O_BINARY;
> +static int output_flags = O_BINARY;
>  
>  /* Status flags for what is printed to stderr.  */
>  static int status_flags = 0;
> 
> -----
> 
> It would be up to the coreutils maintainer to decide what to do about
> this.  It could be handled in a number of ways.
> 
> Brian
> 

Predefining O_BINARY as the default input_flags and output_flags is a
stopgap measure.  While it is fine for other programs, such as od, to
always open in binary mode, I think that dd should be more flexible as it
already can specify so many other fine-tuning details.  It would be nicer
if iflag= and oflag= supported text and binary as supported flags (no-ops
on platforms where there is no difference).  Or maybe introduce new
keywords imode= and omode=, since it is not clear whether fcntl(fd,
F_SETFL, O_BINARY) will work, or whether modes must be set with
SET_MODE(fd, O_BINARY) from system.h.  Also, since O_BINARY and O_TEXT are
mutually exclusive (when O_BINARY is defined, you can't set the mode to
O_BINARY|O_TEXT), it would add a layer of complication to parsing iflags
to ensure that an incompatible mode is not chosen.

There is still the question on cygwin whether an unspecified text/binary
mode should always default to binary, or should default to the underlying
default for that particular mount.  Meanwhile, I noticed that cygwin
permits open("foo", O_RDWR | O_BINARY | O_TEXT), although I don't know
which of the two modes it chose; I think it should instead return EINVAL
like setmode(fd, O_BINARY | O_TEXT) does.

Here's a cygwin-local patch (against the 5.3.0 tarball) that adds imode=
and omode=, and which defaults to binary mode if unspecified.  I'll try to
release coreutils-5.3.0-6 to cygwin in the next week, including this fix
and a `mkdir -p' fix.  I'm cc'ing bug-coreutils in case it is decided to
be a good idea to use as a starting point for folding in upstream (of
course, it would also need NEWS and coreutils.texi documentation, and
updated to apply against CVS HEAD).

2005-05-06  Eric Blake  <ebb9@byu.net>

	Add imode= and omode= to dd:
	* src/dd.c (input_mode, output_mode, modes, set_fd_mode):
	New variables and method.
	(usage) [O_BINARY]: Document new args.
	(scanargs) [O_BINARY]: Parse new imode and omode args.
	(main): Set file mode.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe3DJ84KuGfSFAYARApZbAKCaEJJqwJ9I2UCXy5HarHMJXKHqSACdFNyN
XurPMrVxdRcFj+cqepzaSnw=
=m/hB
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreutils.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20050506/5835ff38/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


More information about the Cygwin mailing list