ideas, questions, and bugs (?)

ideas, questions, and bugs (?)

[Quinn Dunkan]

Well, I'm new to this list, and here I go posting a big huge long suggestion
list.  I looked through the archives and didn't find other people mentioning
any of these things, though.  It could very well be many of these suggestions
require applying existing features in ways I haven't thought of.
So, I ask your patience in reading this, it's kinda long.

according to the zshmisc man page, a sublist is `one or more pipelines seperated
by && or ||'.  Then it says a list consists of one or more sublists optionally
terminated with ;, &, &|, &!, or \n.  So it should be possible to do:
command1 && command2 &
and have the whole conditional execute in the background.  Unfortunately, zsh
runs command1 in the foreground, and if command1 returns 0, runs command2 in
the background.  Bash handles this command properly, btw.  Even csh does this
right, for goodness sake.  Ok, so
(cmd1 && cmd2) &
works, but according to the man page I shouldn't have to do that.

I had a few problems compiling zsh 3.1.2.  Of course, it is an alpha release,
so I didn't expect a pain-free installation, but my difficulties seemed
unusually great.  I wound up changing the configure script (dlopen is in -ldl
on my linux system), and altering zshxmods.h and bltinmods.list to get a
modular binary.  I probably should have just altered the .conf files, but
the comments seemed to indicate they were already right, and my changes didn't
have any effect anyway.

When chaselinks is off, there is a problem that the shell's idea of .. is
different from another program's idea.  So if you do 'cd symlink', zsh's pwd
(and the %~ PS1 escape sequence) reports you as being in /old/path/symlink.
However, you are _really_ in /path/symlink/points/to.  So if you do 'ls
../foo', zsh looks for /path/symlink/points/foo.  If you do 'cd ..; ls foo',
zsh looks for /old/path/foo.  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.  Since
programs being run have no idea if chaselinks is on or not, zsh would have to
do this expansion itself.  It seems it wouldn't be hard to just have every '..'
in the path cancel out its parent.

Here's a random idea:  it would be interesting to generalize the $PATH facility
so one could set up user defined path vars, and use a compctl-like command to
assign them to commands and parts of commands.  So, for example, you could do 

GFXPATH=".:$HOME/gfx/jpg:$HOME/gfx/ppm"
assignpath GFXPATH /usr/local/bin/pbm/*(:t) djpeg cjpeg

Then, if you type 'djpeg foo.jpg >foo.ppm', zsh will search through $GFXPATH
for foo.jpg.  Of course, we'd use a zsh-style $gfxpath array.  I'm not sure
how useful this would actually be.

A nitpick:  in the COMMAND EXECUTION section of zshmisc, it would be nice to
mention the pathdirs option, I read that and assumed zsh couldn't do rc style
path searching, then found pathdirs in zshoptions later.

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() ?).  Many daemons don't
make nice .pid files, and it can be hard to figure out what you just started if
there are many by the same name (the only thing I can figure out is to stat
/proc/pids_of_a_certain_name for one with a timestamp that matches with one
when I started the daemon (if you have a procfs), but that's not ideal).

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.  What I mean is, I would
like a command-line switch like -c but for interactive shells.
E.g. one could set up special zsh sessions with 
% zsh -fr '. $HOME/.special.zshrc'
where
% zsh -c foo
is equivalent to
% zsh -r 'exec foo'
I thought +t might do something like this, unfortunately even with -s it
doesn't seem to consider a pipe `standard input', so
% echo '. $HOME/.special.zshrc' | zsh -s +t
is a no go.

well, I had a description of zsh's autorepeat freezing like Paul Janzen
mentioned a while ago, and then found some comments about $BAUD, setting it to
0 fixed the problem.

if zsh gets a parsing error in an rc file, you get something like:
zsh: unmatched ' [97]
with no indication of what rc file bombed.  Would it be possible to include
the name of the file it came from (how it works for .), so you get
~me/.zshrc: unmatched ' [97] ?

