Re: Builtin append() and prepend() to PATH, CDPATH, etc.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jun 4, 11:27am, Zefram wrote:
} Subject: Re: A peep into the future.
}
} >6. Hierarchical option settings.  E.g. unsetopt zle automatically
} >   unsetopts's the options dependant on its being set.  It itself also
} >   is an option.  It's there to make understanding the plethora of
} >   options easier for new users.
} 
} That's rather pointless.  If an option has no effect due to the state
} of another option, I'd rather it stayed the way it is, rather than get
} unset.

Exactly.  I don't want to have to reset half a dozen options to get back
to where I started after unsetting only one option!  (That doesn't mean
it wouldn't be a good idea to rearrange the to make option explanations
heirarchical.)

An alternative, however, would be to have options with three states: set,
unset, and disabled.  Options would become disabled if any other option,
upon which they depend, becomes unset or disabled; disabled options go
back to set if all the options on which they depend become set.

Then the question becomes, what happens if you set an unset option, and
it depends on some other unset or disabled option?  Does the newly set
option simply become disabled, or does it force all options upon which
it depends to also become set?

} >zsh 4.0:
} >
} >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
} >    and menu capabilities on text only terminals.  
} 
} It has colour capabilities to some extent: you can put colour sequences
} into prompts quite easily.  I don't see any advantage in having zsh use
} windows in any way.

I tend to agree.  At this point you've rewritten emacs.  Just *get* emacs,
and run zsh in a shell buffer.

} >2.  mount/umount is a shell builtin which simulates working with
} >    virtual filesystems e.g. ftpfs, tarfs, libfs, memfs.
}
} Virtual filesystems, of
} course, should be done in the kernel (for example, userfs under
} Linux).

I agree with Zefram.

} I'd like to see quite a lot of basic administration commands added as
} optional builtins, to make a sysadmin's shell.  There would be a
} configuration option to strip out ZLE, and to add builtins for cp, mv,
} rm, link, sln and so on.

This, on the other hand, has possibilities.

} >3.  zsh can now byte-code its scripts.
} 
} I never tried this, but I think it used to be possible, if you just put
} the token control characters into a script.

Not only does this not save you much, as Zoltan pointed out, but it's
problematic in the face of SH_WORD_SPLIT.  If a single variable reference
can explode into multiple tokens, the script ends up having to be reparsed
and interpreted anyway, and you've actually made parsing MORE expensive.

(Of course, zsh already does a little of this with shell functions.)

} >4.  zsh now supports dynamic files.  If a file has a specific magic no,
} >    it can be handled like a normal file of the *output* of that file.

What the heck does that even MEAN?

} >zsh 10.0:
} >
} >OS_TYPE is a shell variables which can be changed.  zsh simulates the
} >given OS.  Everything is a shell builtin.

(Run screaming in terror)

On Jun 4, 10:37pm, Zoltan Hidvegi wrote:
} Subject: Re: A peep into the future.
}
} I have already did some private hacks to add loadable module support to
} zsh.  This is quite trivial on elf systems (I did this on Linux) but I do
} not know how can it be ported to non-elf systems.

It probably can't be ported to every system on which zsh runs.  I think
with some carefully selected primitives, you could construct scripts to
handle nearly everything that would be useful as a loadable module.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"