dirOf should work with relative paths

[pvgoran]

Cross-posting from NixOS/nixpkgs#42340.

Issue description

nix's built-in function dirOf only works for strings which are absolute paths, for some reason. This looks like a completely arbitrary (and quite unfortunate) restriction, and the documentation doesn't mention it.

The related function baseNameOf does work for all kinds of strings.

Steps to reproduce

nix-instantiate --eval --expr 'dirOf "dir/abc.txt"'                                                        ~
error: string 'dir/abc.txt' doesn't represent an absolute path, at (string):1:1

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.49, NixOS, 18.03.132687.14c248a4ab7 (Impala)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.0.4
• channels(paul): ""
• channels(root): "nixos-18.03.132687.14c248a4ab7"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

[pvgoran]

Posted here as suggested in NixOS/nixpkgs#42340 (comment).

[edolstra]

I disagree. This would introduce an impurity into the evaluator (namely, the current directory), which would cause evaluation to produce a different result depending on the cwd.

[pvgoran]

Why would it need to depend on the current directory?? It should be just a text processing operation which doesn't care about the filesystem or environment.

dirOf "dir/abc.txt" == "dir"
dirOf "abc.txt" == "."
dirOf "../abc.txt" == ".."

[lheckemann]

Some oddities — what would you expect map dirOf ["." ".." "../.."] to result in? There's precedent for ["." "." ".."] in the behaviour of coreutils dirname, but that might not be the least confusing thing to do since it won't always get the parent directory.

[pvgoran]

["." "." ".."] seems to be appropriate.

The goal is not to get a parent directory. The goal is to get a directory name which, when combined with the result of baseNameOf, would be the logical equivalent of the initial path.

[lheckemann]

This seems like sensible behaviour to me. Implemented in #2349.