Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!bu.edu!olivea!decwrl!nsc!amdahl!krs
From: krs@uts.amdahl.com (Kris Stephens [Hail Eris!])
Newsgroups: comp.unix.shell
Subject: Re: Shell METACHAR's in parameters
Message-ID: <28Oj01wn0eAI00@amdahl.uts.amdahl.com>
Date: 24 Jan 91 00:55:20 GMT
References: <829@marvin.jpl.oz> <11k701EV0dwd00@amdahl.uts.amdahl.com> <1991Jan23.045104.5557@NCoast.ORG>
Reply-To: krs@amdahl.uts.amdahl.com (Kris Stephens [Hail Eris!])
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 25

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"?

Absolutely correct.  I *hate* it when things like that slip my mind.

...Kris
-- 
Kristopher Stephens, | (408-746-6047) | krs@uts.amdahl.com | KC6DFS
Amdahl Corporation   |                |                    |
     [The opinions expressed above are mine, solely, and do not    ]
     [necessarily reflect the opinions or policies of Amdahl Corp. ]