Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Shellorama 2005

Prev : Index  : Next

Nov 15, 2005] vshnu the New Visual Shell

Skilled Unix users know the importance of the shell or command line interface (CLI). (Old-time Unix users didn't even have a choice about it). While having more of a learning curve than a graphical user interface (GUI), it permits powerful, creative, complex operations to be specified quickly and reliably. For anyone but the superficial user, learning a CLI is an investment that pays off rewardingly. Command line environments are still readily usable over low-bandwidth network connections and restricted displays. Neal Stephenson explains the history and values of computer interfaces exceedingly well in "In the Beginning was the Command Line" <http://www.cryptonomicon.com/beginning.html>. One can even build a strong case that a CLI is best for a learning new computer user, as described in "The Command Line - The Best Newbie Interface?" <http://osnews.com/story.php?news_id=6282>.

However, when one is concerned about file manipulation and management (which is a very good thing to be concerned about as the basis of your interface, as most GUIs would rather lead you to forget), a CLI can be a frustratingly terse interface to the filesystem. Too many tedious ls(1) and cd(1) commands are needed to keep watch on what's there. A GUI file manager can address this problem, but then you're in mouseland and have lost the advantages of the CLI.

Enter the visual shells. Not a new idea, visual shells can operate within an entire terminal or console screen. File listings are displayed for your constant reference. Common commands and operations can typically be performed in fewer keystrokes in a visual interface. As the vi(1) visual editor evolved from the ed(1) and ex(1) command line editors, visual shells have attempted to evolve from command line shells. Some visual shells have promoted themselves as simpler menu-oriented interfaces suitable for novices, while others emphasize more expert functionality.

Nonetheless, visual shells have never really caught on, except some in certain circles such as Emacs' "dired" mode and the Midnight Commander program. I believe this is because they have been designed as largely self-contained applications with limited configurability. Using a visual shell has required a significant jump into a new base interface tool, and few are so compelling or standard to make that worthwhile.

Hence the design of vshnu, the New Visual Shell. In the Unix tradition, it works with things already there and fills a empty niche. When incorporating it into your Unix environment, you keep your command line shell, your editor, your pager, and access to all your tools, tricks and know-how. Vshnu can operate as an optional supplemental visual mode to your command line shell. You switch between command line and visual mode easily as you wish. Your interface bandwidth and power for Unix operations is on a higher plane and life gets sweeter. In addition, being written in Perl, it ports to any Unix system without compilation, gives you the advantages of a Perl interpreter running readily at hand, and permits visual command customizability limited only by your creativity, yet doesn't require knowledge of Perl for normal usage. Vshnu is a tool that's worthwhile even if only used occasionally as an interactive, pageable, color ls(1), yet still pays back, with interest, whatever more you put into using it.

Additional Features

• Extensive options for sorting and listing a directory's files
• Multiple methods for navigating directories and selecting files
• Directory locations may be marked for quick returns
• Lists colored command outputs alongside files, including a builtin "ls -l" and "df"
• Directory and file histories
• In color terminals, uses color for more informative displays, including file coloring by type via the standard LS_COLORS environment variable
• Expands and collapses chosen subdirectories

• Multiple methods for choosing and operating on individual or arbitrary sets of files
• Key commands and file actions are 100% configurable, extensible, self-documenting and arbitrarily complex, including multiple choice options
• File actions are customizable by file name/type/contents/etc, with common actions configured by default
• Online help descriptions of key commands and file actions, by mode and by command
• Separate per-site and per-user configurability

• Adjustable file column displays
• Adapts to changing screen sizes (but works best on screens 80 characters wide or more)
• Current directory and environment is propogated between vshnu and the parent command line shell
• Multiple interfaces for shell commands and Perl statements
• Perl statements may be {{embedded}} within shell commands
• A Perl "where" clause to subset the displayed files

• Can use mailcap(4) files for specifying file actions by MIME type
• Can use the CD_PATH environment variable as a search path for files and directories
• Recognizes the following standard environment variables: ANSI_COLORS_DISABLED, DISPLAY, EDITOR, HOME, HOST, LS_COLORS, MAIL, MAILCAPS, PAGER, PATH, PERL_RL, SHELL, TERM and VISUAL

[Apr 2, 2005] freshmeat.net Project details for The friendly interactive shell

About:
The friendly interactive shell is a shell focused on interactive use, discoverability, and friendliness. fish has very user-friendly and powerful tab-completion, including descriptions of every completion, tab-completion of strings with wildcards, and many completions for specific commands. It also has extensive and discoverable help. A special help command gives access to all the fish documentation in your Web browser. Other features include syntax highlighting with extensive error checking, support for the X clipboard, smart terminal handling based on terminfo, an easy to search, no duplicates history.

[»] Re: zsh? :) by liljencrantz - Feb 28th 2005 02:02:19 > Hm, but what's missing in zsh or > bash-completion to start Yet Another > Shell? Good question. I started writing fish because of two missing features. Tab completion of strings containing wildcards and syntax highlighting. The first one is (to me at least) obviously useful, while the second one only becomes useful if you start thinking about flaging errors red, so you can see a lot of misspelled words before executing the command. To do the first one, one would have to rewrite both the completion system and the globbing system, both of which are large, hairy beasts. To do the second one, one would have to connect the parser with the editor, which might be doable in zsh, but since bash uses an external editor (readline), this becomes a huge hairy mess. So I started out wanting to write a small, simple test shell to see if those two features where nice. After implementing them, I thought that they were worthwhile, so I looked at the bash sourcecode. Yikes! I really do NOT belive in throwing away old code and starting from scratch, but I'd say it is impossible to rewrite a major part of bash without first implementing at least one other shell so you know what the issues are. There are lots of comments in the source which amount to "Does this really work? What does it do?", and though large parts of the code are pretty well written and commented, there are huge chunks of hairy, strange and uncommented code. I suspect that some of the bash maintainers that have come and gone over the years liked to write unmaintanable, ugly and uncommented code, and that later maintainers have tried to stay away from large portions of the codebase. I also suspect that there are huge amount of code duplication, but since the code makes my eyes bleed, it's kind of hard to be sure. In hindsight, maybe I should have watched zsh more closely, since several of the features I've added to fish since are also present in zsh. But apart from the ones described above, fish also has features like a clever MATLAB-like command history, (slightly) better job notification and a cool pager for tab completions. Also, many of the features that are in fish and in zsh are disabled by default in zsh. I did not know about them until after releasing fish, since they are kind of hard to find. :-/ [»] Re: zsh? :) by Michael Shigorin - Feb 28th 2005 03:17:24 *sigh* Same old story of same old code... thanks for clearing up, hope that my "anti-dup" comment didn't hurt you but maybe helped to have another look ;-) -- Michael Shigorin mike SOMEWHERE AT altlinux PLUS DOT org

[Mar 25, 2005] Bash  2.05b with debugger  source  is available at http://bashdb.sourceforge.net/.

The debugger is more than a diagnostic tool,  it is a fine way to explore the very guts of bash.

[Mar 21, 2005] Advanced Bash Scripting Guide Version 3.3.

More bugfixes were made, some of them fairly important. New material was added, including a few rather useful example scripts. This is more than a "minor" update, but not quite a major one.

The Advanced Bash Scripting Guide is both a reference and a tutorial on shell scripting. This comprehensive book (the equivalent of about 646 print pages) covers almost every aspect of shell scripting. It contains over 300 profusely commented illustrative examples, and a number of tables.

Not just a shell scripting tutorial, this book also provides an introduction to basic programming techniques, such as sorting and recursion. It is well suited for either individual study or classroom use.

Continue...