thanks in advance
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
I like zsh, because it's sh-compatible, brings in a lot of the good ideas
from csh/tcsh, and the license appears to be copyfree rather than copyleft.
man zsh to see that there are so many features they had to break up the
man pages.
--
Sterling (Chip) Camden | camdensoftware.com | chipstips.com | chipsquips.com
Too broad a topic I suspect fo u to get an answer here. In FBSD the
base system is completely separate from the applications, that is
really great because for example your system upgrades are
independendent of applications / ports. The base shell is in the base
system so don't replace the shell for the root user but rather start
bash from your root account if you wish. This will make sense when
your system breaks in an upgrade for example.
For everything else you can safely use bash and choose bash for your
normal users. I use bash all the time even for root, but in the latter
case I start it manually.
Best,
Alejandro Imass
Definitely too broad a topic for a mailing list.
Probably the best way to approach it is to look first at the Bourne
shelli (sh), which probably has the smallest and simplest set of
features.
The C shell (csh) is, as the name suggests, more like the C programming
language. It was developed at UC Berkeley, and thus has always had a
close association with BSD. One of the major innovations introduced by
the C shell is *history*.
tcsh is an enhanced but completely compatible version of csh.
The Korn shell (ksh) combined many features from the C shell with the
functionality of the Bourne shell. Among the many new features
introduced by the Korn shell are pattern-based variable substitution,
e.g. ${varname%%pattern}.
Bash picks up where the Korn shell leaves off, and adds even more
features.
More features usually means increased size and sometimes slower
execution. In fact, if you look at the manpage for bash, the first
sentence in the last section ("BUGS") is a frank admission that "It's
too big and too slow."
It's also too GPL-encumbered for many BSD folk. You can get many of the
same features in a lighterweight package, with a friendlier license, by
going with one of the Korn shells instead. I've been using shells/mksh
from ports after having it recommended to me in the forums, and I've
been very satisfied with it.
It isn't humanly possible to write *all* the differences of *all* the
shells in a single email reply. But you can find a good table that
compares various shells in Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_command_shells
In a FreeBSD context there are also a few more things to consider when
comparing shells:
* Is the shell part of the base system or a port/package?
* Is the shell well maintained?
* Does the shell depend on many other ports or none at all?
* Does the shell support building static-only copies? This is useful
if you want to upgrade the base system without breaking the login
shell you are using every day.
Having said that, here are a few personal notes from my own experience
with shells on FreeBSD...
The /bin/sh and /bin/csh shells are part of the base system, so they are
rebuilt as part of the normal buildworld process. The big advantage of
using a shell that is part of the base system is that it's always
there. Any shell scripts or code you write that uses these shells will
have a great chance of running on ANY FreeBSD system out there. That's
where traditionalism stops and personal preference jumps in though...
I don't like using csh(1) for a lot of things. It syntax makes me
cringe, even though it's a mostly "ok" interactive shell. So I always
install at least bash and mksh on my systems.
There is no bash shell in the *base* system of FreeBSD. But there are
many ports for command shells, and bash is part of these:
# cd /usr/ports/shells
44bsd-csh dash jailkit pdksh tcshrc
Makefile es ksh93 pear-PHP_Shell v7sh
bash esh lshell psh viewglob
bash-completion fd mksh rc vshnu
bash-static fish nologinmsg rssh wapsh
bash3 flash osh sash zoidberg
bash3-static gscommander p5-Shell-Perl scponly zsh
bashc heirloom-sh p5-Term-ShellUI shell-include
ch ibsh pash tcsh_nls
#
You can always install bash with "pkg_add". The default package is not
built as a static binary, but you can compile a static bash binary from
its port:
# cd /usr/ports/shells/bash
# make WITH_STATIC_BASH=1 install clean
The bash shell depends on two other ports: gettext and libiconv. These
are not large ports, but it is often a good idea to have a shell around
that only depends on libc.
This is why I also install 'shells/mksh' on my systems. It's the ksh
compatible shell of the MirOS BSD folks. It has a small foot-print, a
ksh-compatible syntax, and it depends only on libc.so:
keramida@kobe:/home/keramida$ ldd `which mksh`
/usr/local/bin/mksh:
libc.so.7 => /lib/libc.so.7 (0x280c9000)
> You can always install bash with "pkg_add". The default package is
> not built as a static binary, but you can compile a static bash
> binary from its port:
>
> # cd /usr/ports/shells/bash
> # make WITH_STATIC_BASH=1 install clean
I thought that was what this port was for:
Port: bash-static-4.1.5_2
Path: /usr/ports/shells/bash-static
Info: The GNU Project's Bourne Again SHell
--
Jerry
FreeBS...@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________
Do you use that as your interactive shell, for scripting, or both?
>
> man zsh to see that there are so many features they had to break up the
> man pages.
That's kind of scary.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Interactive only. For scripting, I stick to sh unless it gets too complex --
then I jump to Ruby.
>
> >
> > man zsh to see that there are so many features they had to break up the
> > man pages.
>
> That's kind of scary.
True, and it shows in its initial virtual size:
sterling 62630 0.0 0.0 8264 1804 0 I 10:42AM 0:00.00 sh
sterling 62733 0.0 0.1 10284 2932 0 I 10:42AM 0:00.01 csh
sterling 62791 0.0 0.1 10284 2848 0 I 10:43AM 0:00.01 tcsh
sterling 70731 0.0 0.1 14580 4324 0 I 10:46AM 0:00.05 zsh
sterling 71773 0.0 0.1 10220 2908 0 I+ 10:46AM 0:00.01 bash
But on a laptop with 4GB, I don't miss it.
I'm curious about why you prefer zsh for an interactive shell. What zsh
features would you miss if you used tcsh instead (what I've been using)?
I'm always willing to be convinced to try something better.
I cannot say about the tcsh features.
I switched from bash to zsh mainly for excellent vi-mode editing
support, more so over multiple lines. ksh & bash were horrible in
that respect.
Recently I have found that regular expression like [a-d] (instead of
{a,b,c,d}) in file name generation work as expected. zsh has more
ways to help file name generation which I have not looked into yet.
And of course, as stated earlier, compatibility between a bourne
shell script & an interactive shell helps immensely while
developing|debugging a script.
- parv
--
Given my preference for (t)csh syntax over sh syntax for an interactive
shell, I guess that doesn't give me a whole lot of motivation to try it
out. Another response to my question discusses some other benefits,
though. . . .
Thanks for your perspective.
That's kind of a shame, since tcsh is what I prefer these days, having
long since given up on bash (pretty much immediately after I started
using FreeBSD as my primary OS instead of bash, and realized I preferred
the csh-style syntax).
>
> I switched from bash to zsh mainly for excellent vi-mode editing
> support, more so over multiple lines. ksh & bash were horrible in
> that respect.
I've never really tried using vi-mode editing in any shell, despite the
fact I'm a constant vi user (even a vi gangsta, one might say). Maybe I
should some day. Thus far, though, I don't even know if tcsh supports
vi-mode editing.
>
> Recently I have found that regular expression like [a-d] (instead of
> {a,b,c,d}) in file name generation work as expected. zsh has more
> ways to help file name generation which I have not looked into yet.
>
> And of course, as stated earlier, compatibility between a bourne
> shell script & an interactive shell helps immensely while
> developing|debugging a script.
This is another area where I just haven't run into the need for that sort
of thing. When I use a regex at the command prompt, it's via grep,
basically -- I don't tend to get more fancy than something like globbing.
For scripting, I stick to sh and "real" programming languages like Perl
and Ruby. I'm not terribly clear on tcsh's regex support, and I guess if
I needed shell compatibility when writing a shell script (which, for me,
is usually just a batch file, perhaps with a little flow control and a
variable or two) I can always just start sh.
Yes, that's what bash-static enables.
I only mentioned WITH_STATIC_BASH because it's what I usually prefer to
avoid gettext/libintl.so troubles when portupgrade is still half-done
and I want to open a new screen window or xterm.
My pleasure, Chad. If I had learned csh first, I'd probably stick with
tcsh myself.
I'd also like to publicly thank you on this list for encouraging me to
try FreeBSD. I absolutely love it.
I may use this chance to add that I'm also a fan of FreeBSD's csh
especially from the standpoint of dialog behaviour. For example,
autocompletition is - in my opinion - much better than in bash
(which does force too much interaction).
Example:
$ ls /usr/local/bin/m[tab]
BEEP!
*** [tab]
Display all 146 possibilities? (y or n)
*** y
mDNSClientPosix* moc-qt4*
mDNSIdentify* modutil*
--More--(1%)
*** q
$ ls /usr/local/bin/m
The "***" marks all unneccessary interaction that interrupts
work flow.
Also, csh's history behaviour is better - again in my opinion.
For example, if you enter "bl" and press the up / down arrow keys,
you can browse all commands that started with "bl", e. g. "bla",
"bli", "blubb", "blonk" and so on. In bash, you would browse
through *all* commands using the same approach.
I am aware of the fact that most shell behaviour can be configured
or reprogrammed, but I'm just talking about the default settings.
> I've never really tried using vi-mode editing in any shell, despite the
> fact I'm a constant vi user (even a vi gangsta, one might say). Maybe I
> should some day. Thus far, though, I don't even know if tcsh supports
> vi-mode editing.
According to "man csh", it is possible:
The command-line editor (+)
Command-line input can be edited using key sequences much like those
used in GNU Emacs or vi(1). The editor is active only when the edit
shell variable is set, which it is by default in interactive shells.
The bindkey builtin can display and change key bindings. Emacs-style
key bindings are used by default (unless the shell was compiled other-
wise; see the version shell variable), but bindkey can change the key
bindings to vi-style bindings en masse.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Excellent! I don't have to wait until I get off my tuckus to look it up
now. Thank for feeding my laziness.
I consider it a service to mankind to encourage more people using better,
and better-licensed, software. You're welcome, and I'm pleased as punch
it's working out so well for you.