• 11
• 9
• 10
• 9
• 10

# std::string move up one directory

This topic is 541 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi

I've a file path:

std::string filepath

and want to move up one directory. (win/mac/linux) In other words delete until up one directory.

Many thanks

##### Share on other sites

in windows systems(linux too i assume) ..\ can be used to point to the parent directory, but this is the parent of the working directory.

if you mean to go from c:\windows\system to c:\windows, then you will need to parse out tokens with the backslash as a delimiter, and then recombine the tokens into a new string.

##### Share on other sites

Wrote my own string class but should work with standard too. First you need to eaulize the file path because Windows uses '\\' path seperators while Linux and I think Mac too use the other way '/' path seperators. For this when acieving a path from a system API I first do

for(size_t i = 0; i < path.Size(); i++)
if(path[i] == '\\')
path[i] = '/';


to remove any occurance of the one seperator char with the one I prefer. The building a C# like mechanism

path.Substring(0, path.LastIndexOf('/'));


should be done very quickly for trim the string by anything behind the last '/' in it

##### Share on other sites

What I do now is erase also the last two letters (/ or \\) then get the last / or \\. Works as I know the upper directory to contain at least two letters.

InFileCopyFrom.erase (InFileCopyFrom.end()-18, InFileCopyFrom.end());

string::size_type nn = InFileCopyFrom.find_last_of("/\\:");
if (nn == string::npos) XPLMDebugString("The plugin folder is missing.\n");
InFileCopyFrom = InFileCopyFrom.substr(0, nn + 1);

##### Share on other sites

Even without considering the complications of (at least) three different path separators in existence and drive letters being used on Windows (but not so under Unix-alikes)... is it even strictly legal to modify paths in this way? (I'm really wondering! I think it's not.)

Imagine you have the path /a/b/c/.. which is, of course, the same as /a/b. Of course? Really?

Now imagine that c is a symbolic link that points to /d/e/f -- going up one level should, if you are being truthful and correct, place you at /d/e rather than /a/b, and you will not find any such thing as c in that location at all, only f.

What if c is just... c, but instead b is a symbolic link to, say, /g/h/i? Now going up one level should place you in /g/h where (at least) a c and i directories can be found.

##### Share on other sites

is it even strictly legal to modify paths in this way? (I'm really wondering! I think it's not.)

Interesting question.

My take on it is that it is legal to define a set of rules for manipulating paths as a generic concept. However, as you demonstrate, that's not to say anything about how (or if!) that path resolves against any given filesystem.

Here's another example, take a path like this:

/a/b/c/..

I think it's fair to apply a set of rules which which simplify that path to:

/a/b

However when you resolve both paths to a filesystem I think it's also fair if they might result in different things. One example would be your symlinks. Another example would be if /a/b are straightforward directories and c simply doesn't exist on the filesystem at all. Then /a/b will resolve successfully whilst /a/b/c/.. will error with "no such file or directory".

Long story short, to actually arrive at a parent directory for a real file or folder represented by a path you actually have to interrogate a filesystem to do so. Modifying the path as a thing itself is legal to do but won't necessarily resolve to the intended place afterwards.