Re: rfc: exposing *at functions to shell

2009-11-11 Thread Mike Frysinger
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

Re: rfc: exposing *at functions to shell

2009-11-11 Thread Andreas Schwab
Eric Blake writes: > Mike Frysinger 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 = 58

Re: rfc: exposing *at functions to shell

2009-11-11 Thread Eric Blake
Mike Frysinger 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/s

Re: rfc: exposing *at functions to shell

2009-11-11 Thread Mike Frysinger
On Wednesday 11 November 2009 18:13:41 Andreas Schwab wrote: > Eric Blake writes: > > Mike Frysinger 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". i wasnt aware of

Re: rfc: exposing *at functions to shell

2009-11-11 Thread Andreas Schwab
Mike Frysinger writes: > On Wednesday 11 November 2009 18:13:41 Andreas Schwab wrote: >> Eric Blake writes: >> > Mike Frysinger writes: >> >> --at-fd might be a better explicit option without getting too verbose ? >> > >> > Indeed. >> >> Note that the "at" in those functions is actually short f

Re: rfc: exposing *at functions to shell

2009-11-13 Thread 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