Latest release of --files-from patch

jw schultz jw at pegasys.ws
Sat Feb 1 10:53:15 EST 2003


On Fri, Jan 31, 2003 at 10:04:22AM -0800, Wayne Davison wrote:
> On Fri, Jan 31, 2003 at 03:16:43AM -0800, jw schultz wrote:
> > we have several options that accept multiple values from a file
> > and we aren't switching to null termination for them but --null is
> > rather unspecific.
> 
> Yes, I had been thinking a bit about that option as well.  I think I
> would like to go the opposite direction of your suggestion and make
> the option more general, i.e. have it affect both --exclude-from and
> --include-from.  Then we just need to change the name to be clearer.
> I was thinking that "--nulls-in-from" might be a good name.  Any
> suggestions?

If it applies to all lists read i'd stick with --null.
I had thought of that as well. I'm not overly inclined to it
but once you accept the idea that a filename might include
EOL chars it then becomes sensible to allow them in the
patterns.

You'd have to completely rewrite the file reading loop in
exclude.c but it wouldn't be too bad.  Just replace the
fgets with a fgetc loop that does EOR processing on NULL or
on \r and \n.  In some ways the code will look cleaner.

> > It also occurs to me that it might make sense to always transfer
> > the file-list over the network null terminated.
> 
> Doing this means that the sending side need to scan the data instead
> of just transmit it.  It would make the protocol more consistent,
> though, so I'm starting to come around to your way of thinking.

I think of it as data normalization.  A habit of mine is to
normalize the data before processing it.  That tends to
clean up the processing logic by eliminating most of the
exceptions.

In this particular case the absence of --null means "convert
EOL chars to NULL" then you just do normal null termination
processing and discard empty entries.

I just looked again at your patch and the text mode
processing needs adjustment as ffrom_rs isn't designed to
handle alternate forms of line termination as we now expect
such things to do.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt


More information about the rsync mailing list