[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: extension of file-test primitives?

From: Greg Wooledge
Subject: Re: extension of file-test primitives?
Date: Wed, 23 Aug 2017 08:36:17 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Aug 22, 2017 at 09:25:44PM -0700, L A Walsh wrote:
> Chet Ramey wrote:
> > On 8/21/17 9:27 AM, Greg Wooledge wrote:
> > > You could write your own helper functions for this:
> > > 
> > > -fx() { test -f "$1" && test -x "$1"; }
> > 
> > This is indeed a quick and easy way to implement desired functionality.
> > Shell functions can do a lot.
> ----
>    Alas, they don't work inside [[...]] with other
> file-test operators:
> [[ -fx /bin/ls && -s /bin/ls ]] && echo ok

They're not intended to work that way.  If you want to test f+x+s then
you just make another function:

-fxs() { test -f "$1" && test -x "$1" && test -s "$1"; }

if -fxs /bin/ls; then ...

You could also take the original function and combine it with a test

if -fx /bin/ls && test -s /bin/ls; then ...

Or, since you seem to be infatuated with the [[ command:

if -fx /bin/ls && [[ -s /bin/ls ]]; then ...

All of your syntactic proposals have problems.  First, curly braces.
These already have their own semantics, and what you are proposing
does not work with those semantics.  You proposed:

[[ -{f,x} $file ]]

With standard curly brace semantics (ignoring [['s stupid magic
parser-bending rules for the moment) this expands to:

[[ -f -x $file ]]

If we use single brackets and set -x we can even witness the shell
expanding it thus.

wooledg:~$ [ -{f,x} file ]
+ '[' -f -x file ']'
bash: [: -x: binary operator expected

Second, you proposed test -fx.  But this collides with existing
multi-character test options.  Specifically, test has the options -e,
-f, and -ef.  So your proposal of letter-concatenation would take
the -e and -f options and squash them together into -ef, which would
collide with the "two files are hard links to the same inode" option.

Likewise, the unary options -n and -t would combine into -nt which
collides with the binary "mtime is newer than" option.

Sure, you might argue that there is no reason to combine -e and -f
together, since one implies the other; or that no sane person would
ever combine -n and -t together; but that's not the point.  The point
is to avoid reader confusion.  It's already bad enough that the -a
option is overloaded and has two completely different meanings.  Let's
not compound that mistake.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]