From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: arisawa <arisawa@ar.aichi-u.ac.jp>
In-Reply-To: <8738bdw2hj.fsf@gmail.com>
Date: Sun, 28 Sep 2014 16:00:00 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <D821D108-E39D-4C2D-BD68-6217FE79A996@ar.aichi-u.ac.jp>
References: <CAL0h+tWUCrwWoTSeLz+Kx1yqKwKqwDBZZbH7fLe-PWXjLSgWWw@mail.gmail.com>
	<CADSkJJWP=cdMxXFH_Oo04Cp2tTxfD6kTTeXx22N6BOBBmj3fLA@mail.gmail.com>
	<8738bdw2hj.fsf@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] shell functions
Topicbox-Message-UUID: 175ebe80-ead9-11e9-9d60-3106f5b1d025

Hello,

when rc is invoked, rc reconstructs shell variable and shell functions =
using files in /env/.
in case of shell functions, rc evaluates whole data in the file.
this feature makes problem if the content is
	fn foo {=E2=80=A6}; maliciouscommand
I think this problem must be fixed.

Kenji Arisawa

2014/09/27 23:40=E3=80=81Christian Neukirchen <chneukirchen@gmail.com> =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A
>=20
> The problem could be completely avoided if the '{}' were implicit, =
that
> is, store=20
>=20
> fn foo { echo bar }
>=20
> as
>=20
> fn#foo=3Decho bar
>=20
> (Also, I heard Research Unix v8 sh(1) stored functions in the =
environment
> as "foo(){ ... }", i.e. without =3D.  So this never clashes with any
> variable.  Not sure if that works portably enough for plan9port, =
though.)
>=20
> --=20
> Christian Neukirchen  <chneukirchen@gmail.com>  =
http://chneukirchen.org
>=20
>=20