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