instead of just beeping when the user attempts to scroll the history past the
current line, zsh should just predict the user's next command, so you could
have a forward 'history' as well.  Of course, you could also use this for
command line completion: just hit <tab><enter> to complete your next command
and execute it, if you don't feel like typing the whole thing in.  The
prediction algorithm would be simple: just have the user scan in his brain and
run an emulation in a sub process.  Use dup() to copy all the user's input and
pipe it to the simulation, it ought to think the same thing he's thinking of.
This might not work for non-determinists, though.  Another approch for those
too cheap to buy a brain-scanner (or for ancient unices without /dev/brain
support) would be to construct a markov chain.  It would take a little while to
get reasonably accurate, but after a month or so of learning it might work
ok.

oh, and to Jose Unpingco who mentioned dvorak, it's much easier to change the
keymap at the terminal driver level, instead of individual apps.  various
unices have different methods of changing keymaps at the console, but xmodmap
always works for X, of course.  I use dvorak exclusively, especially in vi, I
have no problems.  In fact, I find vi keys (especially hjkl) awkward under
qwerty (having right-left on one hand and up-down on the other keeps me
un-confused).  'zshrc' is tons of fun to type in dvorak, but not as much fun as
'fvwmrc'

To add some more confusion to the rc file thread, I don't quite understand the
reasons for zprofile/zlogin.  Ok, so you could use zlogin to override commands
in zshrc for login shells... but is this really useful?  I can't think of any
situation that would require this (how many people have non-interactive login
shells?), but it's obviously there for a reason, so maybe someone can help me
out here.  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?  I tend to go for the zshenv route, since I don't want different
behaviour from scripts run from cron, for instance, but is this a bad idea?  In
fact, my zlogin is empty, everything that non-interactive zshs may want is in
zshenv, everything else in zshrc.  Is it better to let progs inherit their
enviroments rather than rescan a large /etc/zshenv every time?  The only thing
I can think of to put in zlogin is things like `fortune'.

I kept wondering where these run-help and which-command aliases were coming
from...  took a look in hashtable.c and found out that they're hard coded!  I
don't think they should be (since if you make a run-help function it will
mysteriously not work right until you unalias run-help, despite the fact that
you never set it in the first place), but in any case, it would be nice if the
man pages were a little more explicit about that (they're defined even when
zle is unloaded!), and any other surprises that may be lurking in the name
space.

My zsh 3.1.2 segfaults when it can't find PATH.  This seems like a bug.
% unset PATH;/bin/zsh-3.1.2 # always segfaults on my system.
% unset PATH;/bin/zsh       # works fine


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.  That means that given:

% unset PATH
% path=(/bin /usr/bin)

zsh 3.0.0 % echo $PATH
/bin:/usr/bin

zsh 3.1.2 % echo $PATH
(nothing)

However, given:

% unset PATH
% PATH=
% path=(/bin /usr/bin)
% export PATH

Both 3.0.0 and 3.1.2 work correctly.  So for now I have PATH= in my zshenv as
a workaround.

Oh, and does anyone know a way to reprint the prompt?  I want to make a widget:

function vi-cmd-mode-boldps { PS1='%B%#%b '; zle redraw-line; zle vi-cmd-mode }

and according ones for a, A, i, I, etc. that unbold the prompt, the idea being
that I can have a nice reminder of what keymap I'm in.  I tested this with
zle clear-screen instead of the (nonexistent) redraw-line, and the prompt
came back mangled (spaces and high chars), but if I hit enter it's like it
should be.  Also, there's a little pause whenever I invoke the widget, which
would make it unusable (too annoying), even if clear-screen didn't already.
So what am I doing wrong?

Re: ideas, questions, and bugs (?)

[Peter Stephenson]

Quinn Dunkan wrote:
> according to the zshmisc man page, a sublist is `one or more pipelines sepera
> ted
> by && or ||'.  Then it says a list consists of one or more sublists optionall
> y
> terminated with ;, &, &|, &!, or \n.  So it should be possible to do:
> command1 && command2 &
> and have the whole conditional execute in the background.  Unfortunately, zsh
> runs command1 in the foreground, and if command1 returns 0, runs command2 in
> the background.  Bash handles this command properly, btw.  Even csh does this
> right, for goodness sake.  Ok, so
> (cmd1 && cmd2) &
> works, but according to the man page I shouldn't have to do that.

