Jump to content
  • Advertisement
Sign in to follow this  
FGFS

std::string move up one directory

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Totaly agree with you but this will always happen in game development even on more robust systems like Unity 3D or strict ones like on an Android device but at the end we need to intend some kind of environment beeing given and cant even fix any occurance that may happen in a file system where a crazy linux pro fixes all its paths by creating mount locations whatever evil stuff could be done so at the end we need to assume a couple of possibilities that we tend to be normal for acting our software with the file system it is running on and if that isnt matching the environment then either we need to change that or the user has to set up our recommendet environment settings then

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!