[15] in arla-drinkers
sl/roken and parsing ramblings
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Jun 21 04:50:31 1998
From arla-drinkers-request@sundance.stacken.kth.se Sun Jun 21 08:50:29 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 12144 invoked from network); 21 Jun 1998 08:50:28 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 21 Jun 1998 08:50:28 -0000
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
by sundance.stacken.kth.se (8.8.8/8.8.8) with SMTP id KAA28097
for <arla-drinkers@stacken.kth.se>; Sun, 21 Jun 1998 10:42:59 +0200 (MET DST)
Received: from MARY-KAY-COMMANDOS.MIT.EDU by MIT.EDU with SMTP
id AA27502; Sun, 21 Jun 98 04:42:58 EDT
Received: by mary-kay-commandos.MIT.EDU (SMI-8.6/4.7) id EAA25109; Sun, 21 Jun 1998 04:42:55 -0400
Date: Sun, 21 Jun 1998 04:42:55 -0400
Message-Id: <199806210842.EAA25109@mary-kay-commandos.MIT.EDU>
To: arla-drinkers@stacken.kth.se
Subject: sl/roken and parsing ramblings
From: John Hawkinson <jhawk@MIT.EDU>
What does sl stand for?
There's an inconsistency in the way sl_command() handles return
values versus the way fs (et al) do so.
If sl_command returns -1 (should be a constant, proably), fs will
print out "$argv1: Unknown command".
But various fs commands return -1 to signal
invalid usage syntaxes.
That means that you see something like:
> /usr/arla/bin/fs lsm
fs: Required parameter '-dir' missing
lsm: Unknown command
Whereas the transarc version produces:
[mary-kay-commandos!jhawk] ~> fs lsm
fs: Missing required parameter '-dir'
[mary-kay-commandos!jhawk] ~>
So probably the interface for sl_command() should be defined a little
more clearly and the routines called by sl_command() should return
SL_BADSYNTAX (-2?) instead of SL_BADCOMMAND (-1). Or something.
Is it intentional that the commands (well, just vos) that use
sl_help() for their help text get this bizarre formatting:
> ./vos help
addsite
not yet implemented
apropos
not yet implemented
It certainly feels unfriendly. I guess I see that the
examine, volinfo
print information about a volume
might be a more efficient use of space, but overall, I think we want
the helpsummaries for all commands to say <48 rows (common window
height). For Transarc fs/pts/vos they're at 36/16/28 rows. For arla,
vos help is already at 56 rows.
I think that printing the canonical command name is probably
quite sufficient and it's not necessary to print the aliases.
Detailed help ("vos help addsite") could print aliases,
though.
I guess vos is the experiment for sl_help() to see how it's working?
It also coredumps on some architectures:
> (setenv SLMANDOC 1; ./vos help)
.\" Things to fix:
.\" * correct section, and operating system
.\" * remove Op from mandatory flags
.\" * use better macros for arguments (like .Pa for files)
.\"
.Dd Jun 21, 1998
Segmentation fault (core dumped)
because __progname isn't initialized:
p = strrchr(__progname, '/');
Of course, under Solaris, it will work with:
> ( setenv LD_PRELOAD 0@0.so.1 ; setenv SLMANDOC 1 ; ./vos help )
but you didn't want to know that, I think :-)
*** /tmp/T0057RXP Sun Jun 21 04:36:34 1998
--- sl.c Sun Jun 21 04:35:51 1998
***************
*** 230,235 ****
--- 230,238 ----
sl_command(SL_cmd *cmds, int argc, char **argv)
{
SL_cmd *c;
+
+ set_progname(argv[0]);
+
c = sl_match (cmds, argv[0], 0);
if (c == NULL)
return -1;
...fixes things, but again it's not clear whether this really belongs
in sl_command(), a hypothetical sl_init() function, in vos' main(),
etc., etc.
I'm unhappy with the choice of __progname, since __ is reserved for
the operating system's private stuff, and we shouldn't be poking at it.
It looks like the sl/roken stuff comes from kth-krb (if not other places),
so maybe it's hard to change and there's a lot of version skew?
I'm unsure it's so wise to use -mandoc macros over -man macros, but
perhaps that's because I haven't gotten around to installing
much on this system at the moment, so I'm biased.
--jhawk
