Xref: utzoo comp.sys.atari.st:34060 comp.sys.atari.st.tech:1164
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!samsung!cs.utexas.edu!convex!rosenkra
From: rosenkra@convex.com (William Rosencranz)
Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
Subject: Re: IO Redirection (before a pexec)
Message-ID: <1991Jan17.234815.19695@convex.com>
Date: 17 Jan 91 23:48:15 GMT
References: <1991Jan14.173507.19761@csug.rdg.ac.uk>
Sender: news@convex.com (news access account)
Organization: Convex Computer Corporation; Richardson, TX
Lines: 102
Nntp-Posting-Host: convex1.convex.com

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