Here's a thought (no immediate rush to implement, though). Should we expose various *at functions to shell scripting, by adding a new option to specify which fd to pass as the directory argument? This would allow the creation of virtual directory change semantics without the cost of forking a subshell around a cd command. For an envisioned example,
cd /tmp mkdir -p sub { ln --at=4 -sf foo bar # call symlinkat("foo",4,"bar") readlink --at=4 -m bar # call areadlinkat(4,"bar") } 4< sub would output /tmp/sub/foo. It may also make sense to add some shell support in bash for a new redirection operator that opens a directory with O_SEARCH, rather than using < for O_RDONLY, to benefit from the additional POSIX semantics of O_SEARCH on platforms that support that distinction; maybe '><', as in 'exec 4>< dir'. Also, using --at only helps for command line arguments; a new redirection operator that can specify a directory fd for interpreting relative names would also be useful in the shell to make this proposal fully worthwhile; although here I have no ideas for a decent syntax extension beyond POSIX. Also, maybe it should be spelled something longer, like --relative-to-fd, rather than --at? First round of apps to consider this for: anything that modifies file metadata or does low-level operations chcon chgrp chmod chown cp dd du install link ln mkdir mkfifo mknod mv pathchk readlink rm rmdir stat touch truncate unlink Second round of apps: anything that calls open on command line arguments, such as head, tail, cat -- Eric Blake