JScript - is a file of a known Type?

[Dr J R Stockton]

In Windows Script Host, given a File Object with properties including
Name and Type, is there a direct guaranteed infallible way in
JScript/VBScript to find whether the file is a known Type?

Examples :

FILENAME TYPE KNOWN

LONGFILENAME.HTML Firefox Document Yes
SEAKFYLE.OK6 OK6 File No
SEAKFYLE.ZIP Compressed (zipped) Folder Yes
SEEK.$$$ $$$ File No
SEEK.BAT MS-DOS Batch File Yes
SEEK.VBS VBScript Script File Yes

For those, it suffices to test, case-dependently, whether the Extension
appears as a word in the Type : if it does not do so, then the file must
be a known Type. But the converse is only reliable if one can be sure
that a known extension cannot ever, in any natural language, occur as a
word in the corresponding Type string.

Consider the possibility of a default browser being called "View Your
HTML", for example - unlikely, but possible. Or that of a file with
extension "File".

The application is SEAKFYLE, via
<http://www.merlyn.demon.co.uk/programs/32-bit/00index.htm>, using
Options X3 and X4. The current code is in a paragraph currently starting
at Line 281 :

if (Eggs == 3 || Eggs == 4) { S = Item.Path
S = S.substring(S.lastIndexOf(".") + 1) // Extn
if (Eggs == 4 ^ new RegExp("\\b"+S+"\\b").test(Item.Type)) return }

Eggs 3 returns for unknown types; Eggs 4 for known ones. In JScript,
the token ^ means "Exclusive-Or".

 

[Mayayana]

I'm not sure I understand. Do you mean you want to
find out if it's a registered file type? That would be
in HKCR. If OK6 is registered there will be a key
HKCR\.ok6


--
--
|
| In Windows Script Host, given a File Object with properties including
| Name and Type, is there a direct guaranteed infallible way in
| JScript/VBScript to find whether the file is a known Type?
|
| Examples :
|
| FILENAME TYPE KNOWN
|
| LONGFILENAME.HTML Firefox Document Yes
| SEAKFYLE.OK6 OK6 File No
| SEAKFYLE.ZIP Compressed (zipped) Folder Yes
| SEEK.$$$ $$$ File No
| SEEK.BAT MS-DOS Batch File Yes
| SEEK.VBS VBScript Script File Yes
|
| For those, it suffices to test, case-dependently, whether the Extension
| appears as a word in the Type : if it does not do so, then the file must
| be a known Type. But the converse is only reliable if one can be sure
| that a known extension cannot ever, in any natural language, occur as a
| word in the corresponding Type string.
|
| Consider the possibility of a default browser being called "View Your
| HTML", for example - unlikely, but possible. Or that of a file with
| extension "File".
|
| The application is SEAKFYLE, via
| <http://www.merlyn.demon.co.uk/programs/32-bit/00index.htm>, using
| Options X3 and X4. The current code is in a paragraph currently starting
| at Line 281 :
|
| if (Eggs == 3 || Eggs == 4) { S = Item.Path
| S = S.substring(S.lastIndexOf(".") + 1) // Extn
| if (Eggs == 4 ^ new RegExp("\\b"+S+"\\b").test(Item.Type)) return }
|
| Eggs 3 returns for unknown types; Eggs 4 for known ones. In JScript,
| the token ^ means "Exclusive-Or".
|
| --
| (c) John Stockton, nr London UK. [email protected] DOS 3.3, 6.20;
WinXP.
| Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and
links.
| PAS EXE TXT ZIP via
<http://www.merlyn.demon.co.uk/programs/00index.htm>
| My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also
batprogs.htm.

 

[Todd Vargo]

I'm not sure I understand. Do you mean you want to
find out if it's a registered file type? That would be
in HKCR. If OK6 is registered there will be a key
HKCR\.ok6

Correct. However getting the string for the file type requires a bit
more effort. Some extensions have their type in the default string.
While others provide the name to another key where the real string must
be read.

