[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
rfc: exposing *at functions to shell
From: |
Eric Blake |
Subject: |
rfc: exposing *at functions to shell |
Date: |
Wed, 11 Nov 2009 22:13:04 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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
- rfc: exposing *at functions to shell,
Eric Blake <=
Re: rfc: exposing *at functions to shell, Jim Meyering, 2009/11/13