Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!helios!archone!byron
From: byron@archone.tamu.edu (Byron Rakitzis)
Newsgroups: comp.unix.shell
Subject: Re: Shell METACHAR's in parameters
Summary: rc creeps in to the discussion
Keywords: rc; arguments, rescanning of.
Message-ID: <11464@helios.TAMU.EDU>
Date: 23 Jan 91 08:08:13 GMT
References: <829@marvin.jpl.oz> <11k701EV0dwd00@amdahl.uts.amdahl.com> <1991Jan23.045104.5557@NCoast.ORG>
Sender: usenet@helios.TAMU.EDU
Organization: College of Architecture, Texas A&M University.
Lines: 65

In article <1991Jan23.045104.5557@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes:
>As quoted from <11k701EV0dwd00@amdahl.uts.amdahl.com> by krs@uts.amdahl.com (Kris Stephens [Hail Eris!]):
>+---------------
>| In article <829@marvin.jpl.oz> david@marvin.jpl.oz (David Magnay) writes:
>| >Can anyone supply a "rule" of how to consistently handle shell parameters inside
>| >a script, when the parameter MAY contain shell meta-characters or a regular
>| >expression. The danger is that the shell is will process the characters, rather
>| >than pass them literally.
>| 
>| 			set -f
>| 			grep $re somefile
>| 			set +f
>+---------------
>
>Still unsafe --- "set -f" in ksh doesn't stop it from splitting at spaces.
>What happens if the value of $re is "x y"?
>

The shell I am almost finished writing, an almost-public (to use Henry
Spencer's turn of phrase) implementation of rc, the AT&T v10 and plan
9 shell, does not have any problems passing arguments in a literal
fashion even if they are stored in variables.

A variable is a list type. If you assign:

a=(one two three)

then when you type:

grep $a

you get {"grep", "one", "two", "three", NULL} passed to grep in
argv[].

However, if you assign

a='one two three'

when you type:

grep $a

grep sees in its argv: {"grep", "one two three", NULL}

It's that simple; after a value has been assigned to a variable, it
is not altered. If a variable has many elements, then each element
of that variable is assigned a slot in argv.

The latest version of rc is available by anonymous ftp from
archone.tamu.edu in ~ftp/pub/rc. The copies of rc are stored by date
(since rc is still changing very fast) but any given copy, if it
compiles on your machine (portability is not quite guaranteed) will
probably be fairly stable on your machine. Of course, let me know
about any problems you have getting rc to work.

For those keeping track of rc's progress, the only big feature left to
go in is heredocs. I will probably add "break" and "return" keywords
by popular demand, but other than that, rc should freeze very soon now.
(i.e., further developments will be confined to a new rc, and the old
rc will be updated for bug fixes and general unix robustness.)

--
---
Byron Rakitzis
byron@archone.tamu.edu