On Mon, 5 May 2014 01:23:03 -0400
"Eon S. Jeon" <esjeon_AT_hyunmu.am> wrote:
Hey Eon,
> Indeed, this is a huge concern, even though the argument gets escaped
> befored being tossed into the shell.
no, this is not a huge concern, as discussed. Mentioning this
considerably minimal pitfall in the manual is totally sufficient (hell,
it's bloody obvious).
> In-house string escape code is always deemed insecure and incompetent,
> because of the dynamic nature of shell script language.
What are you talking about? This escape method is proven to be
successful and secure in every but the edge-case presented by Chris.
I consider it insecure and incompetent to change the operating
environment of this process to solve a problem which doesn't exist in
the first place if you know what you're doing.
It's an interesting approach, but damn, don't you know what happens
behind the scenes when setenv() is called? Too much overhead for such a
small tool.
Less code =!= More efficient.
> So, it's always the best if you can avoid
> escaping once and for all.
You should avoid escaping if you don't know how it's done, and in this
case, escaping is rather trivial.
Now, once and for all: I'll mention this minor side-issue of broken
escapes in the manpage and be done with it. I got more important stuff
to do than discussing this crap for days on this mailing list.
The time we spent discussing we could've written so much more
productive code.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Mon May 05 2014 - 17:13:01 CEST