zle separability

zle separability

[Frederik Eaton]

Hi all,

I'm writing a shell and I'm wondering if there would be an advantage
to trying to use zle instead of readline at least initially. My
impression is that it has a lot of additional features (multiline
editing?) that might be nice to take advantage of, but I'm not sure
how hard it would be to separate it from the rest of the zsh code.

Thanks,

Frederik

Re: zle separability

[DervishD]

    Hi Frederik :)

 * Frederik Eaton <frederik@a5.repetae.net> dixit:
> I'm writing a shell and I'm wondering if there would be an advantage
> to trying to use zle instead of readline at least initially. My
> impression is that it has a lot of additional features (multiline
> editing?) that might be nice to take advantage of, but I'm not sure
> how hard it would be to separate it from the rest of the zsh code.

    I was told once that zle was tightly coupled with the rest of the
shell code. My interest was using zle as a general purpose line
editor (for example for building frontends). Bad luck, because zle is
really *great* and, IMHO, better than readline...

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...

Re: zle separability

[Frederik Eaton]

Thanks. I guess there's always writing a zsh script to do the
interfacing, but that wouldn't be ideal.

(... but, by the way, it would still be nice if such uses for zsh were
better supported, with for instance support for reading an arbitrary
config file or executing an arbitrary fragment before opening an
interactive shell, or for a function which can be defined to handle
all interactive commands)

Frederik

On Mon, Apr 25, 2005 at 01:08:16AM +0200, DervishD wrote:
>     Hi Frederik :)
> 
>  * Frederik Eaton <frederik@a5.repetae.net> dixit:
> > I'm writing a shell and I'm wondering if there would be an advantage
> > to trying to use zle instead of readline at least initially. My
> > impression is that it has a lot of additional features (multiline
> > editing?) that might be nice to take advantage of, but I'm not sure
> > how hard it would be to separate it from the rest of the zsh code.
> 
>     I was told once that zle was tightly coupled with the rest of the
> shell code. My interest was using zle as a general purpose line
> editor (for example for building frontends). Bad luck, because zle is
> really *great* and, IMHO, better than readline...
> 
>     Raúl Núñez de Arenas Coronado
> 
> -- 
> Linux Registered User 88736
> http://www.dervishd.net & http://www.pleyades.net/
> It's my PC and I'll cry if I want to...
> 

-- 
http://ofb.net/~frederik/

Re: zle separability

[DervishD]

    Hi Frederik :)

 * Frederik Eaton <frederik@a5.repetae.net> dixit:
> Thanks. I guess there's always writing a zsh script to do the
> interfacing, but that wouldn't be ideal.

    In fact I've tried to use zpty for building frontends to 'dumb'
programs that doesn't support history or line editing. I tried first
with a simple ftp client, since zftp has some problems for me. The
result is incomplete because I haven't had the time to do it.

> (... but, by the way, it would still be nice if such uses for zsh were
> better supported, with for instance support for reading an arbitrary
> config file or executing an arbitrary fragment before opening an
> interactive shell, or for a function which can be defined to handle
> all interactive commands)

    You already can open an arbitrary config file with zsh using
/etc/zshrc and $ZDOTDIR/.zshrc and a bit of magic (like an
environment variable). If you want, you can use '-c' too or '-s' to
read commands from stdin or from a file. Be careful about closing
stdin too soon or end your script when you shouldn't ;))

    If what you want is to run 'zsh --config=configfile', ok, there's
no support for that.

    For the rest I don't understand clearly what do you want. If you
could give me some use cases I can try to tell you ways of achieving
what you need.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...

Re: zle separability

[Frederik Eaton]

> > (... but, by the way, it would still be nice if such uses for zsh were
> > better supported, with for instance support for reading an arbitrary
> > config file or executing an arbitrary fragment before opening an
> > interactive shell, or for a function which can be defined to handle
> > all interactive commands)
> 
>     You already can open an arbitrary config file with zsh using
> /etc/zshrc and $ZDOTDIR/.zshrc and a bit of magic (like an
> environment variable). If you want, you can use '-c' too or '-s' to
> read commands from stdin or from a file. Be careful about closing
> stdin too soon or end your script when you shouldn't ;))
> 
>     If what you want is to run 'zsh --config=configfile', ok, there's
> no support for that.

Yeah, that's what I wanted. Actually, a way to specify an arbitrary
command to execute after everything is loaded (or not, with -f) would
be a bit more general because you'd just set it to ". ./configfile"...
Sure, making a temporary directory with a special .zshrc in it is
mostly equivalent, but seems like zsh shouldn't make you go through
that mess.

>     For the rest I don't understand clearly what do you want. If you
> could give me some use cases I can try to tell you ways of achieving
> what you need.

Sort of like preexec, except that it executes not *before* the command
but *instead of* the command. So you could set it to something like

myexec () { "$@" }

