Need feedback on a wrapper script design.

[selk]

Dear Monks:

We have a bunch of internal tools, written by different people and in different languages (mostly in Perl although some are in Tcl, bash, C++, etc.), and most of them are located in a single directory. I would like to create some kind of a wrapper script for all these tools. Although I already have some pretty good idea what I would like this wrapper script to have, there are still some issues that I am not sure what's the best way to handle them. BTW, I was not asked by my manager to do this. I just saw a need for something like this and hoping to just do it myself for extra points :-)

Here are some of the requirements for my wrapper script:

1. The script would scan a known directory for the tools and present a menu to the user of all the available tools. I was thinking maybe to use Perl/Tk for this.
2. When the user selects a paricular tool, he/she will be presented with some description about what the script does, and the arguments it takes. Since I don't want to impose that the tools be written in a certain way or in what language, I was thinking that maybe there will be a separate metadata file describing all of these. I'm not sure yet whether each script will have its own metadata file or there'll be one metadafile for all the scripts.
3. If the user invokes a selected tool, it will ask for the arguments if it needs any, and then go on and execute the script.
4. The script's output will either go into another window or in some subframe within the same window. But in any case, I would like to be able to capture this window or be able to save this to a text file when I'm done. So, maybe I would run several tools in sequence, then save the output screen when I'm done.

That's pretty much what I have so far. The thing that I am not sure how to handle yet, is how to ask the user for the arguments needed by the tool. The ugly way would be to just have the user type in some text field the exact command to execute the tool passing in all the command line arguments. A better way I guess, is if the arguments are described in some metadata file as well, then render them in some kind of input screen or dialog window, then form the command line needed to invoke the tool.

What do you monks think? Thanks in advance for all the feedback.

[rinceWind]

ptksh that comes with Tk, is a good starting point. It doesn't do exactly what you want, but probably contains much that you can reuse.

[Courage]

I wrote an utility very close to your description; mostly my utility coincides with your description, but I have only Perl scripts to invoke.

Each utility to invoke has common agreements on parameters, and, indeed, parameters could be entered via GUI, or from command line, or both methods (entered in command line and then edited by afterwards in GUIby user), or without GUI - all ways of invocation are possible in my case.

GUI was implemented with Tcl::Tk, which is like perl/Tk but much more capable.

I can provide may be more details on this.

Also, http://search.cpan.org/~srezic/Tk-Getopt-0.49/ could be of interest for you as a starting point of your own way.

[graff]

Think about what will happen as more tools get added to the given directory. Will you need to change the code in your GUI, or not? If yes, then you might want to think harder about how you are designing it. OTOH, if just changing your "metadata" is all that is needed to adapt the GUI to any change in the tool set, you still need to consider how that metadata is created and modified. Can (any of) that work be done automatically? (If yes, then you're on the right track.)

Personally, I view GUI interfaces to command-line tools as being sort of like training wheels on a motorcycle. I don't doubt that some people who've never used a motorcycle before may find some comfort in using them, at least for the first little while. But as soon as one has a basic grasp of using the unmodified mechanism, the training wheels slow it down and limit its use to the point of being an unbearable hindrance. (And many people just jump right on the unmodified machine and start moving.)

Still, there is real value in a GUI tool that can provide a good, comprehensive summary of other tools of any type. So focus on providing easy, sensible displays of the tools -- e.g. a listing that shows: tool name; availability of a man page; command-line usage synopsis; maybe even type of tool (shell script, perl script, binary, ...). Clicking on a list item should bring up the man page with more detailed explanation of usage, along with purpose, resulting output, and error conditions.

You might choose to provide a dynamic set of buttons based on the usage synopsis in order to activate particular options, but I think it's just as well to allow the user to type in a set of command line args. (The sooner they take off the training wheels, the sooner they'll speed up.)

If some tools have especially intricate controls, it would certainly be handy to have a simple method for storing a particular command+option string, with a label, for future use. (Among CL/shell addicts, this is known as creating an "alias" or "shell function".)

[chb]

This isn't Perl, but maybe you can get some ideas from the kapain project: http://kaptain.sourceforge.net/

[griff]

This is a very labor-intensive solution to the arguments problem, but here goes.

Edit each of the scripts to respond to a set input. For instance "mytool -h" might return a specification of the arguments that the tool accepts and perhaps a description of their effects that you could parse automatically. Perhaps you could use xml. You would want to look out for optional inputs, required inputs, modes, etc.

