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 desire
Greg Wooledge wrote:
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"; }
How many different single-ops? over 20? That's 20 factorial
combos. You wanna include that in a script?
On 08/23/2017 07:36 PM, Greg Wooledge wrote:
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
On Wed, Aug 23, 2017 at 07:55:55PM +0700, Peter & Kelly Passchier wrote:
> I was the one proposing combining the UNARY operators in a way like -fx, and
> your -a example shows that there is a precedent. Unary and binary operators
> are different, so there is no confusion for the parser or for the u
On 8/23/17 8:55 AM, Peter & Kelly Passchier wrote:
> Users
> might even expect this to work already.
Nobody expects this to work already; it never has and there's no reason
to think it would.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevi
On Wed, Aug 23, 2017 at 3:55 PM, L A Walsh wrote:
>
>
> Greg Wooledge wrote:
>
>>
>>
>> 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"; }
>>
>>
> How many different single-ops?
On Wed, Aug 23, 2017 at 04:22:09PM +0300, Pierre Gaston wrote:
> testfile () {
> local OPTIND=1 f=${!#}
> while getopts abcdefghLkprsSuwxOGN opt;
> do
> case $opt in
>[abcdefghLkprsSuwxOGN]) test -$opt $f || return 1;;
"$f"
>*)retur
On 8/23/17 9:34 AM, Greg Wooledge wrote:
> On Wed, Aug 23, 2017 at 04:22:09PM +0300, Pierre Gaston wrote:
>> testfile () {
>> local OPTIND=1 f=${!#}
>> while getopts abcdefghLkprsSuwxOGN opt;
>> do
>> case $opt in
>>[abcdefghLkprsSuwxOGN]) test -$opt
On August 23, 2017 3:37:51 PM GMT+02:00, Chet Ramey wrote:
>On 8/23/17 9:34 AM, Greg Wooledge wrote:
>> On Wed, Aug 23, 2017 at 04:22:09PM +0300, Pierre Gaston wrote:
>>> testfile () {
>>> local OPTIND=1 f=${!#}
>>> while getopts abcdefghLkprsSuwxOGN opt;
>>> do
>>>
On 8/23/17 9:51 AM, Dethrophes wrote:
if testfile -fx file;then.
>>>
>>> Add the quotes, make opt local too, and I think we have a winner.
>> This has the advantage of supporting both syntax options: a single
>> option with multiple operators or a series of options, each with one
>> or more o
>
>> Which I always understood as the correct way of doing this in the
>first place...
>
>It's not as good as multiple test commands: test -f file && test -x
>file.
>There's no ambiguity and you get short-circuiting.
Only if you are using the test built-in, otherwise the latter means 2
spawns/f
On 8/23/17 10:24 AM, Dethrophes wrote:
>
>
>>
>>> Which I always understood as the correct way of doing this in the
>> first place...
>>
>> It's not as good as multiple test commands: test -f file && test -x
>> file.
>> There's no ambiguity and you get short-circuiting.
>
> Only if you are using
On Wed, Aug 23, 2017 at 04:24:55PM +0200, Dethrophes wrote:
> >
> >> Which I always understood as the correct way of doing this in the
> >first place...
> >
> >It's not as good as multiple test commands: test -f file && test -x
> >file.
> >There's no ambiguity and you get short-circuiting.
>
> Onl
Well technically I don't *have* to accept the performance penalty.
As I can just use the posix comform syntax, which is quicker.
And just becasue I was curious as to how much quicker it is. Now
admittedly it's not the biggest difference in perf, but I don't see any
real point in using a slower
Am 23.08.2017 um 16:46 schrieb Greg Wooledge:
On Wed, Aug 23, 2017 at 04:24:55PM +0200, Dethrophes wrote:
Which I always understood as the correct way of doing this in the
first place...
It's not as good as multiple test commands: test -f file && test -x
file.
There's no ambiguity and you ge
On 8/23/17 10:49 AM, dethrophes wrote:
> Well technically I don't *have* to accept the performance penalty.
>
> As I can just use the posix comform syntax, which is quicker.
Wait, which posix-conforming syntax? Because your original example, which
had five arguments to `test', is explicitly unspe
Yhea I just learned that now, it's been at least a decade since I looked
at the posix spec on test.
Should probably update the bash help to reflect that
as help bash (in my version at least) only says
EXPR1 -a EXPR2 True if both expr1 AND expr2 are true.
EXPR1 -o EXPR2 True if eith
On 8/23/17 11:13 AM, dethrophes wrote:
> Yhea I just learned that now, it's been at least a decade since I looked at
> the posix spec on test.
>
> Should probably update the bash help to reflect that
>
> as help bash (in my version at least) only says
>
> EXPR1 -a EXPR2 True if both expr1
Ok I inferred incorrectly that bash was also depricating it.
And just because I was curious.
I added the other syntaxes I'm aware of to see how they compared.
looks like [[ -e file && -x file ]], is the quickest.
test_file_1(){
test -f "${1}" -a -x "${1}"
}
test_file_2(){
On 8/23/17 11:54 AM, dethrophes wrote:
> Ok I inferred incorrectly that bash was also depricating it.
Well, it's supported because it's historical syntax, but that doesn't
mean I won't recommend a superior alternative.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Interestingclever, even though not well vetted here, either.
Pierre Gaston wrote:
You can use a loop, here is hack(ish) function that perhaps work (ie
not tested too much):
testfile () {
local OPTIND=1 f=${!#}
while getopts abcdefghLkprsSuwxOGN opt; do
case $opt in
[abcdefghLk
On 08/23/2017 10:17 AM, Chet Ramey wrote:
> On 8/23/17 11:13 AM, dethrophes wrote:
>> Yhea I just learned that now, it's been at least a decade since I looked at
>> the posix spec on test.
>>
>> Should probably update the bash help to reflect that
>>
>> as help bash (in my version at least) only sa
On Wed, Aug 23, 2017 at 3:57 PM, Eric Blake wrote:
>
> Not just deprecated, but inherently ambiguous. There are situations
> where you CANNOT tell whether the user meant -a to mean the binary
> operator or a string being tested against, because POSIX (intentionally)
> does not specify enough pre
23 matches
Mail list logo
