On 22 February 2010 01:33, daid kahl <daid...@gmail.com> wrote:
>>> I just installed zsh recently and was working on making the switch
>>> over from bash for my daily user, provided I can get a few things
>>> worked out.
>
>> Zsh is a wonderfull shell, but it does have a steep learning curve, due to 
>> its
>> many features. Yes, you will bang your head on the wall many and many times 
>> if
>> you don't read the documentation and continue to think in bash terms.
>> Reading the manual (or the "user friendly" documentation) is a must. Zsh is 
>> an
>> example of an open source project with a massive and excellent documentation,
>> so no excuses for not reading it! :)
>

Forgive the reorganization and slight top-posting nature of this post.

Most of my googling to finish setting up zsh and resolve all my issues
now hits this thread!  So since I've gotten everything worked out for
myself, here's what I've done (mostly from manuals and documentation,
but in any case...)

>>> The biggest problem that I can't find useful results googling is zsh
>>> interaction with sudo.
>>>
>>> I'm noticing some strange behavior with the PATH and also the
>>> interpretation of '='.
>>>
> [snip]
>>> So sudo has the PATH set correctly, but it doesn't actually use the
>>> correct path.  Fishy!
>>
>> Nope. If you do
>>
>> sudo echo $PATH
>>
>> $PATH is replaced by the calling shell before sudo even sees it, so no wonder
>> you see the right one (btw, this should also answer your other question on 
>> why
>> doing the same on a second instance of the shell seems to "work").
>> To test what path is seen when sudoing, do
>>
>> sudo zsh -c 'echo $PATH'
>>
>> that should be more accurate. But you already had an indication of what $PATH
>> is in your first command above.
>
> Yes, that's true!
>
>>
>> This might be a good read about where to define PATH:
>>
>> http://zsh.sourceforge.net/FAQ/zshfaq03.html#l19
>>

It's true, this told me what I needed to know.

So now I have critical path information in ~/.zprofile
d...@flux ~ % more .zprofile
#Basic PATH
export PATH="$PATH:/sbin:/usr/sbin"

And more specific pathing and variables in ~/.zshenv
(not boring you with details here)

>>> As for interpretation of '=' I really don't understand what's
>>> happening.  It seems indiscriminate of the case in terms of mucking
>>> about, but the exact result it not always the same.  Consider the
>>> monstrous output in the following simple case of making a new
>>> environment variable:

Yes, setting unsetopt EQUALS in ~/.zshrc works perfectly for me.

I also alluded to some other small points of confusion that I didn't
ask for help on.  None-the-less, I explain how I successfully resolved
these issues in case it can be useful to anyone.

For slim, the issue was that I wanted to copy/paste the bash line in
/etc/slim.conf, but that's too lazy and naive.  The following works
fine (and it would be nice if this was a commented option in the
default slim.conf for n00bs like me):
login_cmd           exec /bin/zsh -l ~/.xinitrc %session

basically, the bash version has -login which zsh doesn't understand
and wants to take as -l -o -g -i -n

Honestly, bash's version should be --login based on standard gnu
styled options IMO.

For home/end keys, /etc/inputrc is not in a format zsh can understand,
so it's an issue to map these manual, say, in .zshrc

However, /etc/inputrc is commented well, and so one can look at that,
use Ctrl+V at the command line, and get the basic idea.  The escape
key, denoted in config files as \e shows up from Ctrl+V at the command
line as ^[

I make a file called ~/.zinputrc which is sourced by ~/.zshrc
A sample line is:
bindkey "\eOH" beginning-of-line

I also find that some of my mappings change between console-login and
xterm mode, so in some cases I have to map things two ways, or
pick/choose if I have some collision (like Ctrl+Arrow in console mode
is the same as an arrow in xterm mode for my machine, so that means I
can't use it for word skipping.  This could be an xinit issue, but in
any case, bash was not doing this either on my machine, so I've not
lost and functionality I was used to having.  A topic for later
perhaps)

Also, if, for example, I use gcc-config to change compilers, then I
need to source /etc/profile.  Well this borks up my nice zsh prompt.
So I edited /etc/profile so that it doesn't do this:

if [ -n "${BASH_VERSION}" ] ; then
        # Newer bash ebuilds include /etc/bash/bashrc which will setup PS1
        # including color.  We leave out color here because not all
        # terminals support it.
        if [ -f /etc/bash/bashrc ] ; then
                # Bash login shells run only /etc/profile
                # Bash non-login shells run only /etc/bash/bashrc
                # Since we want to run /etc/bash/bashrc regardless, we
source it
                # from here.  It is unfortunate that there is no way to do
                # this *after* the user's .bash_profile runs (without putting
                # it in the user's dot-files), but it shouldn't make any
                # difference.
                . /etc/bash/bashrc
        else
                PS1='\...@\h \w \$ '
        fi
elif [ -n "${ZSH_VERSION}" ] ; then
        PS1="%b%{$fg[yellow]%...@%m%{$reset_color%}%b
%B%{$fg[blue]%}%~ %%%{$reset_color%} %b"
else
        # Setup a bland default prompt.  Since this prompt should be useable
        # on color and non-color terminals, as well as shells that don't
        # understand sequences such as \h, don't put anything special in it.
        PS1="${USER:-$(type whoami >/dev/null && whoami)}...@$(type uname
>/dev/null && uname -n) \$ "
fi

All I've done is added the elif for ZSH_VERSION and then pasted my own
prompt there.  This result is nearly identical to prompt gentoo,
except it gives a full path rather than just the working directory.

I can say that I was surprised how difficult migration to zsh is on a
Gentoo system, in the sense that some basic things, like keymaps and
/etc/profile are really just not designed to be compatible with zsh.
Whether or not they should be is a can of worms I won't touch, but I
would like to stress that the zsh Configuration and Installation Guide
in the gentoo handbook (http://www.gentoo.org/doc/en/zsh.xml) tells
you *none* of the things in this post, and I think that at least some
of them might warrant coverage.  But that was updated about 30 months
ago, so maybe it's time for some changes...

Regards,
daid

Reply via email to