Since it sounds like you have a lot of existing scripts, you might want to just write a quick perl wrapper for each of the existing tools that could return this description if called with no arguments, or runs the intended tool with whatever arguments are supplied. New scripts that you write could then support this self-specification protocol and do away with the wrapper. Just point your program at the directory of wrappers and it would be able to automatically determine what sort of arguments each tool needs.

Using this method, you wouldn't need some sort of database that would need to be maintained seperately, the tool itself (or its wrapper) would advertise its interface.

[sauoq]

Edit each of the scripts to respond to a set input.

IMHO, this is poor advice. Changing the interface of a bunch of existing tools which are, presumably, in regular use is a very bad idea.

[sauoq]

BTW, I was not asked by my manager to do this. I just saw a need for something like this and hoping to just do it myself for extra points :-)

Why do you really want to do this? Is it really to impress your management and get "extra points?" You say you saw a need but whose need is it? After you put the effort into this and your tool is created, is it going to be used, or most of the team already familiar the tools that exist?

How are the tools used? If they are like most Unix tools, they can probably be used in chains of filters where the output of one script is used as the input to another. Will your wrapper support this? How will your wrapper handle command line arguments with more than simple logic? (I.e. this switch makes sense only when used in conjunction with this other one or similar.)

Could a better solution be writing some documentation?

If I was your manager and I saw you take the initiative to write some documentation for our in-house tools, I'd be impressed. ;-) I'd be less impressed by a gui front-end to command line tools though.

[selk]

Thanks to all for the feedback so far. I would like to answer a couple of questions mostly from this last post because it raises very good points that might also help where I'm going with this.

Why do you really want to do this? Is it really to impress your management and get "extra points?"

Actually, that was secondary :-) My primary goal is to find some ways to practice my skills with Perl by doing real world problems. Besides, the company is in kind of a lull right now and our group is in betwen projects. We just also had a big layoff, everybody is feeling down and just kind of sitting around. I'd like to find myself something interesting to do.

You say you saw a need but whose need is it?

The tools will be used by Tech Support and Field Engineers. And the tools are written mostly either by developers or SQA. They started as internal tools for one person's own use. So most, if not all of these were written not meant for public consumption aside from the person developing the tools and maybe one or two other people in the group. The usualy thing that happens is word spreads around about such a tool, and it just get dumped in a central repository where everybody can gain access to it.

After you put the effort into this and your tool is created, is it going to be used, or most of the team already familiar the tools that exist?

As touched upon by the previous answer, no, the people this wrapper script will be meant for a totally different group, perhaps less technical than the original audience the tools being wrapped were meant for.

How are the tools used?

They are just currently command line tools run on a linux bash shell. The people using it, are mostly on Windows telneting to the linux environment, and are not very comfortable with command line tools. Most of the users use the command by 'rote' method. Somebody would give them the command and arguments once, and they will just kind type it in without really understanding what's going on. And they will just remember that as the only thing they have to type to do something.

If they are like most Unix tools, they can probably be used in chains of filters where the output of one script is used as the input to another. Will your wrapper support this?

No, most of these scripts are stand alone, whose output will never ever be used to feed other scripts.

How will your wrapper handle command line arguments with more than simple logic? (I.e. this switch makes sense only when used in conjunction with this other one or similar.)

This is actually one of the things I'm asking this group for help about :-), that is, how to handle command line args. I never even thought about what you just said here, which is good, this is why I asked here in the first place, right? :-) But I guess the answer to this one, I'm just going to make my wrapper script very dumb and I will not try to process any arguments at all. All I have to do is gather up all the arguments from the user, and invoke the script passing all the arguments without doing anything to it. I'll let the script handle the argument checking. If I get an error back from the script, then I'll pass it back to the user.

Could a better solution be writing some documentation?

I'd like to say 'Yes', but I think it will just be part of the solution. And I actually documented some of them, well at least all the Perl ones, by writing PODs, but nobody ever noticed them. or bother to look at them. I was thinking that one of the features of this wrapper will be to display the POD when the user selects a particular tool. I don't know what to do yet for those tools that are not Perl.

If I was your manager and I saw you take the initiative to write some documentation for our in-house tools, I'd be impressed. ;-) I'd be less impressed by a gui front-end to command line tools though.

I was thinking the wrapper would address both. It will present some documentation about the script if it is provided by the script, and at the same time provide some kind of UI to it, I don't know about GUI at this point, but at least some kind of UI

Also, another question above is how I would like to handle when a new script is added, do I want to change the wrapper code each time? The answer is no. The metadata I was talking about will suppose to take care of that.

Thanks again for the interaction so far. I think it's kind of helpful, in a way where at least it got me thinking about things I haven't though about yet.