From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NmbYQ-0002jB-56 for garchives@archives.gentoo.org; Tue, 02 Mar 2010 23:31:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F3CD5E0F0E; Tue, 2 Mar 2010 23:30:26 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id B5F6AE0F0E for ; Tue, 2 Mar 2010 23:30:26 +0000 (UTC) Received: by pwi2 with SMTP id 2so449200pwi.40 for ; Tue, 02 Mar 2010 15:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=WYtoskvUAyZ8OTsxBZgqG5sM7PhbHRoSssQI1x8HPRQ=; b=ra+92QeVg51/hoZ2dokHevMT0r66k0Ok091thKHI7rDBU4rUUXUkhuzxisnkBM3lA/ AwVkZCDXHMUsCX3GKTJloDiWLT9yp/eZmN8/TYeqo6La4DQvzaIPQpi8VE+Tgl3xWttU CNUHoks3A5b+LZpdVFAg4uPB2255Nx1dvx33M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=JngjMpTMnJsFc0JAdpHumbkAvgBeHlkfDiNvezreJsthGQF8+aNC38iGlZAEhcUCKh xNvyIkcth6l7QRonbEX6hFti4D8GT1VnYo9qdClm6fWcTi+BqEk/H0QrI+kDgMWeCEo4 givaCZZR5InHT+3YjZnw+bTXE1fruLgGiDcHc= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.143.153.3 with SMTP id f3mr473900wfo.104.1267572626148; Tue, 02 Mar 2010 15:30:26 -0800 (PST) Date: Wed, 3 Mar 2010 08:30:26 +0900 Message-ID: <3ac129341003021530k52b7d4fcl63ba22c6d9963434@mail.gmail.com> Subject: Re: [gentoo-user] zsh and sudo [SOLVED] From: daid kahl To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c8ae07fd-ec48-4e57-8244-31896a28f85b X-Archives-Hash: f2177875c7babf85a522e6fe08cc8cdd On 22 February 2010 01:33, daid kahl 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 ti= mes 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 documenta= tion, >> 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 '=3D'. >>> > [snip] >>> So sudo has the PATH set correctly, but it doesn't actually use the >>> correct path. =A0Fishy! >> >> Nope. If you do >> >> sudo echo $PATH >> >> $PATH is replaced by the calling shell before sudo even sees it, so no w= onder >> 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 daid@flux ~ % more .zprofile #Basic PATH export PATH=3D"$PATH:/sbin:/usr/sbin" And more specific pathing and variables in ~/.zshenv (not boring you with details here) >>> As for interpretation of '=3D' I really don't understand what's >>> happening. =A0It seems indiscriminate of the case in terms of mucking >>> about, but the exact result it not always the same. =A0Consider 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 putti= ng # it in the user's dot-files), but it shouldn't make any # difference. . /etc/bash/bashrc else PS1=3D'\u@\h \w \$ ' fi elif [ -n "${ZSH_VERSION}" ] ; then PS1=3D"%B%{$fg[yellow]%}%n@%m%{$reset_color%}%b %B%{$fg[blue]%}%~ %%%{$reset_color%} %b" else # Setup a bland default prompt. Since this prompt should be useabl= e # 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=3D"${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