From: Jan Harkes <jaharkes_at_cs.cmu.edu>
   On Thu, May 13, 2004 at 12:56:07PM -0400, shivers_at_cc.gatech.edu wrote:
   > venus-setup uses some program called codaconfedit. It is not a script; it's a
   > binary. There is no man page for it in the man-page tarball. What is this
   > thing? Does its existence imply that I should fear to hand-edit
   > /etc/coda/venus.conf?

   No, it started off as a script, but had a dependency on 'ed' and I believe
   at the time this was a non-standard binary in the cygwin install. Over
   time it also got more and more functionality, so a small C-program ended
   up being simpler to maintain.

   http://www.coda.cs.cmu.edu/cgi-bin/viewcvs.cgi/coda/coda-src/scripts/Attic/codaconfedit.in

   Hand editing should be fine, we just needed something for the setup
   scripts.

Ahh. Thanks. The reason I asked is that for some reason I don't understand,
the debian package on coda.cs.cmu.edu doesn't install venus-setup. If you
hose yourself and want to reset your setup by means of a venus-setup, you're
out of luck. (Perhaps there's a way to do this with the deb package machinery?
I am not a debian expert.) But the coda documentation is done in terms of
venus-setup, so it seems like it would be a good thing for the deb pkg to
keep the venus-setup script, no?

I read the script on a Red Hat box, trying to understand what it was doing,
came across codaconfedit, and then ran into the brick wall.

   > clog has a detailed useage msg, which it prints out on stderr when it is
   > unhappy. But it's all lies:
   >     ; clog -help
   >     Missing host
   >     Usage clog [-q] [-test] [-h authserver] [{-kerberos4,-kerberos5,-coda}]
   > 	    [-tofile <file>] [-fromfile <file>]
   > 	    [-as username] [Coda username]
   >
   > According to the man page, and this also appears to be the way it actually
   > works, clog really only takes a -x switch. This is quite misleading and
   > would be very easy to fix.

   Never heard of option '-x'. 

The man page states that it's a meaningless switch. But the man page also
states that it is the *only* switch. The 
    -q -test -h -kerberos4 -kerberos5 -coda -tofile -fromfile -as
switches do *not* appear in the man page. Furthermore, the -h switch is
busted in multiple ways. 
  - If you say "-h <host>" as indicated by the useage msg, it blows up:
    % clog -h testserver.coda.cs.cmu.edu shivers
    Usage clog [-q] [-test] [-h authserver] [{-kerberos4,-kerberos5,-coda}]
	    [-tofile <file>] [-fromfile <file>]
	    [-as username] [Coda username]
  - If you try, for variety, "-h<host>", it just appears to ignore the switch:
    % clog -htestserver.coda.cs.cmu.edu shivers
    username: shivers_at_lambda.csail.mit.edu
Any way you slice it, the -h switch handling of clog is way broken.

As for all these other undocumented switches in clog -- they are mystery
switches. Could they be described in the man page?

   Any case, looking at the source it looks like -h is used for the help
   message and -h<anything> is used to match something like -host
   <authserver>.

Strange, because as you can see from the two examples above, that's
not the behavior I see for the "-h<anything>" case.

   > I also note that coda tools are distinguished by their pretty consistently
   > missing the standard --help switch. It would sure be handy to have it.

   Standard? That is a GNUism. As far as I know, the standard getopt
   doesn't even parse the --long options. A lot of the Coda binaries are
   based on stuff that was written somewhere in the 1980's. Coda was
   originally developed on MachOS and NetBSD systems, which do not use the
   GNU libc.

   I can't really find when exactly long options were introduced, but if I
   can believe google, even groff didn't have them until at least April
   2000. Ahhh, I did find it..
       http://groups.google.com/groups?selm=9111142329.AA21815%40mole.gnu.ai.mit.edu

But here in the open-source future, it's a defacto standard & a useful one, and
one that is very easy to make happen.

   > Finally, it seems to me that having "cfs la" error out with a msg about
   > timing out when the true problem is that the client is in disconnected
   > operation is an extremely unfriendly and misleading error msg. Is it
   > impossible to have it report that the client's in disconnected op? (The
   > answer may be "yes;" I'm pretty much a novice here.) A better report
   > would save a lot of user confusion.

   Probably, whenever the RPC layer times out we're always disconnected, so
   the ETIMEDOUT error can probably be caught and replaced by some other
   message.

Maybe this is a misinformed & dumb question. Can cfs distinguish between
being in a WriteDisconnected state and being connected to a catatonic
server? What was weird was that the server was up, functioning properly,
my net connection was working fine, I never did anything to request the
client go into WriteDisconnected state, but it was in that state. And
when I tried to look at my coda filesys, it would fail in a mysterious
way that made it appear that the server was somehow borked. ???
    -Olin