I agree this is a useful addition. I think people usually do some super unsafe drop stuff which is very unpleasant.

I note the name stripPrefix clashes with List, and nothing else in this module does, so we need a different name.

I also note the closely related operation of take/drop directories from the front of a path. I wonder if they should be added at the same time? Or even if they replace this as a general case of it? In Shake I have takeDirectory1 (terrible name) for that purpose.

I agree that it makes sense not to clash with Data.List.

I dont think that taking and dropping directories form the front of a path are a generalization of this. And even if they are, a well-named, well-documented function would make it easier to discover the functionality and understand it.

Name suggestions, mainly for brainstorming:

• stripCommonPrefix
• stripPathPrefix
• takeRelative
• stripAncestor
• removeAncestor

I'd appreciate this function. 👍

I just tried to implement a function that checks whether a file is inside a directory or inside its subdirectories using this flawed approach:

isInside :: FilePath -> FilePath -> Bool
isInside dir file =
  let dir'   = show dir
      file'  = show file
  in Data.List.isPrefixOf dir' file'

This returns false, also for files that were indeed inside the directory.

After a bit of head scratching I realized that show puts quotes around the file paths. This meant checking if "/home/me/dir" is the prefix of "/home/me/dir/file" which it is not because of the trailing ".

@mb720 I would have thought Data.List.isPrefixOf (addTrailingPathSeparator dir) file would do what you are after more easily than the hypothetical stripPrefix.

Thanks @ndmitchell! I forgot that FilePath is a type alias for String. Your suggestion makes for a simple solution.

So I think what we want is:

splitDirectoryStart :: FilePath -> (FilePath, FilePath)

Which turns foo/bar/baz into (foo, bar/baz). Then everything else, probably a take, drop, and strip are built off that. Does that make sense? Not a massive fan of the names, but split/take/drop/strip seems to be consistent with what else is in the filepath library.

I think, this is a reasonable primitive.
To be clear, the function proposed in this issue would still be added to the library?

For other additions to the library, there are the split/drop/take functions all in the library - I see no reason to not do that here too. The main question I have open is coming up with a name that is clear.

In #77 I offered to change maintainership of this library. Given this decision is the big one outstanding, I'll wait for a resolution on that matter before figuring out this patch. (And sorry for the delay, I've got weighed down with lots of other stuff)

A dual to stripExtension to strip a few segments from the start of the path would be helpful indeed. A low-level stripPrefix from os-string isn't quite there, because it will strip segments even in the middle of a folder name.

There are some rather peculiar edge cases on windows:

stripPrefix "C:foo" "C:foo/bar"

This is a relative path that has a drive letter and means "relative to the current directory on drive C".

Semantically it should probably produce "C:bar".

Similarly stripPrefix "/foo" "/foo/bar" should produce "/bar", since the leading slash means "apply the drive from the current directory".

UNC paths are difficult. Stripping can produce an "invalid path". But that problem already exists in other functions to some degree.

The question is what properties do we really expect. If it's "the entire prefix should be gone from the output", then that won't hold on windows.