for normal behavior, or if you wanted to, say, send the commands to
your favorite app that doesn't have a readline interface, you could do
that instead. People may say it's too powerful ... but I still think
it would be nice.

Frederik

Re: zle separability

[DervishD]

    Hi Frederik :)

 * Frederik Eaton <frederik@a5.repetae.net> dixit:
> >     For the rest I don't understand clearly what do you want. If you
> > could give me some use cases I can try to tell you ways of achieving
> > what you need.
> Sort of like preexec, except that it executes not *before* the command
> but *instead of* the command. So you could set it to something like
> 
> myexec () { "$@" }

    You can do that using aliases :? Maybe I'm misunderstanding
anything?
 
    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...

Re: zle separability

[Frederik Eaton]

On Mon, Apr 25, 2005 at 01:39:25PM +0200, DervishD wrote:
>     Hi Frederik :)
> 
>  * Frederik Eaton <frederik@a5.repetae.net> dixit:
> > >     For the rest I don't understand clearly what do you want. If you
> > > could give me some use cases I can try to tell you ways of achieving
> > > what you need.
> > Sort of like preexec, except that it executes not *before* the command
> > but *instead of* the command. So you could set it to something like
> > 
> > myexec () { "$@" }
> 
>     You can do that using aliases :? Maybe I'm misunderstanding
> anything?

If you wanted to use zsh to replace readline, you'd need a way to
intercept the lines it read as commands, and to get zsh to not execute
those lines as it normally would...

Frederik

Re: zle separability

[DervishD]

    Hi Frederik :)

 * Frederik Eaton <frederik@a5.repetae.net> dixit:
> > > >     For the rest I don't understand clearly what do you want. If you
> > > > could give me some use cases I can try to tell you ways of achieving
> > > > what you need.
> > > Sort of like preexec, except that it executes not *before* the command
> > > but *instead of* the command. So you could set it to something like
> > > myexec () { "$@" }
> >     You can do that using aliases :? Maybe I'm misunderstanding
> > anything?
> If you wanted to use zsh to replace readline, you'd need a way to
> intercept the lines it read as commands, and to get zsh to not execute
> those lines as it normally would...

    OK, I understand. You can do that using 'vared'. You have the
full zle power (I think) and the result is stored in a parameter,
never executed unless you want it to.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: zle separability

[Frederik Eaton]

On Mon, Apr 25, 2005 at 06:02:49PM +0200, DervishD wrote:
>     Hi Frederik :)
> 
>  * Frederik Eaton <frederik@a5.repetae.net> dixit:
> > > > >     For the rest I don't understand clearly what do you want. If you
> > > > > could give me some use cases I can try to tell you ways of achieving
> > > > > what you need.
> > > > Sort of like preexec, except that it executes not *before* the command
> > > > but *instead of* the command. So you could set it to something like
> > > > myexec () { "$@" }
> > >     You can do that using aliases :? Maybe I'm misunderstanding
> > > anything?
> > If you wanted to use zsh to replace readline, you'd need a way to
> > intercept the lines it read as commands, and to get zsh to not execute
> > those lines as it normally would...
> 
>     OK, I understand. You can do that using 'vared'. You have the
> full zle power (I think) and the result is stored in a parameter,
> never executed unless you want it to.

So 'vared' has history? How do I enable it?

Frederik

Re: zle separability

[DervishD]

    Hi Frederik :)

 * Frederik Eaton <frederik@a5.repetae.net> dixit:
> On Mon, Apr 25, 2005 at 06:02:49PM +0200, DervishD wrote:
> >     OK, I understand. You can do that using 'vared'. You have the
> > full zle power (I think) and the result is stored in a parameter,
> > never executed unless you want it to.
> So 'vared' has history? How do I enable it?

    No, vared has no history, and I don't know if you can use history
within vared in some way, with some trick, sorry :(

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: zle separability

[Bart Schaefer]

On Apr 25, 12:51am, Frederik Eaton wrote:
}
} Thanks. I guess there's always writing a zsh script to do the
} interfacing, but that wouldn't be ideal.

The Functions/Misc/nslookup script in the zsh distribution is the
classic example of doing this.  If your underlying command doesn't
expect to print its own prompts on a terminal, you can even leave
out the zpty stuff and just do a "while vared" loop.
 
} (... but, by the way, it would still be nice if such uses for zsh were
} better supported, with for instance support for reading an arbitrary
} config file or executing an arbitrary fragment before opening an
} interactive shell, or for a function which can be defined to handle
} all interactive commands)

Interactive shells are for interacting with the shell.  You don't need
an interactive shell to interact with some other command.  E.g. to
repeatedly read command-line arguments of "dig" and then call dig with
those arguments:

zsh -c 'while line=""; vared -e -p "$0: " line; do $0 $=line; done' dig

The use of $0 means you can replace "dig" above with any other command
name and it'll work the same way.  It's a little trickier if you want
to add history support, but not too bad.

Re: zle separability

[Frederik Eaton]