For example, on my system the default string for .bmp is Paint.Picture
which you then find there is an Paint.Picture key where you find the
file type is "Bitmap Image".

And some, like .x, store the type in a string named "PerceivedType".

 

[Mayayana]

I'm still not sure I get what Dr J R Stockton is after,
but the Registry system is straightforward.

HKCR\.txt default value: "txtfile"
HKCR\txtfile default value: "Text Document"

PerceivedType is not related to file registration. According
to MS it's actually meant to be used with Windows
Find/Search.
http://msdn.microsoft.com/en-us/library/aa965719(v=vs.85).aspx

Unless someone is building a shell view I don't see the
point of needing the file type's class name. The only need for
that in the first place is so that the way of looking up files
can work despite changes: If Firefox takes over .html from IE,
or IE changes it back, the current status can still be tracked
via HKCR\.html.

The existence of HKCR\.txt confirms that it's a registered type.
The HKCR\[extension key default value] (HKCR\txtfile\) subkeys
then provide other information, like icon, default program for
that file type, etc.

I see what you mean about .x. I wonder how such a key got
written in the first place. It doesn't have any purpose that I
can see. I have very few of those in my Registry. The only
thing I can guess is that some uninstallers remove the default
value for a program's extensions during uninstall but don't
remove the extension key itself.

In any case, it doesn't change the design. "Text" is
not a registered file type. .x is not really registered. So I
guess I should amend what I said above: To be thorough
one should confirm there's a default program for a file type,
under:
HKCR\[extension key default value]\shell\open\command\

That gets back to why anyone cares about the registered
file type name in the first place. Usually the point of looking
up this info. is to find the default program.


--
--
| On 1/3/2012 9:13 PM, Mayayana wrote:
| > I'm not sure I understand. Do you mean you want to
| > find out if it's a registered file type? That would be
| > in HKCR. If OK6 is registered there will be a key
| > HKCR\.ok6
|
| Correct. However getting the string for the file type requires a bit
| more effort. Some extensions have their type in the default string.
| While others provide the name to another key where the real string must
| be read.
|
| For example, on my system the default string for .bmp is Paint.Picture
| which you then find there is an Paint.Picture key where you find the
| file type is "Bitmap Image".
|
| And some, like .x, store the type in a string named "PerceivedType".
|
| --
| Todd Vargo
| (Post questions to group only. Remove "z" to email personal messages)

 

[Dave \Crash\ Dummy]

I'm still not sure I get what Dr J R Stockton is after, but the
Registry system is straightforward.

HKCR\.txt default value: "txtfile" HKCR\txtfile default value: "Text
Document"

PerceivedType is not related to file registration. According to MS
it's actually meant to be used with Windows Find/Search.
http://msdn.microsoft.com/en-us/library/aa965719(v=vs.85).aspx

Unless someone is building a shell view I don't see the point of
needing the file type's class name. The only need for that in the
first place is so that the way of looking up files can work despite
changes: If Firefox takes over .html from IE, or IE changes it back,
the current status can still be tracked via HKCR\.html.

The existence of HKCR\.txt confirms that it's a registered type. The
HKCR\[extension key default value] (HKCR\txtfile\) subkeys then
provide other information, like icon, default program for that file
type, etc.

I see what you mean about .x. I wonder how such a key got written in
the first place. It doesn't have any purpose that I can see. I have
very few of those in my Registry. The only thing I can guess is that
some uninstallers remove the default value for a program's extensions
during uninstall but don't remove the extension key itself.

In any case, it doesn't change the design. "Text" is not a registered
file type. .x is not really registered. So I guess I should amend
what I said above: To be thorough one should confirm there's a
default program for a file type, under: HKCR\[extension key default
value]\shell\open\command\

That gets back to why anyone cares about the registered file type
name in the first place. Usually the point of looking up this info.
is to find the default program.

The trouble with "file type" as stored in the registry and read by
"objFile.type" is that it can be and often is changed by applications. For
example, on my computer the ".bmp" file mentioned above is a "Paint Shop
Pro 5 Image," not a "Paint.Picture."

 

