Re: ideas, questions, and bugs (?)

[TGAPE! <tgape@xxxxxxxxxxxxxxxxxxxxxxxxx>]

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