Re: rfc: exposing *at functions to shell

[Jim Meyering]

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
...