Discussing the full implications of these tests could probably keep a
philosophy class busy for an afternnon. It might even rise to an
LPU[1] paper.

-e is fairly easy. It asks if something exists. Ignoring Schrodinger,
either it does (i.e True) or it doesn't. (False)
-f is more ambiguous. It asks if something has a property (fileness)
or not. If it exists, it either does or doesn't.
If it doesn't exist, it certainly can't possess the required property,
but can it be said "not" to possess that property? Anybody know any
convenient Buddhists?

Summarised:   Exists  Has Desired Property Response
                      Yes       Yes                         True
                      Yes       No                           False
                       No        N/A?                       ??

Bash appears to err on the pragmatic side, returning "fail" for both
-e and -f on a non-existent
file. After all, we usually only want to proceed if the thing exists
&& is what we want. It would probably be least confusing to default to
the same behaviour, but perhaps returning different kinds of "False"?

[1] Least Publishable Unit

On 9/29/17, Timo Paulssen <t...@wakelift.de> wrote:
>> This sounds broken, actually; I understand that a Failure treated as > a
>> Bool prevented it from throwing, so it should have simply returned
>> False. > > Checking it for .defined *does* prevent throwing. Still
> seems like a > bug.
> It doesn't get "treated as a Bool"; any Failure makes it through a
> return typecheck as if it were the right type, that's why you can "fail"
> in a method that has its return type set to be "Int", even though
> Failure doesn't derive from Int. So we don't have to go around giving
> every single method a return type like "Any where { Failure | Int }".
>
> I see .f as "is it a file". "Is /blahblah a file? Oops! I can't check
> that, because /blahblah doesn't exist". It's a different use case from
> "does it exist". You'd likely want to have something more like
>
>     my $file = "/home/linuxutil/erasxeme.txt".IO; say $file.e &&
> $file.f.Bool;
>
> i.e. first check if it exists, then check if it's actually a file.
> Though something could have deleted the file between checking if it
> exists and whether it's a file or not, that's why i'm putting a .Bool
> after the .f check, too.
>
> hope that makes sense
>   - Timo
>

Reply via email to