Submitted by “Colin Walters of Red Hat chaired a FOSSCamp session about Hotwire, a unique and innovative graphical shell environment designed to improve the command-line user experience. I’ve been testing Hotwire releases for some time now, so the opportunity to see Walters present his invention in person seemed too good to pass up.”
It’s a cool toy for unix geeks!
More useful for beginners
than fish shell I think.
But for speed and raw power zsh still wins
Notice that it uses a more object-oriented approach. That is, programs take objects as input and output instead of just strings. This isn’t just for beginners, as this feature can be heavily exploited to provide a more powerful environment for advanced users.
It’s nice to see usage of advanced graphics like that completion popup or icons in “ls” output, but for me it wastes much too much space. I hope (but don’t think) it’s possible to hide the menubar, scrollbar, tabbar, etc. so only the output widget is visible with a one-line input-textbox at the bottom.
This seems like it’s going to require writing a parser for each *nix shell command to create objects from their text output. Sounds like a large task.
It’s an interesting concept, really. To make wide use of it, some kind of translator / parser / tunnel could be created in order to manipulate Python objects as they are used within Hotwire and passed from / to called applications.
Using classical shells, you have the same functionalities, of course, but they usually are represented as text that you can process line by line. Objects privide more complexity, but handling them requires more ressources. At low level system operation tasks, Hotwire won’t be very useful, I think (minimalistic conditions), but as it has been mentioned before, it can be a very professional and powerful tool, as well as it can introduce beginners to the power of the CL. Its possibilities regarding extensions are quite good, thanks to Python and Gtk. This will enable its integration into mechanisms already present within the UNIX / Linux system and its applications.
I see an irony here,
“Heavily inspired by Microsoft Powershell, the underlying infrastructure of Hotwire is based on the principle of object pipelines.”
Now RedHat is getting inspirations for shells from Microsoft, while Linux is known for superior command line support.
This seems interesting.
Edited 2007-11-02 02:02
Nobody has really done anything like powershell before, that is why that is where the inspiration came from. Just because it comes from microsoft doesnt make it bad.
I like the idea behind this. Powershell is more geared towards running existing scripts, hotwire looks more geared towards direct interaction.
Actually not.
Just look at the past glory of XMLterm of Mozilla foundation.
They wanted full power of XHTML for a command line,
and provided much of the similar functionality through output of structured markup.
Both inputs and results had an option to be both structured markup and text. In this way it was more open-ended approach (you can exchange documents without insecurities of a code transfer, and you can’t do it with meaningful objects).
http://www.scsh.net/resources/commander-s.html …
hotwire is relaly nice. been playing with it for the last few weeks. as for powershell, well, i have to hand it to microsoft i absolutly love it. been playing witht he 2.0 beta for a while and its great. 1.0 was solid and really set teh standard, in my opinion, of how it should be.
good old 4dos, 4nt etc
as if powershell was something new, lol…
is this what 10 years of reinventing wheels means?
4dos is an enhanced cli for windows, adding a few tools to the existing platform. Powershell was the first thing to really bring an object oriented approach to the command line, while leveraging the .net api to provide an incredable amount of capabilities for scripting. they are not even remotely the same thing. One adds a few basic capabilities to a fairly crude platform, the other completely turns the way we look at scripting on its head.
This object-oriented vs. text-based shell debate reminds me of that old saying: “Those who don’t understand unix are bound to reinvent it, poorly.”
Object-orientarion in CLI shells is highly overrated. If I want object orientation, I’ll go for Python or Ruby, or any other readily available modern scripting language, not shell.
The text-based nature of the existing unix shells is what makes them great for quick and dirty scripting. Just like text-based protocols like HTTP/SMTP/… trade a bit of performance for increased readability/debugability, so do traditional unix shells.
After having played around with php and python as general purpose scripting environments, I do agree that oop in a shell environment is useless 90% of the time, and it comes with many burdens, such as having to learn the api of every object passed around (and the typical sysadmin is not a great coder).
Otoh I am still wondering whether a “standard” shell where lists and especially hashes are a first class construct to be used for piping between commands would be a huge productivity boon…
I don’t think it’s highly overrated. Here are some examples where OO approach can improve CLI:
1) consider sorting files based on size. This can be accomplished by: ls -s | sort. The problem is sort does not understand that ls is giving it two columns: a numerical column and a string column. If sort understood the second column consists of numbers, it could numerically sort it instead of doing an ASCII sort.
Here’s an OO alternative: ls -s produces an array of “listings,” where the listing consists of a (number,string) pair. An OO sort can readily understand that the first column is a number and sort appropriately.
2) A major problem with Unix is the rm command. It is permanent and does not provide any facilities to check if the user is entering a sane command. (See Unix Hater’s Handbook for a more thorough argument; I know a lot of you guys hate that book, but it provides a lot of interesting arguments and it is not meant to be taken so seriously according to the author. In fact, ESR has cited it in his Art of Unix Programming book many times.)
Consider “rm -r *.”. It is so easy for the user to accidentally type “rm -r *” (which is easy if the user prematurely hits Enter), leading to catastrophic results. The problem is rm cannot do a sanity check and make sure the arguments are intentional because the shell expands wildcards automatically.
Here’s an OO alterative: the shell could provide rm the expanded version of wildcards like ‘*’ and the original command issued to the shell. Then rm can do a sanity check.
I don’t propose that OO is a silver bullet in all of CLI’s problems, but has the potential to improve it. If you get a better interface, then why not use it? If the objects and norms are consistent and useful, then why not? As for speed, it has been understood that a more consistent, well-designed system is better than a faster one. (See Art of Unix Programming.)
With your rm example you can already do that with an alias and a shell script. i.e. the script gets all the output expansion and displays the first ten or so lines of files to be deleted to the user and then asks if they really want to do it.
The actual problem here is that most UNIX or UNIX like systems do not come with such a thing as a default and they should especially for the root user.
As for your first example it works on my system. ls gives two columns the first being size. Of course if it did do it the way you suggested sort itself could be rewritten so that it could take a specified column as a parameter. There are also intermediary utilities that can be used to swap data around such as sed and awk.
“consider sorting files based on size. This can be accomplished by: ls -s | sort.”
Actually, “-s” shows the number of blocks for the file, not its size. Nevertheless, sorting by number of blocks can be accomplished with “ls -1s | sort -n” (where “-n” tries to sort numerically first), and sorting by file size can be accomplished by just “ls -1S”.
Anyway, the text-based shell is now more than 30 years old, and people don’t seem to find any arguments against it beside academic issues. That kind of proves my point.
The OO shell may be a better technology, but that doesn’t make it better in the real world. The shell is primarily an interactive tool, and scripting in the shell should be an extension of that interactive use. That means operations should happen over data as the user (admin) sees it, and the user sees text. Besides, the universal nature of text means all tools can operate on all data/be piped, unlike tools in an OO shell.
Most people hyping the OO shell are the very same people that tend to use the shell for complex scripting, something it isn’t meant to do. That’s why we have scriptable shells – and – scripting languages.
I am a Python programmer and when I think of a Python based shell, the first thing that comes to my mind is an environment which allows me to mixin Python code with shell like capabilities. Hotwire disappoints in that it does not provide such an enviroment, but provides pre-built constructs to manipulate Python objects.
For example how about creating an object on the shell which allows me to perform a list comprehension filtering on the current process objects ? Something like…
[item for item if item.name.startswith(‘wget’) in proc]
(proc is a hotwire builtin which lists the current processes as objects).
The filter builtin only accepts strings, not something like list comprehensions or Python objects or arbitrary lambda (anonymous) functions. Till hotwire supports at least Python list comprehensions/anonymous functions and filtering based on these, I am not much interested.
It does look like a project with potential, but still way to go.
I dream at night of a python/shell mixed environment that allows me to manipulate commands and system information as python objects.
Personally, I dream at night of hot girls manipulating my python-like object.
I guess it won’t be too much work to develop one. My recipe for such a project’s 0.1 version would be,
1. Provide types (classes) to represent many of the command-line “objects”. Primarily these would be processes, files/directories, commands, pipes.
2. Make it function as a minimal shell also. The representation (display) should be much the same, but the internal objects would be Python objects which can be introspected.
3. The environment itself should be a Python interpreter. That is, there should be no additional work required to expose Python syntax to the power user using this. Since Python provides an interactive interpreter and even ready-to-use cmd interpreter classes (checkout the “cmd” module), this is straight-forward. This is where hotwire disappoints me.
4. Wrap the whole thing in a nice Py-GTK front-end with support for history, completion etc.
Anyone Interested ? 🙂
This is already implemented.
This is also implemented, but I think you’re underestimating how hard it is to do a shell.
Yeah, this is the strong feedback I got from the FOSSCamp presentation, and I have a plan to improve it. Once 0.600 is out, the road to 0.700 will focus on this.
In 0.599 you can press Ctrl-Shift-S to get a same-process interpreter where you can play around, and that will form the basis for doing Python in Hotwire.
I have not written a full-fledged shell with process control, history and other frills in Python, but I have written complex command interpreters using the cmd module. I guess it shouldn’t be too hard.
…
Good to know you are already thinking about it. Not to take anything away from your effort, but if I had started on a similar project, this would have been the first thing in my design spec.
Hotwire is cool and looks very promising, but the fact that you did not take advantage of the excellent interactive and introspective capabilities of the Python interpreter is disappointing.
All the best for the project…!
I don’t think it would ever replace bash, but it could definitely be a useful productivity tool or UI. If hotwire were to also allow for a compound user interface (that is, if hotwire scripts could modify the shell’s UI environment) we could see something that would finally give traditional GUIs a run for their money.
I always wondered why we should have separate shell languages. PowerShell (that uses .NET) proves that special languages for the shell are unnecessary.
Not entirely. PowerShell, while built atop .NET, is still a new language. You can’t just write C# (for example) at a prompt and expect it to work.
Because it’s a .NET language, however, it can easily utilize .NET class libraries, or interop with COM/WMI/etc., for scenarios that the cmdlets alone don’t yet cover. One difference from traditional shells is that there are no built-in commands.
WRT to the statement in the article:
While it’s true that the default PowerShell host from MS is the standard console window, PowerShell implements command completion (and many other features) as functions which users may freely customize. There are currently several free and commercial shell hosts and custom functions that extend the default PowerShell environment with graphical shells and/or intellisense-like statement completion.
FYI, a CTP of PowerShell 2.0 will be released next week.
http://blogs.msdn.com/powershell/archive/2007/11/02/ctp-ctp-beta.as…
Great thing!
I would switch, if only Colin provided remote support.
Most people use shell on the remote computer. I need to:
1. Use shell over SSH to remote computer, on which I may not even have X11 libraries to start hotwire with.
2. Detach a shell session from my local computer, when I’m on the move, or expect that a job will last few days. (“Screen” does it very well.)
Of course GnomeVFS already supports remote browsing for 1., so it is just a matter of support. The 2nd thing may be much harder though.
I have used it for a while and I wasn’t too impressed. The main drawback is that it is /slow/. Second, I cannot see any real benefit over a good old bash shell. In fact, hotwire’s builtins have only a small subset of option that the respective bash builtins have. For any serious application, like mutt, mc etc, you have to run term [command], which launches a conventional xterm in a separate tab.
yes it is. Are there some deficiencies on being traditional shell scripts streams only? Yes there are.
Do hotwire bring friendship to newbees? Yes, it sounds sweet.
Lets now discuss what is the market for such a tool. Its target is administration/automation. Why? Because for simple things, you are better of with a file manager or some specific program. So, on this base, it must be generic enough. That means a need of lots of objects being exposed and creation of complex constructions. Not an easy task, and already very well covered by script languages like Python/Ruby/Perl and bash, but without the burdening that a combination of them would bring (and all the problems related to portability/maintenance). If the developers are conscious of that and are prepared to a long and uphill battlefield for usage and see a real need to it, well, all power to them.
On Microsoft case, there was a strong need of a powerful shell script language, the lacked one. On unix systems we already have many. Not that Hotwire would not find its way, just pointing out that will be a really tough battle.
Running irssi in this shell is not possible. How this is supposed to be usable?
Type “term irssi”. You need only prefix a command with ‘term’ once for it to be remembered as such. After that you can just say “irssi”. See:
http://code.google.com/p/hotwire-shell/wiki/HotwireCommandInput