sl0ppty: expand ~ in a path that a config file wrote

`cwd="~/dev/api"` is in the README, in config/layout.example.kdl, and did
nothing. `~` is a shell thing, and no shell has touched a path that arrives
from a layout file -- so it went to chdir() literally, failed, and left the
pane in whatever directory the session happened to be started from. The pane
still ran, so nothing looked wrong until you typed `ls`.

path_expand() handles `~` and `~/...` against $HOME and returns everything
else untouched, including `~user`, which needs the password database and is
not worth linking it in for -- returned unchanged rather than half-expanded
into something wrong.

Applied where a layout's cwd is read, which is one place because a pane
inherits its tab's. Found while documenting a shader directory that was
about to have exactly the same bug.

1 files changed, 6 insertions, 1 deletions

diff --git a/src/app.c b/src/app.c
index ce95175..be707c7 100644
--- a/src/app.c
+++ b/src/app.c
@@ -1583,7 +1583,12 @@ uint32_t app_current_tab_id(app_t *a) { return a->ntabs ? cur(a)->id : 0; }
  */
 
 static node_t *build_pane(app_t *a, const kdl_node_t *node, const char *cwd) {
-  const char *node_cwd = kdl_prop(node, "cwd", cwd);
+  /* Expanded once here, so both the pane spawned from this node and every
+   * child that inherits the value get the same real directory. The buffer
+   * outlives the recursion below it: children finish before we return. */
+  char cwdbuf[1024];
+  const char *node_cwd =
+      path_expand(kdl_prop(node, "cwd", cwd), cwdbuf, sizeof cwdbuf);
 
   /* a split: children, in order, in one direction */
   size_t kids = 0;