Eric Blake wrote: > 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?
Interesting idea, at least in theory. Another possibility: --dir-fd On one hand, this is tantalizing. On the other, it seems almost self-contradictory. The idea of a shell script that aspires to be robust enough at hierarchy manipulation that it needs tools supporting this new option is almost oxymoronic. It seems like getting openat support into a language like Perl or Ruby would be more worthwhile. If there were more multithreaded shell scripts, where being able to write dir-traversing-without-changing-CWD code would be valuable, it'd be easier to justify... > 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 ...