Re: rfc: exposing *at functions to shell
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
...
Re: rfc: exposing *at functions to shell
On Wednesday 11 November 2009 17:13:04 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.
isnt this possible today under linux by using /proc/self/fd ? i'm not
suggesting this as a clean/portable replacement, just trying to better
understand the proposal.
--at-fd might be a better explicit option without getting too verbose ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: rfc: exposing *at functions to shell
Eric Blake e...@byu.net writes: Mike Frysinger vapier at gentoo.org writes: --at-fd might be a better explicit option without getting too verbose ? Indeed. Note that the at in those functions is actually short for attribute. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: rfc: exposing *at functions to shell
Mike Frysinger vapier at gentoo.org writes:
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.
isnt this possible today under linux by using /proc/self/fd ? i'm not
suggesting this as a clean/portable replacement, just trying to better
understand the proposal.
Yes, with sufficient /proc supprt, the above example would be equivalent to:
cd /tmp
mkdir -p sub
{
ln -sf foo /proc/self/4/bar
readlink -m /proc/self/4/bar
} 4 sub
Without /proc, it's similar to doing everything via absolute or anchored paths
(or using shell variables for shorthand), but then you lose time with O(n^2) on
deep nesting of directories, as well as the robustness that the *at functions
give in the case that some other process is modifying the same hierarchy that
you are operating on:
cd /tmp
mkdir -p sub
dir=sub
{
ln -sf foo $dir/bar
readlink -m $dir/bar
} 4 $dir
--at-fd might be a better explicit option without getting too verbose ?
Indeed.
--
Eric Blake