On Mon, Apr 25, 2005 at 04:09:27PM +0000, Bart Schaefer wrote:
> On Apr 25, 12:51am, Frederik Eaton wrote:
> }
> } Thanks. I guess there's always writing a zsh script to do the
> } interfacing, but that wouldn't be ideal.
> 
> The Functions/Misc/nslookup script in the zsh distribution is the
> classic example of doing this.  If your underlying command doesn't
> expect to print its own prompts on a terminal, you can even leave
> out the zpty stuff and just do a "while vared" loop.
>  
> } (... but, by the way, it would still be nice if such uses for zsh were
> } better supported, with for instance support for reading an arbitrary
> } config file or executing an arbitrary fragment before opening an
> } interactive shell, or for a function which can be defined to handle
> } all interactive commands)
> 
> Interactive shells are for interacting with the shell.  You don't need
> an interactive shell to interact with some other command.

Well on a computer you don't *need* anything to do anything. But it's
come up for me before that this would be a very convnient way of doing
certain things. If you want a command which will start a normal zsh
but with a certain environment, you can set the variables and hope the
user's .zshrc doesn't overwrite them. But this isn't ideal, and it
doesn't allow you to configure aliases or functions.

It's not a big deal, I don't know how many others would use it, but I
was surprised to find out that it wasn't a feature.

I have this at the end of my .zshrc, but the fact that it's not
standard (and I would choose a different variable name if it were)
means that there are drawbacks to relying on it in anything I
distribute to others.

if [ -n $RC_CMD ]; then
    eval "$RC_CMD"
    export RC_CMD=
fi

> E.g. to repeatedly read command-line arguments of "dig" and then
> call dig with those arguments:
>
> zsh -c 'while line=""; vared -e -p "$0: " line; do $0 $=line; done' dig
> 
> The use of $0 means you can replace "dig" above with any other command
> name and it'll work the same way.  It's a little trickier if you want
> to add history support, but not too bad.

Can you describe how history support might be added?

Thanks,

Frederik

Re: zle separability

[Bart Schaefer]

On Apr 27, 10:59pm, Frederik Eaton wrote:
} Subject: Re: zle separability
}
} On Mon, Apr 25, 2005 at 04:09:27PM +0000, Bart Schaefer wrote:
} > 
} > The Functions/Misc/nslookup script in the zsh distribution is the
} > classic example of doing this.
[...]
} >  
} > zsh -c 'while line=""; vared -e -p "$0: " line; do $0 $=line; done' dig
} > 
} Can you describe how history support might be added?

Did you try out and/or look at the Functions/Misc/nslookup script?
It is an example of adding both history and completion by using a
wrapper that calls vared in a loop.  It also happens to use zpty to
interpret the interactive prompts of the underlying program, but as
I said you can crop that out if you don't need it.

} > Interactive shells are for interacting with the shell.  You don't need
} > an interactive shell to interact with some other command.
} 
} Well on a computer you don't *need* anything to do anything.

Ahem.  The point is that the shell is just there to execute other
commands.  When you know neither what commands you'll need to execute
nor in what order, then the shell has to be interactive so you can
make a new decision before each command, including choosing things
like changing directory that actually alter the state of the shell.

Conversely, when you know that all you're going to do is repeatedly
run the same command or sequence of commands -- even if possibly with
different inputs or arguments -- then the shell doesn't need to be
interactive.  Nothing you type is going to change the state *of the
shell*.

Note that I'm specifically addressing your request to trap everything
that is typed at a prompt and do something with it other than treat
it as a command.  (Which is possible in ZLE by redefining the various
accept-* widgets, or at least their keybindings, but not supported in
the "raw" shell.)  That has nothing to do with this:

} But it's come up for me before that this would be a very convnient
} way of doing certain things. If you want a command which will start a
} normal zsh but with a certain environment, you can set the variables
} and hope the user's .zshrc doesn't overwrite them.

You don't have to "hope" that at all.  "zsh -f" won't read anything
but the /etc/zshrc file (and you can compile away support for the
/etc files if that's an issue).

} But this isn't ideal, and it doesn't allow you to configure aliases or
} functions.

You seem to be asking for the ENV feature of ksh (which zsh does in
fact support, when emulating ksh), but that isn't something you need
if you're already writing/running a shell script in the first place.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: zle separability

[Peter Stephenson]

Bart Schaefer wrote:
> You don't have to "hope" that at all.  "zsh -f" won't read anything
> but the /etc/zshrc file (and you can compile away support for the
> /etc files if that's an issue).

You mean /etc/zshenv, of course.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: zle separability

[Bart Schaefer]

On Apr 28, 11:04am, Peter Stephenson wrote:
} Subject: Re: zle separability
}
} Bart Schaefer wrote:
} > "zsh -f" won't read anything but the /etc/zshrc
} 
} You mean /etc/zshenv, of course.

Er, yes.  I was 1:15AM here at that point ...