[Mayayana]

|
| The trouble with "file type" as stored in the registry and read by
| "objFile.type" is that it can be and often is changed by applications. For
| example, on my computer the ".bmp" file mentioned above is a "Paint Shop
| Pro 5 Image," not a "Paint.Picture."

Yes, but that's the whole point. That name is only
a pointer to the Registry key that holds the relevant info.
about a registered file, such as the path to the default
program to open it. The file class name itself is not
significant. It's a pointer.

I guess a distinction should be made between the
two "file type" values. I've never used objFile.type
and don't see any point to it, so I'm not sure what
it shows.

I'll call the default value of HKCR\.xxx the file class
name. (I don't know if there's an official term.) I'll call
the default value of HKCR\[FileClassName] the file type
name. So:

HKCR\.txt default value: txtfile
HKCR\txtfile default value: Text Document

Any program that gets assigned as the default for a
file type can set any values it wants. Those values are
really only for Registry navigation and advertising. (Since
most software is commercial one often gets commercial
names.) For .bmp I have a file class name of "IrfanView.BMP"
and a file type name of "IrfanView BMP File". Neither of
those names tells me anything about what a BMP file is.
If I wanted a script to provide useful information about
file types, perhaps in an HTA, I think I'd write a function
to return strings like "text file", "cascading style sheet file",
"webpage file", etc. There simply isn't any standard like
that in Windows.

 

[Todd Vargo]

|
| The trouble with "file type" as stored in the registry and read by
| "objFile.type" is that it can be and often is changed by applications. For
| example, on my computer the ".bmp" file mentioned above is a "Paint Shop
| Pro 5 Image," not a "Paint.Picture."

Yes, but that's the whole point. That name is only
a pointer to the Registry key that holds the relevant info.
about a registered file, such as the path to the default
program to open it. The file class name itself is not
significant. It's a pointer.

I guess a distinction should be made between the
two "file type" values. I've never used objFile.type
and don't see any point to it, so I'm not sure what
it shows.

I'll call the default value of HKCR\.xxx the file class
name. (I don't know if there's an official term.) I'll call
the default value of HKCR\[FileClassName] the file type
name. So:

HKCR\.txt default value: txtfile
HKCR\txtfile default value: Text Document

Any program that gets assigned as the default for a
file type can set any values it wants. Those values are
really only for Registry navigation and advertising. (Since
most software is commercial one often gets commercial
names.) For .bmp I have a file class name of "IrfanView.BMP"
and a file type name of "IrfanView BMP File". Neither of
those names tells me anything about what a BMP file is.
If I wanted a script to provide useful information about
file types, perhaps in an HTA, I think I'd write a function
to return strings like "text file", "cascading style sheet file",
"webpage file", etc. There simply isn't any standard like
that in Windows.

I know what you mean. It drives me nuts when installers hijack
registered file associations without warning. It has gotten better over
the years with installers offering the option to select or exclude
taking over existing extensions. I have added many custom keys over the
years to select from several apps with special parameters for particular
extensions. So when these misbehaved installers hijack one of these on
me, you know I'm not a happy camper.

 

[Dr J R Stockton]

The trouble with "file type" as stored in the registry and read by
"objFile.type" is that it can be and often is changed by applications. For
example, on my computer the ".bmp" file mentioned above is a "Paint
Shop
Pro 5 Image," not a "Paint.Picture."

The fact that the Type string can be changed provides a good reason for
having a convenient way to read the Type string.

Typically, MS make it harder to tell by code whether a file's Type is
known or not by putting an uninformative but readable string where they
could more easily have put an empty string or a recognisable language-
independent one such as "-".

No-one has actually answered the question.



Let's try another.

The CScript in question is started from the DOS-box command-line and
writes lines to the screen - it would run perfectly well on an ASR33
teletype. At present, if started in WScript, it exits leaving a small
note.

It would be nice to allow execution by WScript, with GUI output; but, to
be worth doing, it would be necessary for there to be an easy way of
creating and writing (line by line) to something resembling an HTML
textarea. Is that available, and if so how is it done or where do I
need to look?

 

