ISFILE with url

Oct 24, 2011
57
1
#1
I'm trying to detect whether a command line option is a filename or a url and the perfect candidate would seem to be the ISFILE conditional, but it doesn't work. The following conditionals return False, as they should:
ISFILE http
ISFILE http:
ISFILE http:/

The following conditional returns True (which is false):
ISFILE http://

The second slash is the deciding factor. ISFILE always thinks the URL is a file.

My purpose is to have a small BTM that will call Firefox with the correct command line, whether I'm trying to read a local HTML file, or go to a web page. I must be doing something wrong, but I'm having a senior moment.
 
Oct 24, 2011
57
1
#3
I'm not sure you understood what I was saying because your reply seem dismissive. I'm not wanting to search for a filename using http. I just expect ISFILE to report that a URL is not a file.

A URL can be given on the Firefox command line without change:

A local file requires a modified syntax:
firefox file:///myfile.htm​

I believe that ISFILE should report that a URL is not a file because it obviously is not a file. In other words, it should return "FALSE" Instead, ISFILE reports that a URL is indeed a file, which it is not.

It seems to me that anything that cannot be confirmed as a file should cause ISFILE to return "FALSE." To me that seems logical.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,556
46
Albuquerque, NM
prospero.unm.edu
#4
But if it started with, say, FTP:// or FTPS://, then it might or might not be a file....

Rather than checking for the existence of the file, might it make more sense to check for an internet protocol? It seems to me that testing %@INDEX[%STRING,://] should suffice in most cases. (But I haven't thought about this much.)
 

rconn

Administrator
Staff member
May 14, 2008
10,434
95
#5
I'm not wanting to search for a filename using http. I just expect ISFILE to report that a URL is not a file.

It seems to me that anything that cannot be confirmed as a file should cause ISFILE to return "FALSE." To me that seems logical.
It works exactly the opposite -- since TCC cannot determine whether an HTTP:// file exists, it always assumes that it does. TCC has always behaved this way, as the general consensus among users was that this would cause less harm than assuming it didn't exist.
 
Oct 24, 2011
57
1
#6
I don't understand why it's better to assume a file exists when it can't be determined. The logic escapes me, but who am I to challenge the general consensus, whatever that is. I've been using 4DOS since upgrading from NDOS and nobody asked me. haha.

In any case, I suppose I can remove the "http://" and then add in back after testing. I was just looking for a simple script for command line convenience and I'm not willing to spend days on it. I have real work to do.
 
Oct 24, 2011
57
1
#8
Well, there ought to be a way to determine whether a file exists at a local location rather than in the cloud somewhere. The ISFILE result in this case is far from intuitive, in my opinion. I don't know what I would take to implement what I want to do in a BTM, so I'm just going to abandon this attempt. Contrary to my initial impression, it turns out to be much easier to accomplish in Rexx.