[Top][All Lists]

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

Re: extension of file-test primitives?

From: Peter & Kelly Passchier
Subject: Re: extension of file-test primitives?
Date: Mon, 21 Aug 2017 07:05:28 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Sorry, indeed I meant: [[ -fx $file ]]
All -ge -ne -eq etc. options are binary operators, while these new ones wpuld be unary, so I think the parsing would be unequivocal.


On 08/21/2017 04:20 AM, L A Walsh wrote:
PePa wrote:
In that case, would not [[ =fx $file ]] be more workable and in line with common GNU short commandline option practice??

Do you mean '-fx' ?  I assume you are meaning as an alternate?
It would be fine with me, even better on an aesthetic sense, however,
Bash already has multi-character ops starting with a dash.

While "-ge $file" could probably be parsed reliably apart from
"$file2 -ge $file", they look similar to a human and might create
more confusion than help.  (-ge $file == exists & groupid set), vs
testing contents of integer vars $file2 and $file for integer-var $file2
being greater-than-or-equal to integer-var $file.

Leveraging the curly brace format, implying [[ -{g,e} $file ]] would be
similar to the quoted example I mentioned.  I.e. -- it would be
a matter of applying brace expansion even though quotes didn't exist.

I.e. instead of:

eval 'test -'{g,e}' /bin/ls && :' && echo executable file

one could remove the eval, quotes and extra '&& :' at the end and

  test -{g,e} /bin/ls && echo executable file

I _think_ people who are familiar w/brace expansion would
easily understand this new form and not confuse it with
existing features.

Does that make sense?

reply via email to

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