Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software Windows Books Media Book Reviews Linux

From Bash To Z Shell 214

Posted by timothy from the what-about-ash dept.
r3lody (Raymond Lodato) writes "Novice users and power users of *nix will enjoy reading From Bash to Z Shell: Conquering the Command line by Oliver Kiddle, Jerry Peek, and Peter Stephenson. In this moderate-sized book from Apress, the authors delve into both bash (the Bourne Again Shell) and zsh (Z Shell) to enable you to use them to their fullest advantage. Topics range from the simple editing of the command line to redefining key sequences, down into creating functions for editing and command-line completion. Some areas are covered in other books, but this one goes into some little-seen side streets and alleyways to show you the shortcuts to more efficient use of the shell." Read on for the rest of Lodato's review.
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.
This discussion has been archived. No new comments can be posted.

From Bash To Z Shell More

From Bash To Z Shell

Comments Filter:

  • Which one? (Score:4, Funny)

    by Anonymous Coward on Wednesday April 13, 2005 @05:02PM (#12227457)
    Which shell has a better wallpaper? More options when I right-click?

  • Wouldn't it have been better... (Score:5, Insightful)

    by jgerry ( 14280 ) * <jason...gerry@@@gmail...com> on Wednesday April 13, 2005 @05:02PM (#12227458) Homepage
    Uh, wouldn't it have been cooler to actually go the extra mile with the whole A to Z metaphor and call the book "From Ash to Z Shell"? There is a shell called ash.

  • Oooo, religious wars!! (Score:5, Funny)

    by smcdow ( 114828 ) on Wednesday April 13, 2005 @05:03PM (#12227462) Homepage
    It's like the good old days!!!

    zshell sux!! bash rules!!

    • Did anyone ever actually argue over ZShell? I thought the primary arguments were always the BASH vs. KSH arguments (i.e. general users vs. hardcore unix admins) and the TCSH vs. BASH arguments (there is *some* validity to TCSH being a bit more professional, but BASH is just more useful).
      • (there is *some* validity to TCSH being a bit more professional, but BASH is just more useful).

        My God. Surely you're joking.

        How, exactly, is tcsh more professional ? And more professional than what? Csh? Using Emacs hexl-mode as a shell is more professional than csh.

        • Re:Oooo, religious wars!! (Score:5, Funny)

          by Anonymous Coward on Wednesday April 13, 2005 @05:26PM (#12227707)
          How, exactly, is tcsh more professional

          I once caught bash selling my personal files on ebay. Also, tcsh cured my grandmother of rheumatoid arthritis.

          In related news, emacs is more articulate than vi, three-button mice are sweeter than one-button mice and perl grepped your sister.

          Actually, that last one is true ;-> Sorry.
        • tcsh is a marked improvement over csh. csh is actually harmful [cqu.edu.au]. However my favourite is still bash. I might switch over to zsh though...
    • It's simple, the premiere shell would have...

      -tab completions
      -color code
      -long ass history list

    • set -o vi

      Discuss among yourselves.
    • Well actually, the True Believer will go waaaaay back before this Unix upstart and enter the command CATALOG from a Apple Basic 3.3 prompt, or if "modern school", CAT on a ProDOS line.

      Everytime I try to understand a *nix shell parm I have to switch to Emacs and ask the Doctor....

  • Which shell is best for you? (Score:5, Informative)

    by Greg Wright ( 104533 ) * on Wednesday April 13, 2005 @05:03PM (#12227465) Journal
    I think either shell mentioned in the book is great, I personally use
    bash, mostly just because of historical reasons.

    Speaking of different shells in general. Here is a very handy list
    that can help you pick which shell is best for you. This is not meant
    to start a war over which shell is better but is just meant to help
    pick the shell that is best for you:

    http://www.unix.com/showthread.php?t=12274

    Just thought it would be helpful.

    • zsh plug: Recursive file completion (Score:5, Interesting)

      by gidds ( 56397 ) <slashdot.gidds@me@uk> on Wednesday April 13, 2005 @07:28PM (#12228795) Homepage
      A good chart, but it omits the single feature which for me puts zsh head and shoulders over the others: recursive globbing.

      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.

    • That chart is years old. Perhaps even as much as a decade.

      There are way more new features that could be added to it. Especially from zsh. Many of zsh's strongest features are not even mentioned.

      For ksh, it is only looking at ksh88 which is what comes with Solaris, AIX etc. ksh93 has many more features related to scripting, some of which this book mentions. Since the release of version 93q earlier this year, ksh is now licenced under the CPL making it properly open source so you can even get it in Debian.
  • I would've personally prefered "From ash to zsh"
  • Other than that omission, I will add it to my "must waste time at Borders sipping coffee and avoiding my insane family" reading list.

  • Don't believe it. (Score:2, Funny)

    by Anonymous Coward
    but this one goes into some litte-seen side streets and alleyways to show you the shortcuts

    Oh sure, those dark alleys might seem to be the shortest route to your destination, but really their just a quick path to a mugging.

  • W00t! Finally! (Score:5, Interesting)

    by lpangelrob2 ( 721920 ) on Wednesday April 13, 2005 @05:14PM (#12227593) Journal
    A book I might just buy after reading about it on Slashdot.

    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!").

  • What about COMMAND.COM? (Score:5, Funny)

    by Ann Elk ( 668880 ) on Wednesday April 13, 2005 @05:14PM (#12227596)

    Quickly runs out of the room and hides.

  • Shell is so powerful! I still remember when I made a war game with it 4-5 years ago! I would kill myself if I had to redo it from scratch nowadays!

  • also a good book (Score:4, Informative)

    by carnivore302 ( 708545 ) on Wednesday April 13, 2005 @05:16PM (#12227615) Journal
    Unix shells by example [amazon.com]. Just enough in-depth for my taste. Full of tricks you actually will remember, and if you don't remember the exact syntax it can be quickly found in the book again (which I occasionally/often have to do... Kudos to those that can write commands with multiple single and double quotes in one go :-) ).

    The book is mostly on bash, and c-shell.

  • SASH? (Score:2, Informative)

    by techfury90 ( 806273 )
    I still can't figure out why the Irix bootloader is called SASH, which means the standalone shell... it would make you think it lets you do unix like things without Irix booted, but nooooo it uses the same syntax and commands even as the PROM monitor uses, except sash can read XFS volumes unlike the boot PROM and list the contents of directories.
    • SGI's MIPS-based machines (and their first NT PC too) used an ARCS PROM and SASH bootloader. These come from the Advanced RISC Computing Specification, back in the pre-Pentium days when people thought Intel was about to drop into obscurity.

      SASH is pretty slick, actually.
  • At the local community college, bash is taught in all the linux classes. They did an informal study about which shell to use, and they found out if the instructor doesn't use bash while teaching how to use the shell, the students can't handle bash when they get to the university.

    The flip-side is that students who don't know how to use the different shells are probably screwed anyway once they get into the real world. Go figure.

    • Re:bash rules! (Score:3, Informative)

      by pilkul ( 667659 )
      The flip-side is that students who don't know how to use the different shells are probably screwed anyway once they get into the real world. Go figure.

      If I'm thrown into a shell I don't like, I just type "bash"<enter> and that's that. If the students can't figure that one out, they really are screwed.

    • If your college is teaching classes on shell scripting, I can understand the availability of bash courses because of its popularity in the ever growing linux world, but you make it sound like what is mainly being taught here is how to interact with the shell (ie "use it").

      Because of scripting, even the slightest difference between shells becomes very important, but for interactive use the differences often become trivial. Anyone who is familiar with any sort of unix shell can "handle" bash, even if they a

      • I personally would like to know the details of that study you mentioned. Is it possible that rather than not being able to handle bash at the universities, the students simply choose not to use it because they prefer something else?

        It was an informal study (probably an end-of-semester survey) conducted by the department for it's own internal use. The instructor mentioned it during the linux course on why we were using only bash for the scripting excercises. I think the real problem is that some students
        • Yeah, I can see how compatibility can break very easily in terms of scripting exercises. I've noticed that sometimes it's hard to find the proper resources in the online documentation for figuring out little scripting quirks. Maybe it'd be easier for them to utilize a different shell if more help were available in that area.

  • Why I love zsh (Score:5, Interesting)

    by winkydink ( 650484 ) * <sv.dude@gmail.com> on Wednesday April 13, 2005 @05:24PM (#12227688) Homepage Journal
    Back in '91 or so, I lost legitamate source-code access to ksh. bash was around but, at the time, it only had emacs-like command-line editing. I then discovered that a bunch of folks in the CS dept at Princeton were developing a new (to me anyway) metashell called zsh that was, for the most part a ksh workalike with vi-like command-line editing.

    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.
    • bindkey -v

      put that in your ~/.zshrc if you always want vi keys enabled. Or you could have bought the book that was reviewed.
      • I'm sorry, that wasn't my question. I know of bindkey -v. I've been using the shell for 14 years.

        My question is, how do I make the command esc-esc put the last command in the history file into a full vi session?

        Or, in simpler terms, how do I make esc-esc execute the 'fc' command? I've tried lots of clever ways over the years, none of them have worked.

        • I think I remember what you are talking about...

          Are you thinking of 'ESC-k' (or 'ESC-up-arrow') which opens the commandline history? That's like the 'fc' command, without opening a vi session.

          In the ksh93, the vi command-line editing actually consisted of some vi-style commands, some ksh-only style commands, and some emacs-style.

          I think the ESC-ESC was a ksh-only command, or it was some common binding on some OSs... but it wasn't universal. ksh93 was annoyingly different on Solaris 8 vs HPUX or AIX. Drov
          • No, I use Esc-k and Esc-/ (search) all day long.

            Esc-Esc might have been a ksh-only command, which would explain why I can't get it work with zsh. It really changed how I protyped shell scripts and probably helped me move to perl (if I have to open the editor window anyway, etc...)

    • Re:Why I love zsh (Score:4, Interesting)

      by Anonymous Coward on Wednesday April 13, 2005 @06:54PM (#12228550)
      Whilst I am no expert on ZSH, the following seems to do what you ask for

      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)

    • Re:Why I love zsh (Score:2, Informative)

      by Alakaboo ( 171129 )
      In bash (and ksh) I hit ESC to enter command mode, then v to bring up (v)isual mode. Perhaps zsh is similar? HTH.

  • Best shell (Score:5, Funny)

    by Kaa ( 21510 ) on Wednesday April 13, 2005 @05:26PM (#12227704) Homepage
    My shell is
    perl -d -e 42

  • New ideas (Score:3, Informative)

    by /ASCII ( 86998 ) on Wednesday April 13, 2005 @05:51PM (#12227940) Homepage
    <shameless plug>

    I think both zsh and bash could use a redesign. The syntax is crufty, with stupid variable assignment syntax ('foo = bar' is not the same thing as 'foo=bar'? '$foo' is not the same thing as `$foo` or "$foo"?), insufficient tab-completion support and very few features enabled by default.
    I have written a shell called fish [no-ip.org]. It has lots of new features [no-ip.org]. Check it out.

    </shameless plug>

    • Suggestion (Score:5, Funny)

      by metamatic ( 202216 ) on Wednesday April 13, 2005 @06:10PM (#12228149) Homepage Journal
      I cordially propose that the default prompt of your new shell be changed to

      }><(([@>

      for reasons which should be obvious.
    • '$foo' is not the same thing as `$foo` or "$foo"?

      echo $foo

      will give you the value of $foo (say, "bar").

      echo "$foo"

      will return the string "$foo"

      `$foo`

      will give you the output of the command, if the value of foo is set to a recognized command. Useful for combo commands.

      These are convenient, and not too hard to remember. Just out of curiosity, how are these things done in fish?

      • Re:New ideas (Score:3, Informative)

        by /ASCII ( 86998 )
        No, you are wrong.

        In bash:

        $foo gives you the contents of variables foo as a list of space-separated strings. "foo bar" becomes "foo" and "bar".

        "$foo" gives you the contents of variable foo as a single variable. "foo bar" remains "foo bar".

        '$foo' gives you the string "$foo".

        `$foo` executes the command pointed to by the variable foo in a subshell. If foo has the value "ls" executes the "ls" command.

        In fish:

        $foo gives you the contents of variable foo as a single string, "foo bar" remains "foo bar".

        "$fo
        • No, I am (mostly) right and you are (partially) wrong.

          If the value of $foo is "bar", then $foo, "$foo", and '$foo' all give the error "bash: bar: command not found"

          echo $foo

          and

          echo "$foo"

          both return "bar."

          echo '$foo'

          returns "$foo." If $bar has the value "ls", then

          grep foo `$bar`

          will search for 'foo' in whatever is listed in your directory.

          My basic point was, the quoting mechanism is no more complicated than the (US) English sentence: I said, "He explicitly said to me, 'don't feed them after


          • Right, but consider variables with spaces. Here's what the OP is getting at:

            #!/bin/bash

            foo="foo bar"
            for baz in $foo; do echo "1: $baz"; done
            for baz in "$foo"; do echo "2: $baz"; done

            produces output:

            1: foo

            1: bar
            2: foo bar

            ... because in bash, $foo is treated as a list of space-separated strings, while "$foo" gives the entire contents of the variable.

            On the other hand, 'fish' tries to avoid this, and presumably would produce:

            1: foo bar

            2: $foo

          • I was referring to what the result of globbing on the different parameters, I was not talking about what would be the result of trying to use values like '$foo' as a command, which does not make sense.

            Like a previous poster pointed out, echo $foo does not do what you think it does, it just happens to work in your example since your string does not contain spaces.
        • I think you're a little bit confused about how shells like bash work.

          If you write $foo when foo="foo bar", it does not "become" two separate strings. Variable interpolation in shells is just a textual search-and-replace. So if you write:

          $ ls $foo

          Here's what the shell does:

          1. Perform variable interpolation: now the command is ls foo bar

          2. Interpret the command. It splits the command into parameters using the contents of IFS, which is set to space, tab, and newline by default. So now the command

    • Re:New ideas (Score:5, Funny)

      by lawpoop ( 604919 ) on Wednesday April 13, 2005 @07:51PM (#12228999) Homepage Journal
      A shell called fish? Can you call it shellfish for short? Did you make it GPL? If so, thanks for not being selfish with shellfish!

  • Unicode (Score:5, Insightful)

    by olafc ( 183227 ) on Wednesday April 13, 2005 @06:05PM (#12228093)
    I like zsh and use it a lot, but there is just one big feature still missing: proper unicode support.

    I know they started working on it in february, at least more actively then before. So it will come eventually. Once the internals are done they will move on to the line editor.

    Untill then, it still "eats" my prompt when backslashing over multibyte characters... :(

  • Wicked! (Score:5, Informative)

    by veg_all ( 22581 ) on Wednesday April 13, 2005 @06:39PM (#12228412)
    . 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.

    What a timesaver! I start so many commands with
    $ March 2004
    In all seriousness, though, I'd like to stick my suggestion in here: Wicked Cool Shell Scripts [intuitive.com] is a charming little read and the scripts are all on line!

  • I may be one of the few here who don't do much in the way of coding (I'm a MechE) but I can't be the only person reminded of the TI-85 application called ZShell. Anyone else have fond memories of this?

  • Mr Old fashioned (Score:3, Insightful)

    by mrbooze ( 49713 ) on Wednesday April 13, 2005 @07:01PM (#12228597)
    Every shell script I write can run in a non-dynamic bourne shell. With all my years of supporting dozens of different flavors of unix, I grew accustomed to never assuming what shells may or may not be available on a given system.

    #!/bin/sh 4 LIFE!
    • Yeah, except that it might not actually be *sh*. Bash, ksh, and zsh all do compatibility modes, and all are (at least to some extent) mutually incompatible. So you're fucked, basically.

    • Re:Mr Old fashioned (Score:3, Insightful)

      by PigleT ( 28894 )
      For scripting, maybe, unless you know the script isn't going to go off your box. For actual command-line interaction, give me zsh or give me death. "Compatibility" is no reason not to learn what fun *can* be had.

  • IPython (Score:5, Interesting)

    by ultrabot ( 200914 ) on Thursday April 14, 2005 @02:47AM (#12231290)
    Those shopping for a shell, and with a taste for Python, would do well to check out ipython [scipy.org].

    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.
  • Unix, Books, Linux, okay... But any idea why they added the Windows icon to this story?? Because those shells run under Cygwin? Wouldn't then at least make as much sense to put BSD and even Apple icons as well?

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close