TermBuilder: a graphical Linux command line generator

Posted at 1:31pm on Wednesday January 27th 2010

This is TermBuilder, an easy-to-use script that helps newbies form Linux terminal commands by selecting from options in their web browser. To get started, all you have to do is select one of the command options from the selection box below, and click Add. If you add more than one command, the output will be chained from the first program to the second.

There are some things you need to know before you get started:

Some of the command types must come first in your command because they don't make sense anywhere else. For example, while you can list the files in a directory with one command and pipe the results to another command to count the number of lines that were returned, it make no sense the other way around. In the list of commands, any command with a * next to it is one that must appear at the front of your command.
The commands generated are designed to run using the GNU tools shipped with Linux distros. They may work with other Linux-like OSes; they may not. Try your luck! Similarly, this has been tested to work on various Linux web browsers; if you find a bug with Firefox, Konqueror or some other Linux browser do let us know below.
If we've missed some important commands or command parameters from the selection here, please post a comment below and we'll try to add them.
Of course, it goes without saying that all the code for this is licensed under the GPLv3. Click here to download the TermBuilder source code.

Commands

This is the first release of TermBuilder - please let us know what you think below. Any bug reports, suggestions or other feedback is most welcome!

You should follow us on Identi.ca or Twitter

Your comments

This is great

Stephen@NoS-LUG (not verified) - January 27, 2010 @ 2:24pm

I love this Idea. Any chance this could be extended to writing scripts?

Impressive!

TomMan - January 27, 2010 @ 2:38pm

I'm very impressed with this, I will certainly use this a lot. :)

Correction

CarryingColoradan (not verified) - January 27, 2010 @ 5:09pm

In the first bullet point, at the end of the second sentence, it says "it make sense the other way around." I believe you meant "it makes no sense [...]".

The long road to standardization

TesserId (not verified) - January 27, 2010 @ 5:10pm

Now imagine that there was a standard machine-readable grammar language (meta-language) that would adequately express the usage of commands. Then any new command for which such a grammar was provided could be automatically added to a tool of this sort. But, it is perhaps too much to expect from those who write command documentation.

In the mean time, I wish you much luck in manually maintaining the rules for all the commands that you include with this tool.

From there, you might then include some standard tasks with a repertoire of common command combinations.

Ultimately, I have to commend those who got this started. This is surly a worthy endeavor. Best of luck.

Great!

Polly the Parrot (not verified) - January 27, 2010 @ 6:21pm

I always wanted one o'these! Thanks! :-)

One suggestion: to also have a "Clear" button should the user not be looking for a "piped" command sequence. Sorry, I'm just lazy...

Great idea! One suggestion:

Ron LaBorde (not verified) - January 28, 2010 @ 10:49pm

Great idea!
One suggestion:
How about adding a text explanation of the generated command, show the how and why of each option. Now you have a real teaching tool as well.

Your suggestions

TuxRadar - January 28, 2010 @ 10:57pm

Thanks for your suggestions, folks; could you perhaps clarify a few things?

<< Any chance this could be extended to writing scripts? >>

You mean like Bash scripts? Or do you want for loops and the like? If you give us some examples of scripts you'd like to be able to create, we'll take a look at them.

<< to also have a "Clear" button should the user not be looking for a "piped" command sequence >>

We're not quite sure what you mean. Do you mean rather than "do A then B then C" you want to be able to see "do A; do B; do C"?

<< How about adding a text explanation of the generated command, show the how and why of each option. Now you have a real teaching tool as well. >>

There are already the question marks next to each option explaining what it does. The reason we made the command update live as you change things is so that people can see how each command is built and what the different options do. Again, give us an example or two of what you'd like to see and we'll look into it.

"Clear" button

Polly the Parrot (not verified) - January 29, 2010 @ 12:45am

Hey, guys! First of all, thanks for your response.

About the "Clear" button, try this (and yes, I know the resulting command will make no sense):

1) In the drop-down box, select "List the contents of a directory". Click the "Add" button.
2) Now, in the drop-down box, select "List all running programs". Click the "Add" button.

The output in the "Generated command" box is:

ls -d * | ps aux

(which, again, I know does not make sense).

The two commands were, uh, "concatenated" with the pipe symbol. If there were a "Clear" button I could have used it between steps 1 and 2 to get only the last piece ('ps aux'), which may be what I want, sometimes.

I hope I was able to clarify that.

Keep up the great work!

..There are already the

Ron LaBorde (not verified) - January 29, 2010 @ 3:10am

..There are already the question marks next to each option explaining what it does...

Sure, I missed that - its exactly what I was suggesting. My bad, sorry for not realizing live update to the question marks. You have a wonderful tool here!

TesserId: One approach would

Anonymous Penguin (not verified) - January 31, 2010 @ 4:06am

TesserId:

One approach would be for contributors to this project to design each input form carefully. Then, after many of these have been done, find common factors so as to write out an xml definition to cover all the commands. With the xml syntax and semantics well defined, contribute each command's xml entry to the corresponding projects and point them to the xml syntax/semantics. Later, someone else might tune the descriptive xml definitions so as to express these as dtd, relax ng, and maybe xml schema and/or something else with associated semantics.

A long term goal would be for every single Linux application to develop its cli as extensively as possible (eg, I'd like to see firefox cli be much more interesting) and define its corresponding xml.

A wiki that explains the javascript, shows what it looks like in action, links to the man page, and shows the current xml (draft) definition could help move this forward more quickly. This way people that don't have a lot of experience with javascript can try to follow the patterns and add commands they are interested in. Others come around and clean up (wiki).

How about head & tail (view

Anonymous Penguin (not verified) - February 20, 2010 @ 2:44pm

How about head & tail (view last/first n lines)

Edit

Anonymous Penguin (not verified) - February 20, 2010 @ 2:48pm

Sorry, found it!