Boost logo

Boost :

Subject: Re: [boost] [Boost-commit] svn:boost r62919 - in trunk: boost/filesystem/v2 boost/filesystem/v3 libs/filesystem/v2/test libs/filesystem/v3/test
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-06-15 11:09:49

On Mon, Jun 14, 2010 at 10:24 PM, Scott McMurray
<[hidden]> wrote:
> On 14 June 2010 15:10, Beman Dawes <bdawes_at_[hidden]> wrote:
>> Furthermore, I see the need to output and then roundtrip strings back
>> as input, regardless of embedded whitespace, to be a common need
> I think the best kind of << or >> would be ones that prevent "shell
> script injection attacks".  Is there some usable lowest common
> denominator between the escapes used by various shells?
> Platform-specific output and a permissive parser might work too.
> Remembering the Requirement to "Be able to write portable script-style
> filesystem operations in modern C++"
> <>,
> there should be some way to stringstream together something that can
> be safely passed to std::system.
> Imagine something like this:
>    path p = "-f x";
>    stringstream ss;
>    ss << delete_program << " " << p;
>    system(ss.str().c_str());
> It'd be great if it became system("rm './-f x'"); or similar, avoiding
> all kinds of pitfalls in the process.

Using double quotes as delimiters works well for legitimate uses in
both Windows and bash shells, is readable by humans, and avoids the
need for escapes in the vast majority of all real-world path names.

In your example, the call to system would become system("rm \"-f
x\""), and that will be harmless for both Windows and bash shells.

Because of its familiarity as an escape character, I think backslash
makes a good choice as the default escape for delimited strings in
general. But because backslashes appear routinely in Windows paths, I
think filesystem::path should probably use a different escape
character. I'm using ampersand right now, but am not wedded to it and
am not even sure why it popped into my mind. Percent is another


Boost list run by bdawes at, gregod at, cpdaniel at, john at