From Bash To Z Shell 214
| From Bash to Z Shell: Conquering the Command Line | |
| author | Oliver Kiddle, Jerry Peek, and Peter Stephenson |
| pages | 472 |
| publisher | Apress |
| rating | 9 |
| reviewer | Raymond Lodato (rlodato AT yahoo DOT com) |
| ISBN | 1590593766 |
| summary | An in-depth look at the functionality of bash and zsh. |
A *nix-style shell is available on a number of platforms, so the authors chose not to limit themselves to just one, such as Linux. The techniques they discuss can be used in Unix, as well as under Windows using cygwin.
In case you're not overly well-versed in shell handling, the first part of the book does a pretty good job covering all of the things a typical user might want to do. Basic command editing, I/O redirection, jobs, processes, and some simple scripting are all covered. For many users, this is also as far as they would like to go. However, reading a little further yields treasure.
The next part delves into bash version 3.0 and zsh version 4.2, both freely available on the Internet. In addition to more sophisticated command line editing techniques, the authors also delve into the misty realms of re-binding keys. A great many users find themselves typing the same sequences over and over again. While sometimes a script makes sense to encapsulate these sequences, sometimes you want to simply enter some text and that's where a key binding makes sense. One example given in the book for zsh is bindkey -s '\C-xt' 'March 2004\eb' . After the binding, typing CTRL-x t puts the string 'March 2004' onto the command line, and moves the cursor under the '2' so you can insert the day of the month. That's a very simple example for a very powerful facility. A good chunk of chapter 4 is spent on showing how to make the most of bindkey (or its bash cousin 'bind').
The next few chapters cover common topics of prompt strings, file/directory globbing, and shell history. Then, significant press is given to the subject of pattern matching. Many people understand basic pattern matching and regular expressions, but From Bash to Z Shell goes into careful detail, with many examples from both bash and zsh, to contrast the (minor) differences between these two powerful shells. The next chapter discusses command line and file/directory name completion, a topic usually glossed over in other texts. Finally, job processing wraps up Part 2.
The third and final part of the book deals with extending the shell using variables, scripts, and functions. Here's where we get into the nitty-gritty. The first two chapters go over familiar territory: shell variables and shell programming. The chapter on programming is easy to follow, and I suggest you try the examples as you go to get the most out of it. The last two chapters focus on topics frequently overlooked: editor functions, and completion functions. Editor functions allow you (with bind[key]) to define new capabilities to use while editing the command line. This is where a true power user can shine, creating a suite of new functions to speed his/her use of zsh or bash. Completion functions work in defining new ways for the shell to complete a command, file name, or directory, based on a user-written function. Honestly, it's not something I would tend to use, but the capability is intriguing.
All in all, From Bash to Z Shell provides a frequent shell user with a plethora of new insights into customizing the bash and zsh shell programs to fit his/her tastes. The authors have filled a void in tackling the subject of customizing the shell rather than just simply using it. I would have liked to see more coverage of some of the more standard uses of the shells, just so the book could be a more complete reference, rather than the specialized one it is. Specialized or not, there is a lot offered here, and you couldn't go wrong getting this book.
You can purchase From Bash to Z Shell: Conquering the Command Line from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Oooo, religious wars!! (Score:2, Interesting)
Zsh gaining momentum?? :) (Score:1, Interesting)
W00t! Finally! (Score:5, Interesting)
I like the Advanced Bash Scripting Guide [tldp.org] quite a bit, but I'd also like to learn about other shells, without reading through a mountain of manpages, nor reading through webpages, and just for general interest while riding the El (not because "I need to do x!").
Why I love zsh (Score:5, Interesting)
One thing I have never been able to do successfully is to emulate the old ksh's ability to hit Esc-Esc on the command line and get popped into vi with the last command in the history file ready to be edited. It was such a boon to rapid development of shell scripts. Then again, I don't do as much shell scripting these days, so its probably no great loss.
If anybody knows how to do this, esc-esc thing in zsh and can tell me, I'd be really grateful.
Re:Oooo, religious wars!! (Score:3, Interesting)
Everytime I try to understand a *nix shell parm I have to switch to Emacs and ask the Doctor....
Re:Oooo, religious wars!! (Score:3, Interesting)
Re:Why I love zsh (Score:4, Interesting)
bindkey -s '\e\e' 'fc\n'
This is with a freshly updated debian 'unstable' system,
zsh --version
zsh 4.3.0-dev-1 (i686-pc-linux-gnu)
zsh plug: Recursive file completion (Score:5, Interesting)
I used to find myself using find a lot -- mostly for handling files in subdirectories, and/or for selecting files based on metadata of various kinds. But zsh makes find almost totally unnecessary: it has a simple but very powerful syntax which extends the simple '*' and '?' file completion to allow selection by size/date/type/&c, exclusion lists, user-specified ordering, and most usefully it can select files in subdirectories too. And because it's right there in the shell, the results are easy to use without that awkward -exec syntax. I don't think I've used find once since switching to zsh!
I really don't understand why it hasn't become more popular. It's free and open source; it can mimic other shells (notably, ksh), and it ships with systems such as Mac OS X.
Re:Wouldn't it have been better... (Score:4, Interesting)
I say this because I once spent months fixing hundreds of scripts in an embedded system after the OS vendor upgraded from bash-1.x to bash-2.x. If you don't need the extras that bash gives you, then use the #!/bin/sh shebang and make sure it works with sh/ash/ksh.
IPython (Score:5, Interesting)
In the 'pysh' mode, it acts as a fully functional system shell, even on Windows. Bash and friends suck on windows, but IPython truly shines there. It really makes the command prompt use of Windows feasible, with bash like filename completion etc. Being able to extend it with python functions (as opposed to separate scripts) is a killer feature as well.
I've actually replaced the command prompt launchers on my KDE desktop with 'ipython -p pysh' launchers.
Re:Oooo, religious wars!! (Score:4, Interesting)
Syntax highlighting can give you a great deal of information. I have written a shell called fish [no-ip.org], that syntax highlights the commands as you are typing them. What I find useful about this is that fish colors potential errors in red. Mistyped commands, non-existant options, reading from non-existing files and loads of other errors can be identified by just glancing on your screen.
</shameless plug>
Re:zsh plug: Recursive file completion (Score:2, Interesting)
that's why you want to use something like:
find | xargs grep
which will not only execute grep only once per few thousand files, but it will also work where ZSH's
"grep
while you're at it, you probably want
find -print0 | xargs -0 grep
Re:ZSH rocks except for one feature (Score:3, Interesting)
I also set these options:The last of those allows history so be shared between concurrently running shells.
Re:Mr Old fashioned (Score:3, Interesting)
There is however another problem related to the one you outline above. bash, zsh and probably most of the other shells in your example do not use the standard test command, but do instead use a builtin with the same name. I think including dozens of standard unix commands such as kill, test and printf in the shell binary as builtins is a design mistake. It breaks the unix tradition of doing one thing and doing it well. At least bash has had some trouble with fd redirections and builtins. A bug in a builtin may cause the entire shell to crash. When the user switches shells or invokes a program directly, and not through the shell, he/she may find out that the programs syntax has changed!
For the reasons outlined above, I think the only commands that the shell should provide as builtins are the ones that can not be implemented as a separate command, such as cd, exit and if.