Re: fdisk implementation [read this before deciding what to do]

[Vincent Stemen <vince.dragonfly@xxxxxxxxxxx>]

On Fri, Jan 09, 2009 at 07:33:17AM +0100, Sascha Wildner wrote:
> Vincent Stemen schrieb:
>> Yes, in the traditional layered Unix approach, this tool was
>> specifically designed to be easier to automate and to write interactive
>> front ends than the existing tools.  It would probably be easy enough to
>> add a simple interactive mode to the tool itself, but I hesitate to do
>> that because, as you mentioned, I can do the same thing with a shell
>> script, making it easy to tune the interactive behavior and to have
>> multiple different interfaces that are as simple or as sophisticated as
>> you want.
>
> Yes, but the downside of this is that there are two distinct interfaces, 
> one for the tool itself (getopt_long() stuff) and another for the 
> interactive mode which is put on top of it with shell scripts.
>
> A better idea IMO is to have a built-in interactive mode and allow for 
> feeding those commands to the tool also from a file. In the tool it's just 
> a matter of either reading from stdin or from a file.
>
> Sascha

We discussed it further and Chet is pretty dead against a built in
interactive mode and having to write the commands to a file and then
read the file or having to use pipes.  The existing tools such as
disklabel and fdisk use that approach and it was so much extra work to
write automation scripts that he ended up writing *partition* in the
fist place.  Having interactive interfaces built in to such utilities,
we believe, adds unnecessary bloat and takes away from flexibility.
Besides it just doesn't seem like the Unixy way to do things.  Just like
you don't use cp, mv, ls, sed, sysctl, or most other Unix utilities,
interactively.  That is what scripts are for IMO.  If you want an
interactive mode, I could write a simple shell script in probably
5 minutes that would go through a loop, prompting for the commands and
passing them on the command line.

Another advantage of being command line based, is when listing
information.  I can just say "list slices" like I would *ls*
a directory.  
    e.g. "partition --list-slices /dev/ad0" 
(Actual example from the current state of the tool)

Take the *ls* command as a comparison.  It would suck to have to type
echo "ls d*" | ls" or to have to enter interactive mode, run the
command, then exit, to get a file listing.

The other advantage, even without a front end script, is the power of
shell history, editing, and completion.  It just doesn't seem to make
sense to re-write the shell for each utility.  For example, if you are
running a shell that has customizable argument completion, such as
Zshell, you can even have automatic completion of arguments, custom to
the partition tool, using the <tab> key.