* Extending zsh capabilities [not found] <199807270524.BAA22704@math.gatech.edu> @ 1998-07-27 10:07 ` Mark Hessling 1998-07-27 11:18 ` Bruce Stephens 0 siblings, 1 reply; 6+ messages in thread From: Mark Hessling @ 1998-07-27 10:07 UTC (permalink / raw) To: zsh-workers Hi Guys, I have been using zsh for several years now and have had no complaints! What I want to do now is add optional support for Rexx programs into a shell, and figured that zsh would be the shell to use. Firstly, would there be any objections to me adding this support and getting it into the "official" distribution ? Secondly, what assistance might I be able to get to point me in the right direction ? I originally tried adding this support to bash, but couldn't get it to work; probably because I didn't know enough of the internals of bash to know where the right place was to hook the Rexx support into. I've had a look at Zsh modules in 3.1.3, but don't think that this mechanism will work. Maybe it will, but that's where I need some knowledgeble advice. Before I go too much further, I'll explain what I want to do and someone hopefully can provide some pointers. All Rexx program begin with /* in the first two characters of the first line of an executable file (much like #!). When zsh comes across a Rexx program, I want to execute this program within the shell, but unlike #! programs, execute within the current process. So I can't use the #! hook. Executing a Rexx program within a current process is straighforward, I need to call the API function RexxStart() with the filename as one of the arguments. The interface is simple; its knowing where to hook it into zsh that is my biggest problem. Any comments, suggestions or pointers greatly appreciated. Cheers, Mark ------------------------------------------------------------------------ Mark Hessling Email: M.Hessling@qut.edu.au PO Box 203 http://www.lightlink.com/hessling/ Bellara AUTHOR of | MAINTAINER of QLD 4507 THE | PDCurses Australia Rexx/SQL | Regina Member of RexxLA: http://www.rexxla.org/ ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Extending zsh capabilities 1998-07-27 10:07 ` Extending zsh capabilities Mark Hessling @ 1998-07-27 11:18 ` Bruce Stephens 1998-07-27 12:13 ` Peter Stephenson 0 siblings, 1 reply; 6+ messages in thread From: Bruce Stephens @ 1998-07-27 11:18 UTC (permalink / raw) To: zsh-workers Mark Hessling <m.hessling@qut.edu.au> writes: > Executing a Rexx program within a current process is straighforward, > I need to call the API function RexxStart() with the filename as one > of the arguments. The interface is simple; its knowing where to > hook it into zsh that is my biggest problem. [caveat: I don't know much about zsh internals] A first thought is to look at where the shell executes external commands, and fiddle there. But as you comment, that's in the wrong process. There're presumably lots of subtleties to do with io redirection, interruptability and things, so looking at builtins is probably better. How about, as a first cut, writing a builtin "rexx" which would execute a Rexx script? That could be done as a module (like stat). I'd have thought that would be acceptable in usage too: you'd just create aliases for Rexx scripts you used a lot. If not, you could change the unknown function so it would try executing an unknown command as a Rexx script, or work a bit harder. Probably Zefram has better ideas; I'm sure he was threatening to do the same for Perl. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Extending zsh capabilities 1998-07-27 11:18 ` Bruce Stephens @ 1998-07-27 12:13 ` Peter Stephenson 1998-07-29 22:59 ` Mark Hessling 0 siblings, 1 reply; 6+ messages in thread From: Peter Stephenson @ 1998-07-27 12:13 UTC (permalink / raw) To: Zsh hackers list; +Cc: Mark Hessling Bruce Stephens wrote: > > Executing a Rexx program within a current process is straighforward, > > I need to call the API function RexxStart() with the filename as one > > of the arguments. The interface is simple; its knowing where to > > hook it into zsh that is my biggest problem. > > How about, as a first cut, writing a builtin "rexx" which would > execute a Rexx script? That could be done as a module (like stat). I would have thought that was a good place to start; adding additional capabilities in modules is very much preferred from the development point of view, and makes it much more likely the code would be acceptable in the main distribution. This should be very easy: just take e.g. stat.c, rename everything, and prune it right down so that you just have one function bound to the builtin rexx which calls RexxStart on its filename. What you really then want is for a shell function beginning /* to run Rexx. You can do this by sleight of hand. % fpath=(. $fpath) # just for convenience in this example % alias '/*'='rexx_load $0' % cat rexx_load local file=$1 dir for dir in $fpath; do [[ -f $dir/$file ]] && file=$dir/$file && break done print "Executing $file using Rexx" # rexx $file # Now force the calling function to return immediately. trap 'return 0' EXIT % cat rtest /* This is to test rexx_load */ Rexx commands here % autoload rexx_load rtest % rtest Executing ./rtest using Rexx This works because zsh allows you to alias '/*' which presumably isn't going to appear as a command anywhere else. The other tricky bit is the trap in rexx_load which forces its parent (in this case the function rtest running under zsh, which you don't want to continue) to return immediately, since the EXIT trap is executed in the surrounding context. You could extend rexx_load so that it redefines rtest to run rexx on a series of commands (if e.g. rexx has a -e switch like perl), eliminating the intermediate step for subsequent calls. -- Peter Stephenson <pws@ifh.de> Tel: +39 50 844536 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Extending zsh capabilities 1998-07-27 12:13 ` Peter Stephenson @ 1998-07-29 22:59 ` Mark Hessling 1998-07-30 8:04 ` Zefram 1998-07-30 8:15 ` Peter Stephenson 0 siblings, 2 replies; 6+ messages in thread From: Mark Hessling @ 1998-07-29 22:59 UTC (permalink / raw) To: zsh-workers On Mon, 27 Jul 1998, Peter Stephenson wrote: > Bruce Stephens wrote: > > > Executing a Rexx program within a current process is straighforward, > > > I need to call the API function RexxStart() with the filename as one > > > of the arguments. The interface is simple; its knowing where to > > > hook it into zsh that is my biggest problem. > > > > How about, as a first cut, writing a builtin "rexx" which would > > execute a Rexx script? That could be done as a module (like stat). > > I would have thought that was a good place to start; adding additional > capabilities in modules is very much preferred from the development point > of view, and makes it much more likely the code would be acceptable in > the main distribution. This should be very easy: just take e.g. stat.c, > rename everything, and prune it right down so that you just have one > function bound to the builtin rexx which calls RexxStart on its filename. > > What you really then want is for a shell function beginning /* to run Rexx. > You can do this by sleight of hand. > > % fpath=(. $fpath) # just for convenience in this example > % alias '/*'='rexx_load $0' > % cat rexx_load > local file=$1 dir > for dir in $fpath; do > [[ -f $dir/$file ]] && file=$dir/$file && break > done > > print "Executing $file using Rexx" > > # rexx $file > > # Now force the calling function to return immediately. > trap 'return 0' EXIT > % cat rtest > /* This is to test rexx_load */ > Rexx commands here > % autoload rexx_load rtest > % rtest > Executing ./rtest using Rexx > > > This works because zsh allows you to alias '/*' which presumably isn't > going to appear as a command anywhere else. The other tricky bit is > the trap in rexx_load which forces its parent (in this case the function > rtest running under zsh, which you don't want to continue) to return > immediately, since the EXIT trap is executed in the surrounding context. > > You could extend rexx_load so that it redefines rtest to run rexx on > a series of commands (if e.g. rexx has a -e switch like perl), eliminating > the intermediate step for subsequent calls. > > -- > Peter Stephenson <pws@ifh.de> Tel: +39 50 844536 > WWW: http://www.ifh.de/~pws/ > Gruppo Teorico, Dipartimento di Fisica > Piazza Torricelli 2, 56100 Pisa, Italy > Thanks guys. I started to go this way, but got stumped early on. I downloaded zsh 3.1.3 and am attempting to build it. Unfortunately I am having problems :-( I have tried building zsh under HP-UX 9.04 and Solaris 2.5 and am getting the same errors. I've even tried replacing the HP-UX sed with the latest GNU sed, thinking it was a problem with sed, but that didn't help. If anyone can help with the following problems, please let me know. TIA. ................ output from ./configure --enable-dynamic ............. checking whether symbols in the executable are available... (cached) yes checking whether executables can be stripped... (cached) yes checking whether libraries can be stripped... (cached) yes creating ./config.status creating Makefile Can't open :Makefile.in creating Doc/Makefile Can't open :Doc/Makefile.in creating Etc/Makefile Can't open :Etc/Makefile.in creating Src/Makefile Can't open :Src/Makefile.in creating config.h :config.h.in cat: cannot open :config.h.in config.h is unchanged zsh configuration ----------------- zsh version : 3.1.3 ................................................................... With my very limited REGEXP knowledge I made a couple of changes and got the Makefiles and config.h created. Then, this is what I got on the first attempt at make: $ make if test D = N; then \ cat ./xmods.conf > modules-bltin; \ elif test yes != yes; then \ echo comp1 > modules-bltin; \ else \ echo > modules-bltin; \ fi ( cd .. && /bin/sh Src/mkmodindex.sh Src ) \ > modules.index.tmp Updated `modules.index'. cd .. && /bin/sh $top_srcdir/Src/mkmakemod.sh Src Makemod creating Src/Makemod.in creating Src/Makemod Can't open !Src/Makemod.in make: Fatal error: Don't know how to make target `prep' Current working directory /home/solaris/mark/zsh-3.1.3/Src make: Fatal error: Can't find `Makemod': No such file or directory Current working directory /home/solaris/mark/zsh-3.1.3/Src *** Error code 1 make: Fatal error: Command failed for target `headers' Current working directory /home/solaris/mark/zsh-3.1.3/Src *** Error code 1 make: Fatal error: Command failed for target `all' Cheers, Mark ------------------------------------------------------------------------ Mark Hessling Email: M.Hessling@qut.edu.au PO Box 203 http://www.lightlink.com/hessling/ Bellara AUTHOR of | MAINTAINER of QLD 4507 THE | PDCurses Australia Rexx/SQL | Regina Member of RexxLA: http://www.rexxla.org/ ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Extending zsh capabilities 1998-07-29 22:59 ` Mark Hessling @ 1998-07-30 8:04 ` Zefram 1998-07-30 8:15 ` Peter Stephenson 1 sibling, 0 replies; 6+ messages in thread From: Zefram @ 1998-07-30 8:04 UTC (permalink / raw) To: Mark Hessling; +Cc: zsh-workers Mark Hessling wrote: >I downloaded zsh 3.1.3 and am attempting to build it. Unfortunately I >am having problems There were some bugs in the build process in 3.1.3. These are fixed in 3.1.4. -zefram ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Extending zsh capabilities 1998-07-29 22:59 ` Mark Hessling 1998-07-30 8:04 ` Zefram @ 1998-07-30 8:15 ` Peter Stephenson 1 sibling, 0 replies; 6+ messages in thread From: Peter Stephenson @ 1998-07-30 8:15 UTC (permalink / raw) To: Zsh hackers list, Mark Hessling Mark Hessling wrote: > I downloaded zsh 3.1.3 and am attempting to build it. Unfortunately I > am having problems :-( These are intrinsic to 3.1.3, unless you are running a sh which is actually zsh in disguise. 3.1.4 should be around on the official archives and has this fixed. I realised my trick of aliasing /* probably doesn't work for complex Rexx scripts, because zsh tries to parse the whole thing first and runs into incompatible syntax. I then thought of doing something with preexec, but I now think that's too limited. Of course, if you know in advance that something is a Rexx script, there are all sorts of things you can do, but I can't offhand think of a really good way when you don't. (Even my /* way implies you had already sorted Rexx scripts into function directories, and if you do that, you might as well have a special directory and use some code in .zshrc to alias foo="rexx $rexxpath/foo" or whatever.) -- Peter Stephenson <pws@ifh.de> Tel: +39 50 844536 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-07-30 8:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199807270524.BAA22704@math.gatech.edu> 1998-07-27 10:07 ` Extending zsh capabilities Mark Hessling 1998-07-27 11:18 ` Bruce Stephens 1998-07-27 12:13 ` Peter Stephenson 1998-07-29 22:59 ` Mark Hessling 1998-07-30 8:04 ` Zefram 1998-07-30 8:15 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).