[Michael Haufe (TNO)]

In Windows Script Host, given a File Object with properties including
Name and Type, is there a direct guaranteed infallible way in
JScript/VBScript to find whether the file is a known Type?

Generally not as there is not a bijection between the TYPE and its
registry entry. One would have to use the file extension as a key to
lookup the existence of an entry to get more accurate results.

Examples :

FILENAME TYPE KNOWN

LONGFILENAME.HTML Firefox Document Yes
SEAKFYLE.OK6 OK6 File No
SEAKFYLE.ZIP Compressed (zipped) Folder Yes
SEEK.$$$ $$$ File No
SEEK.BAT MS-DOS Batch File Yes
SEEK.VBS VBScript Script File Yes

Here is some code that creates a similar result on my machine:

<https://gist.github.com/1569247>

 

[Michael Haufe (TNO)]

The CScript in question is started from the DOS-box command-line and
writes lines to the screen - it would run perfectly well on an ASR33
teletype.  At present, if started in WScript, it exits leaving a small
note.

It would be nice to allow execution by WScript, with GUI output; but, to
be worth doing, it would be necessary for there to be an easy way of
creating and writing (line by line) to something resembling an HTML
textarea.  Is that available, and if so how is it done or where do I
need to look?

Are you looking for a formatted table output in the command window in
a way similar to your original example?

 

[Bwig Zomberi]

Are you looking for the /nologo parameter to cscript?

 

[Bwig Zomberi]

Typically, MS make it harder to tell by code whether a file's Type is
known or not by putting an uninformative but readable string where they
could more easily have put an empty string or a recognisable language-
independent one such as "-".

When Windows and programs are installed files types are created. Some
applications hijacks extensions. They keep it meaningful or give it all
a same name. The logic is still the same - what Mayayana has stated. If
it is in the registry, it is a known file type. Otherwise, it is
unknown.

 

[Todd Vargo]

The fact that the Type string can be changed provides a good reason for
having a convenient way to read the Type string.

Typically, MS make it harder to tell by code whether a file's Type is
known or not by putting an uninformative but readable string where they
could more easily have put an empty string or a recognisable language-
independent one such as "-".

No-one has actually answered the question.

Your question was malformed. It did not request to provide code to
demonstrate a different method from the one you previously chose. As
indicated, your answer can be found in HKCR but effort on your part is
necessary to capture it.

Let's try another.

The CScript in question is started from the DOS-box command-line and
writes lines to the screen - it would run perfectly well on an ASR33
teletype. At present, if started in WScript, it exits leaving a small
note.

It would be nice to allow execution by WScript, with GUI output; but, to
be worth doing, it would be necessary for there to be an easy way of
creating and writing (line by line) to something resembling an HTML
textarea. Is that available, and if so how is it done or where do I
need to look?

Not even going to attempt to research it on your own?
Watch for the line wraps...

'''''' Creates an Internet Explorer instance to display VBScript output
''''''
'On Error Resume Next

Set WshShell = WScript.CreateObject("WScript.Shell")
Set objExplorer = Wscript.CreateObject("InternetExplorer.Application",
"IE_")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = False
objExplorer.StatusBar = False
objExplorer.Top = 180
objExplorer.Left = 200
objExplorer.Width = 630
objExplorer.Height = 320
objExplorer.Visible = True
objExplorer.Resizable = False

Do While (objExplorer.Busy) 'Wait for Iexplore instance to load
Wscript.Sleep 250
Loop

With objExplorer.Document
.Writeln "<html><head><title></title></head><body>"
.Title = Wscript.ScriptName & " is running... "

.body.style.cursor = "Wait"
.Writeln "<img
src=""http://www.merlyn.demon.co.uk/graphics/merlyn-1.gif"">"
.Writeln "<p class=""style2""><B>Please wait while APPLICATION is
loading...</B></p>"

