file name containing newline makes `cvs update' abort

[Jim Meyering]

[this is using both the latest version of cvs from the trunk, updated
 minutes ago, as well as cvs-1.12.9]

Merely creating a file with a newline in its name in any working
directory confuses cvs pretty seriously.  Depending on the type
of server, it can `merely' fail with a cryptic `unrecognized request'
diagnostic, or abort on a failed assertion.

Since the offending code has been in server.c for quite some time,
(and there are even comments about the possibility that such newline-
containing file names could cause trouble), I wonder if this happens
so infrequently that it's not worth addressing the problem.  IMHO,
it should be fixed -- or at least give better diagnostics so that
the user knows how to resolve the problem (simply remove the offending file).

I suggest that you consider encoding the file name by converting
the newline to `\n'.  This cannot break any existing scripts,
since they wouldn't work in any case if there is a file name that
would make a difference.

Here's how to reproduce the failures:

cvs -d /tmp/x init
cvs -d /tmp/x co CVSROOT
cd /tmp/CVSROOT
touch 'a
b'
cvs -n up

Here's what I get for the last command:

  $ cvs -n up
  cvs update: Updating .
  cvs: server.c:7842: cvs_output_tagged: Assertion `0' failed.
  ? cvs [update aborted]: received abort signal
  [Exit 1]

Then, repeat, but with a different checkout method:

cd /tmp
rm -rf CVSROOT
cvs -d :ext:localhost:/tmp/x -Q co CVSROOT
cd CVSROOT
touch 'a
b'
cvs -n up

Now, I get this:

  $ cvs -n up
  ? a
  unrecognized request `b'
  [Exit 1]


----------------------------------------
For your convenience, here's the assert and associated comment:
-----------

  /* Output TEXT, tagging it according to TAG.  There are lots more
   details about what TAG means in cvsclient.texi but for the simple
   case (e.g. non-client/server), TAG is just "newline" to output a
   newline (in which case TEXT must be NULL), and any other tag to
   output normal text.

   Note that there is no way to output either \0 or \n as part of TEXT.  */

void
cvs_output_tagged (const char *tag, const char *text)
{
    if (text != NULL && strchr (text, '\n') != NULL)
        /* Uh oh.  The protocol has no way to cope with this.  For now
           we dump core, although that really isn't such a nice
           response given that this probably can be caused by newlines
           in filenames and other causes other than bugs in CVS.  Note
           that we don't want to turn this into "MT newline" because
           this case is a newline within a tagged item, not a newline
           as extraneous sugar for the user.  */
        assert (0);