bug#6986: [PATCH] test: add check to determine whether files are on the same device

[Dieter Plaetinck]

On Mon, 06 Sep 2010 20:24:16 +0200
Jim Meyering <address@hidden> wrote:

> Dieter Plaetinck wrote:
> > In the test program, there is '-ef' which checks whether files
> > are on the same device *and* have the same inode number.
> > This change introduces '-ed' which is basically the same, minus the
> > inode number checking
> > ---
> >  src/test.c |   19 +++++++++++++++----
> >  1 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/test.c b/src/test.c
> 
> Thank you for the patch.
> However, can you make a case for adding this to test
> rather than using an existing tool like stat?
> 
> For example, here's a tiny shell function:
> 
>     same_dev()
>     {
>       local d1=$(stat --format=%d "$1") || return 1
>       local d2=$(stat --format=%d "$2") || return 1
>       test "$d1" = "$d2"
>     }
> 
> You could use it like this:
> 
>     $ same_dev a b && echo same
>     same
>     $ same_dev a / && echo same || echo different devices
>     different devices
> 
> That it's so easy to accomplish the same thing with
> existing tools makes it hard to justify adding the feature.
> 
> Besides, if you're really interested in getting this feature
> into "test", you don't want to start with coreutils.
> Its "test" program is used only rarely, since "test"
> is always a shell built-in, these days.
> Thus you'd want to request that your feature be added
> to at least bash and zsh.


Hey Jim,
at first I considered writing a shell function like the one you suggest.
But putting it in test seemed like a better, more generally useful
place, especially since there are some similar functions in test.
(like -ef), and it's just a few lines of C code.
I would argue some of the existing functionality in test can as
easily be removed in favor of a shell function.  (I don't suggest
doing so)

Ie, for test -O :
owned_by_me ()
{
  local owner_id=$(stat --format='%u' "$1") || return 1
  test $owner_id -eq $EUID
}

I know some shells provide the 'test' features as a built-in,
that's fine.  But they should mimic the features test has.
It makes the shell implementation dependent on test, not the
other way around.  If this feature is considered useful for test, and
gets merged into test, shells will follow soon enough.

But anyway, your call :)
At least thanks for the timely feedback and have a nice day.

Dieter