rfc: exposing *at functions to shell

[Eric Blake]

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