From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28210 invoked from network); 9 Oct 1997 01:45:54 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Oct 1997 01:45:54 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id VAA17522; Wed, 8 Oct 1997 21:38:09 -0400 (EDT) Resent-Date: Wed, 8 Oct 1997 21:37:30 -0400 (EDT) From: TGAPE! Message-Id: <199710082011.UAA00314@dal-tsa6-26.cyberramp.net> Subject: Re: ideas, questions, and bugs (?) To: zefram@tao.co.uk (Andrew Main) Date: Wed, 8 Oct 1997 20:11:56 +0000 (GMT) Cc: quinn@envy.ugcs.caltech.edu, zsh-users@math.gatech.edu In-Reply-To: <199710080934.KAA07190@taos.demon.co.uk> from "Andrew Main" at Oct 8, 97 10:34:19 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sfUVx1.0.yG4.PL3Fq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1062 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Andrew Main wrote: > Quinn Dunkan wrote: > >> When chaselinks is off, there is a problem that the shell's idea of .. is >> different from another program's idea. > > An unavoidable problem with symlinks. If you want consistency, turn > chaselinks on. > >> What I would like is an option that makes it so >> that when chaselinks is off, zsh acts as if you really are in the fake zsh >> path, so it would 'expand' /old/path/symlink/../foo to /old/path/foo. > > Can't be done. There's no way to distinguish a pathname from any other > argument. In any case, a program might generate .. segments itself. Not unavoidable - as long as compctl is set up completely for every command, we have the information available. Check for /../ in the middle of, and ../ at the beginning of, every argument would expand via -f or -g. This may miss a few, but would get the vast majority. I'd do it myself, except that I'm busy and I'm not yet familiar with the zsh code. (Though it looks a lot more readable than the other project I'm trying to fiddle with.) It, of course, cannot get around the program generating the .. sequences itself, even if the program called on a zsh-subshell to evaluate it, unless the program was itself a zsh script (then it gets the path in $PWD which tells it what the perceived path is.) I do admit, however, that we're talking about rediculous things, such as the 'next command' option. BTW, for those of you who are really interested in command prediction, there are programs available which will watch what you type, and try to figure out what you're going to type next. They take months of learning before making predictions, and they're usually wrong, but it can be fun to play with. Unfortunately, I've not paid attention to them in years, as they've never really worked. It could be that I'm just a bit too non-deterministic. >> A $LASTPID or something parameter, which is the pid of the last command run. >> Yes, I know about $!, but that only works if the process is &ed and not at all >> if it forks like a daemon (or maybe daemons pitchfork() ?). Don't let go of that tiger's tail. He'll take you on a nice ride... >> As much as I try, I can't figure out a good way to have zsh execute some >> command at startup and stay in interactive mode. Show us a shell in which you can, and we'll duplicate it. ;> > a history file saved on a trfs (temporally reversed filesystem -- the > media uses positrons instead of electrons). Warning - these systems are notorious for their inability to save your work. Of course, the RAID 1 versions of these do tend to be a little more reliable, so long as the positronic media is only used on the mirror drive. >> Also, is it better to stick vars in zlogin and export them so future >> shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in >> zshenv? > > Put them in zshenv, and export if appropriate. Be sensible. EDITOR, HISTFILE, HISTSIZE, LESS, PAGER, VISUAL, and other such environment variables shouldn't be in zshenv - they can only be used in interactive shells. Of course, setting every environment variable I set takes less than a second; it doesn't hurt *that* much unless you have a *lot* of shell scripts that read /etc/zshenv. (I do - my zshenv contains all of my setopts in it, and most zsh scripts want them.) Question: would it be possible to avoid this whole problem by re-writing /sbin/init as a zsh script? That way, it can export all of the variables, and so you don't need to worry about cron-executed programs having a different environment. >> In zsh 3.0.0, PATH always reflecs path, and vice-versa. In zsh 3.1.2, PATH >> reflects path only if PATH is set. > > This is a feature. Don't unset PATH if you want it to be available. PATH should never be unset. This is an error condition. Most shells I've had an unset PATH agreed on this. Only zsh doesn't actually *tell* you about the error, though. Ed