For x = 1 to 25
.Writeln "Line..." & x & "<br>"
WScript.Sleep(50) 'Pause 50 miliseconds
.body.createtextrange.scrollIntoView False 'Scroll to bottom of page
Next

.Writeln "<p>Ok - Bye.</p><br>"
.body.createtextrange.scrollIntoView False 'Scroll to bottom of page
.body.style.cursor = "" 'Return cursor to normal
.Title = Wscript.ScriptName & " is Done! "
End With

WScript.Sleep(5000) 'Pause 5 seconds
objExplorer.Quit 'Close the status window
Set objExplorer = Nothing
Wscript.Quit


Sub IE_onQuit() 'This subroutine will fire when Iexplore is closed
'Script will continue to run after IE window closes.
MsgBox "User closed window!"
End Sub

 

[John G Harris]

Generally not as there is not a bijection between the TYPE and its
registry entry. One would have to use the file extension as a key to
lookup the existence of an entry to get more accurate results.

<snip>

Beware of believing file extensions. Up to Win ME at least, I haven't
checked XP, a .txt file's content is inspected by Windows. If it looks
like a PIF file then the file will be executed when you thought it would
be displayed by Notepad.

John

 

[Michael Haufe (TNO)]

  <snip>

Beware of believing file extensions. Up to Win ME at least, I haven't
checked XP, a .txt file's content is inspected by Windows. If it looks
like a PIF file then the file will be executed when you thought it would
be displayed by Notepad.

Whether it is an _expected_ result or not is a separate issue to
whether it is KNOWN/Recognized by the OS.

 

[Mayayana]

| Your question was malformed.

Indeed. Neither of his questions seems coherent to
me. He never explained what he was trying to do.
And he's been around long enough, in any case, to
answer both of his questions himself. ...Odd.

 

[John G Harris]

Whether it is an _expected_ result or not is a separate issue to
whether it is KNOWN/Recognized by the OS.

But if you "use the file extension as a key to lookup the existence of
an entry to get more accurate results" then you will get *less* accurate
results in this case. That's the point. Not getting the action you
expected is merely the evidence.

John

 

[Michael Haufe (TNO)]

But if you "use the file extension as a key to lookup the existence of
an entry to get more accurate results" then you will get *less* accurate
results in this case. That's the point. Not getting the action you
expected is merely the evidence.

Since the original question, AFAICT, was to determine whether the OS
recognizes a given file, moving from a human interpretation of the
file's description to an existence check in the registry is most
definitely going to be more accurate. If I have a predicate: isKnown,
and isKnown("*.dat") is true, it doesn't matter at this level of
abstraction what application that extension is mapped to, only whether
it has a mapping at all.

 

[Dr J R Stockton]

| Your question was malformed.

Indeed. Neither of his questions seems coherent to
me. He never explained what he was trying to do.
And he's been around long enough, in any case, to
answer both of his questions himself. ...Odd.

You should not confuse knowing a lot that others do not with knowing
everything that others do know.

 

[Dr J R Stockton]

In comp.lang.javascript message <847ebf0b-4938-4a1e-a108-964535d3d853@z1
2g2000yqm.googlegroups.com>, Thu, 5 Jan 2012 22:05:53, "Michael Haufe

Are you looking for a formatted table output in the command window in
a way similar to your original example?

Yes.

The original article in the thread was concerned with one particular
point. That example was partly from what I already have, with the third
column by hand. It will be to produce something similar but with other
information.

But the core of the situation is that all CScript output is through

function Right(N, Str) { N = Hush[N]
if (N == "0") return
if (N == "1") WScript.StdOut.Write(Str)
if (N == "2") WScript.StdErr.Write(Str)
if (N == "3") txtStreamOut.Write(Str)
}

in which almost all Str end with a newline; and I want to use

if (N == "4") SOMETHING(Str)

[ after having detected (which I can do) WScript ] to get a
corresponding display.

If that can be done, the application is no longer just a CScript
application usable only by those who can find and use a DOS-like command
line, but it is usable also by those who only use GUI routines.


Another approach would be to use the same code in an HTA, which I would
have to learn about.