Yes, in fact the & in zsh really applies at the level of the pipeline,
which is (necessarily) the same level that job control comes in.  It
certainly looks wrong, but it could be a pain to rewrite.

> 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.

I don't think there is one within the shell.  You could make your
own arrangement:  add a line to .zshrc to . a particular file if it
exists, then delete it, and write a trivial script which creates the
file, then exec's zsh.  There are no doubt equally unpleasant ways.

> if zsh gets a parsing error in an rc file, you get something like:
> zsh: unmatched ' [97]
> with no indication of what rc file bombed.  Would it be possible to include
> the name of the file it came from (how it works for .), so you get
> ~me/.zshrc: unmatched ' [97] ?

This is now fixed, but I couldn't tell you since when now is.

> My zsh 3.1.2 segfaults when it can't find PATH.  This seems like a bug.
> % unset PATH;/bin/zsh-3.1.2 # always segfaults on my system.
> % unset PATH;/bin/zsh       # works fine

As far as I can tell, this is fixed, or maybe I have something set
differently: there's certainly a default path here.

What isn't yet fixed is that with shared libraries, zle doesn't get linked
in until late in the initialisation, and zerr tries to call trashzle(),
with the result that `zsh unknown-file' dumps core.  I haven't found
a cleaner fix than adding if (trashzleptr) to zerr().

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, Platanenallee 6, 15738 Zeuthen, Germany.

Re: ideas, questions, and bugs (?)

[Andrew Main]

Peter Stephenson wrote:
>What isn't yet fixed is that with shared libraries, zle doesn't get linked
>in until late in the initialisation, and zerr tries to call trashzle(),
>with the result that `zsh unknown-file' dumps core.  I haven't found
>a cleaner fix than adding if (trashzleptr) to zerr().

What happened to trashzleptr being initialised to an empty function?

-zefram

Re: ideas, questions, and bugs (?)

[Andrew Main]

Quinn Dunkan wrote:
>                  I wound up changing the configure script (dlopen is in -ldl
>on my linux system), and altering zshxmods.h and bltinmods.list to get a
>modular binary.

What did configure --enable-dynamic get wrong?  It does look for libdl.

>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.

>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() ?).

If the program daemonises, a $LASTPID wouldn't help.  If you want a
PID, you can just background the command -- use wait is you then want
synchronicity.

>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.

