Quoting Andree Leidenfrost <[EMAIL PROTECTED]>:
Hi Steven,
Thanks for your response. It appears to me that I have offended you with
my last message. Should this be the case, I do apologise, this was not
my intention at all.
No, I was not offended. I may have overstated things simply in order
to be clear.
On Sun, 2006-07-30 at 19:34 -0400, Steven M. Robbins wrote:
Quoting Andree Leidenfrost <[EMAIL PROTECTED]>:
> To the contrary, e.g. using a function that submits
> things to 'sh -c' means we have a sane environment like a PATH and so
> forth.
Yeah, well ... that depends on whether you can presume the user does
have a sane PATH variable. I'm inclined to believe the opposite,
actually.
Interesting territory we are entering here me thinks. Why would you be
inclined to say that something as fundamental as the PATH variable can
not be assumed to be sane?
Suppose your non-interactive program relies on, say, "cp" to copy
files and you use system("cp ..."). Well, suppose the user has
PATH=$HOME/bin:$PATH with a shell script $HOME/bin/cp that contains
"/bin/cp -i $@". Your program is no longer non-interactive.
Or a real-life example: SGI's version of "join" behaves differently
than GNU "join". I wrote a script that uses join that worked
perfectly for me because my PATH had /usr/local/gnu/bin *ahead* of
/usr/bin, while others had it the other way around. Lovely debugging
problem, that was :-(
2. Not enough memory is allocated so you're going to overrun the
buffer anytime there is a character to escape. Have a closer look at
the manpage for strspn().
[Note: I find remarks like 'Have a closer look...' unhelpful.]
Sorry; I was in a rush so I took a shortcut.
-Steve
