adp@csug.cs.reading.ac.uk (Andrew Pollard) (01/15/91)
Hello,
I am trying to write a shell program (due to the idiosyncracies of gulam), and
I have made several attempts to do input/output redirection with varying degrees
of success. Please could someone out there tell me the 'proper' way to redirect
IO before a pexec call (thinking in terms of a shell program). Do you have to
preload the program, do the redirection, and then re-pexec, etc.
Please mail me any solutions, I will summarise to the net if necessary.
Thanks,
Andrew
--------------------------------------------------------------------------------
| Andrew Pollard | JANET adp@uk.ac.rdg.cs.csug |
| Dept of Computer Science | BITNET adp%csug.cs.rdg.ac.uk@UKACRL |
| Reading, RG6 2AX | INTERNET adp%csug.cs.rdg.uk.ac@nsfnet-relay.ac.uk |
| England. | |
--------------------------------------------------------------------------------rosenkra@convex.com (William Rosencranz) (01/18/91)
In article <1991Jan14.173507.19761@csug.rdg.ac.uk> adp@csug.cs.reading.ac.uk (Andrew Pollard) writes: >Hello, yo... > I am trying to write a shell program (due to the idiosyncracies of gulam), join the club...i, too am doing this, which makes me wonder why we can't just start with gulam source (unless, of course, the author used ATT/BSD code :-). >I have made several attempts to do input/output redirection with varying degrees >of success. Please could someone out there tell me the 'proper' way to redirect >IO before a pexec call (thinking in terms of a shell program). Do you have to >preload the program, do the redirection, and then re-pexec, etc. normally, u use Fdup/Fforce to force stdin/stdout/stderr handles to open file handles. the shell opens the files before the Pexec and closes them after. i don't have code handy, or even a man page, so in general, do: 1) parse cmdline, looking for redirection 2) if so, open the file names (or pipes) 3) Fforce std device handles (stdin, etc) to the open file handles (i would think about opening the files binary, rather than text, as well) 4) set up the command and do the Pexec 5) on return, close the files. note that i recently posted a reasonable popen/pclose, though the MiNT versions would be better. you can also do something like this: sprintf (pcmd, "%c%s %s >file", (char) strlen (cmd), cmd, args); Pexec (..., cmd, ...); tho i have only been able to redir stdout this way (not stdin). this is probably not recommended, at least by me (and doubtless those code police out there who will no doubt jump on me), but it is quick (and dirty). this does not work for all programs. the Fforce should, however. i have written a tiny shell, invoked by my cc(1) to start the various passes of alcyon, which normally cannot be redirected by gulam. i can mail it to u if u want. along these lines, for those of u that are writing a shell, i would offer these suggestions, based on lack of features in gulam: 1) pipes are a must, i.e. "ls -l | grep xxx | wc -l" 2) args in quoted strings include spaces, i.e. grep "a string" file passes "a string" as a single arg to grep, with an imbedded space 3) make it portable 4) support MiNT (and add job control, if possible) 5) RELEASE SOUCE CODE!!!! then the rest of us can improve your work (and be more productive, since YOU also benefit from these improvements) 6) personally, i like history accessible via emacs/vi/cursor keys a l tcsh/ksh. 7) command prompt should be able to deal with imbedded escapes (i.e. ESC p/ESC q for reverse video). gulam gets confused 8) make it possible to redirect inside scripts 9) make it possible to do things like "sh file" (or, if memory serves, "echo 'command' | csh -s") 10) loadable common programs (cat, ls, grep, etc) which stay in memory (i'd rather have them in /bin, too) 11) support something like SLASHCHAR env variable, so cmd lines can use either "cmd /path/file" or "cmd \path\file". shell translates according to SLASHCHAR before exec'ing cmd. it would be nice to support alternate device names, e.g. "/dev/c" for "c:" in cmd lines and scripts. 12) soft links would be a definite plus, if u feel ambitious... these are some of the things i would do to, if/when i write my shell. i would also do away with builtin emacs/file xfer, etc. there are plenty of good standalone codes for this. still, gulam has served us well for all these years. and it is very solid, at least in my experience... pleasant programming.... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
wolfram@cip-s06.informatik.rwth-aachen.de (Wolfram Roesler) (01/25/91)
rosenkra@convex.com (William Rosencranz) writes: >In article <1991Jan14.173507.19761@csug.rdg.ac.uk> adp@csug.cs.reading.ac.uk (Andrew Pollard) writes: >you can also do something like this: > sprintf (pcmd, "%c%s %s >file", (char) strlen (cmd), cmd, args); > Pexec (..., cmd, ...); >tho i have only been able to redir stdout this way (not stdin). this is >probably not recommended, at least by me (and doubtless those code police >out there who will no doubt jump on me), but it is quick (and dirty). this >does not work for all programs. the Fforce should, however. Making this work is up to the program you are Pexecing. Programs compiled with the Megamax C will work with both in and out redir. >i have written a tiny shell, invoked by my cc(1) to start the various passes >of alcyon, which normally cannot be redirected by gulam. i can mail it to >u if u want. I too have written a shell which all but tiny. The ttp is 125K, the sources should be about 10000 lines of C code. Is has ca 100 internal commands. Of your suggested features, it has: > 1) pipes are a must, i.e. "ls -l | grep xxx | wc -l" Yeah. Right this line should work: count all lines of a long file list that contain xxx. > 2) args in quoted strings include spaces, i.e. grep "a string" file > passes "a string" as a single arg to grep, with an imbedded space Yeah too. You can also use single quotes to avoid variable substitution etc. > 3) make it portable Sorry, it isn't. It uses AES, GEMDOS and [X]BIOS plus some system adresses (0x400 onward) in direct access. However, it is C so if you dispense with some features the rest should be portable. > 4) support MiNT (and add job control, if possible) It is outlayed to support Mint (can read out the process table etc) but does not fully support job control. It will as soon as Mint supports the Micro Emacs Editor!!!!! > 5) RELEASE SOUCE CODE!!!! then the rest of us can improve your work > (and be more productive, since YOU also benefit from these > improvements) Source code is available from me. It costs just one pocket calculator. > 6) personally, i like history accessible via emacs/vi/cursor keys > a l tcsh/ksh. History can be accessed with the cursor keys. You can: press Uparrow and recover the previous command line, press Ctrl Uparrrow and execute the previous line, type foo and press Shift Uparrow to recover the last command line beginning with foo, where foo may contain Unix wildcards (*?[]). > 7) command prompt should be able to deal with imbedded escapes > (i.e. ESC p/ESC q for reverse video). gulam gets confused Yeah. The escape character is the circumflex since the backslash is occupied by Tos. Example: echo ^033pThis is inverse^033qthis is not > 8) make it possible to redirect inside scripts Yeah, as well. > 9) make it possible to do things like "sh file" (or, if memory > serves, "echo 'command' | csh -s") Yeah. > 10) loadable common programs (cat, ls, grep, etc) which stay > in memory (i'd rather have them in /bin, too) Most common programs (including cat, ls, grep [but not including etc :-)]) are built-in. It is possible to keep binary programs resident and execute them via shell functions. > 11) support something like SLASHCHAR env variable, so cmd lines > can use either "cmd /path/file" or "cmd \path\file". shell > translates according to SLASHCHAR before exec'ing cmd. it > would be nice to support alternate device names, e.g. "/dev/c" > for "c:" in cmd lines and scripts. You can set a flag which when active translates all slashes to backslash. It is still possible to use slashes by quoting them. > 12) soft links would be a definite plus, if u feel ambitious... Not yet, sorry. Not planned, not considered really useful unless done on OS level. Some other features of the program (called the Okami Shell): Shell functions (=resident scripts), hash table to shorten program search time, shell varaiables, a built-in RPN calculator with some 80 functions, terminal emulator, terminal server and many, many things I dont really remember... In general, it closely resembles the Bourne Shell with most of its specialities (like the type command, $CDPATH, $PATH, export, hashing etc). It's a very solid piece of software. If you find some of the built-in commands unuseful for you, you can get a version without these, thus making the program smaller. It has only two drawbacks: 1) The documentation (about 200K) is is German. Sorry, but I have no time to translate it. It has however a help file with brief explanations which is in English. Maybe you find somebody who is able to read the German documentation. 2) I do not know how to get it by email. There might be a version in the Fido net, so look in the lists of the German nodes (the city is Aachen, try a mailbox called "Uniline", although I am not sure). A safe way to get the Shell is to send a diskette to the following adress: Wolfram Roesler Augustastr. 44-46 5100 Aachen Germany (not West-Germany anymore, fortunately) Dont forget a stamped and adressed return envelope. If you want the sources, dont forget the pocket calculator (if you include a Hewlett Packard you will get the following 10 releases of the shell free of charge). Hope to hear of you! Greetings to those who prefer Unix to Msdos and a command shell to mousing wr