Funnily enough, `interactive' implies interaction with the user.  If you
want interaction in a shell script, use vared.

>instead of just beeping when the user attempts to scroll the history past the
>current line, zsh should just predict the user's next command, so you could
>have a forward 'history' as well.

I'd already considered doing this; history references like "!+1" ought
to work.  Of course, to get commands from future sessions you'll need
a history file saved on a trfs (temporally reversed filesystem -- the
media uses positrons instead of electrons).

>                                   Of course, you could also use this for
>command line completion: just hit <tab><enter> to complete your next command
>and execute it,

Ah, but with the new widget interface it's a trivial matter of programming
for each user to write the interface to their own brain scanner.

>To add some more confusion to the rc file thread, I don't quite understand the
>reasons for zprofile/zlogin.

.zprofile is run first thing, in the manner of .profile.  .zlogin is
a csh-like feature -- it is sourced after the normal shell startup,
and so has the user's full normal environment available.

>           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.

>                                   Is it better to let progs inherit their
>enviroments rather than rescan a large /etc/zshenv every time?

You shouldn't have anything in /etc/zshenv.  Most zsh scripts should
also start "#!.../zsh -f" to avoid scanning any initialisation files.

>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.

>Oh, and does anyone know a way to reprint the prompt?

Can't be done.  Yet.  I want to make it possible eventually, so that we
can have a ticking clock in the prompt.

>                                                        I tested this with
>zle clear-screen instead of the (nonexistent) redraw-line,

You want redisplay.

>                                                           and the prompt
>came back mangled (spaces and high chars),

FITNR (I think), but it won't change the prompt.

Actually, that's rather annoying.  I noticed that zsh had a problem with
this when I first used it, back in 2.6-beta4 or so.  I fixed it in the
2.6 series, but due to this causing some other problem it was removed
for 3.0.  The new fix in 3.1 does things properly, but that's too late
for the thousands of people using 3.0.

-zefram

Re: ideas, questions, and bugs (?)

[TGAPE!]

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

Re: ideas, questions, and bugs (?)

[Tim Writer]

TGAPE! <tgape@dal-tsa6-26.cyberramp.net> writes:

> >>           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

Do you mean they belong in .zlogin?  In my experience, this doesn't work very
well in a networked environment, consider:

    rsh thathost xterm -display thishost:0.0

The shell running inside xterm is interactive, but it's not a login shell, so
it won't have EDITOR, HISTFILE, etc. which is probably not what you want.  Of
course, you can use "xterm -ls", but not everybody uses xterm and terminal
emulators such as shelltool don't have a similar option.

> 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 agree with this.  In practice, I find it's easier to put all this stuff in
/etc/zshenv or ~/.zshenv and leave ~/.zlogin for things that are *strictly*
part of logging in, starting X for example.

> (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.

What about environment variables set in ~/.zshenv?  Why not just put "zsh -l"
in your crontab?

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA

Re: ideas, questions, and bugs (?)

[TGAPE!]

Tim Writer wrote:
> TGAPE! <tgape@dal-tsa6-26.cyberramp.net> writes:
>
>>>>           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?
>>
>> 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
>
> Do you mean they belong in .zlogin?  In my experience, this doesn't work very

No, .zshrc is for interactive shells, according to the manpage.  I
haven't actually tested to make sure it's not run for scripts, but I
cannot recall having seen its contens when I've run a script -x.

Strangely, this removes almost all use for .profile...

> well in a networked environment, consider:
> 
>     rsh thathost xterm -display thishost:0.0

Consider 'rsh therehost elm' - game over, man, game over.

> The shell running inside xterm is interactive, but it's not a login shell, so
> it won't have EDITOR, HISTFILE, etc. which is probably not what you want.  Of
> course, you can use "xterm -ls", but not everybody uses xterm and terminal
> emulators such as shelltool don't have a similar option.

Terminal emulators such as shelltool are broken, in many varied ways.
If you use shelltool, you might as well have a broken /etc/zshenv, let
alone one which is merely not obsessively optimized.  Shoot, you might
as well go whole-hog and use vile as your text editor, or maybe ed.

I can't remember all the problems I've had using shelltool, but lately,
since we've gotten the new people, I seem to recall saying, "I never
figured out how to get around that problem in shelltool" a rather lot.

I'll stop here before some router decides that I *really* meant to send
this to alt.sysadmin.recovery, and redirects it for me.  Sorry for
interrupting your discussion with this unscheduled rant.

>> 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 agree with this.  In practice, I find it's easier to put all this stuff in
> /etc/zshenv or ~/.zshenv and leave ~/.zlogin for things that are *strictly*
> part of logging in, starting X for example.

Ugh.  To each their own.  (Though, admittedly, you're already thrice
damned for using SunOS...)

I maybe should point out that, while I once had a full /etc/zlogin,
pretty much everything which was once there has moved to either
~/.z/.zlogin, ~/.z/.zprofile, or /etc/zprofile...

>> (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.
>
> What about environment variables set in ~/.zshenv?  Why not just put "zsh -l"
> in your crontab?

Actually, my crontab doesn't appear to have any environment variable (or
shell variable for that matter) referenced in it at all.  Something
*must* be wrong here.  Ok, who am I, and where's the real Ed?

Ah.  Found them; they were hidden away in a script called by a script.
But, the script set them before using them.  I still want to know what
I did with the real Ed.

Ed