Running 3.4.3 version.
I have a simple JAL script that loops thru
a directory looking for files using the
wildcard *.*

It gets the first file (a directory with the filename
. ) and
handles that properly (notices that its a directory
and skips the file).

On the second file (a directory with the filename
..) it gets the error "Error Getting File Attribute"
on the FileGetAttr command.

What am I doing wrong?

Thanks

I do not think "..." is a valid file name. Thats why the FileGetAttr fails.

If you simply want to find files only why not to use Dir statement?
If you need names of subdirectories only you can use SubDir statement.

: Running 3.4.3 version.
: I have a simple JAL script that loops thru
: a directory looking for files using the
: wildcard *.*

: It gets the first file (a directory with the filename
: . ) and
: handles that properly (notices that its a directory
: and skips the file).

: On the second file (a directory with the filename
: ..) it gets the error "Error Getting File Attribute"
: on the FileGetAttr command.

: What am I doing wrong?

: Thanks

: I do not think "..." is a valid file name. Thats why the
: FileGetAttr fails.

: If you simply want to find files only why not to use Dir statement?
: If you need names of subdirectories only you can use SubDir statement.

Thanks for the quick response.

While its true that "..." is not valid, my original post
listed the filename as "..", I believe, which is valid and
is returned from FileGetNext.

I was using the example code included in your help system
which seems to be the simple way to process a list of files
as opposed to using the technique using DIR.

I pasted the example from the HELP examples into a new job and
changed the wildcard from *.TXT (on the FileGetFirst) to
*.* and was able to reproduce this problem using the
example code.

Other jobs that I have do the exact same thing, but they use
file maskes like *.TXT, *.VIX, *.LST etc .

This is the first that I've tried using *.* so the directory
problem has never come up until now.

I can work around this using DIR if I have to but would
prefer to make this simple approach work, since I have
many other jobs that do this type of thing.

".." and "." are not valid file names, they are used to indicate existance of "parent" and "root" directories. FileGetNext returns them for compatibility with the DOS dir command.

BTW: The DIR statement does exactly the same thing, but it filters out ".." and "."

: Thanks for the quick response.

: While its true that "..." is not valid, my original post
: listed the filename as "..", I believe, which is valid and
: is returned from FileGetNext.

: I was using the example code included in your help system
: which seems to be the simple way to process a list of files
: as opposed to using the technique using DIR.

: I pasted the example from the HELP examples into a new job and
: changed the wildcard from *.TXT (on the FileGetFirst) to
: *.* and was able to reproduce this problem using the
: example code.

: Other jobs that I have do the exact same thing, but they use
: file maskes like *.TXT, *.VIX, *.LST etc .

: This is the first that I've tried using *.* so the directory
: problem has never come up until now.

: I can work around this using DIR if I have to but would
: prefer to make this simple approach work, since I have
: many other jobs that do this type of thing.

: ".." and "." are not valid file names, they are used to
: indicate existance of "parent" and "root" directories.
: FileGetNext returns them for compatibility with the DOS dir command.

: BTW: The DIR statement does exactly the same thing, but it filters out
: ".." and "."

According to the documentation DIR returns a
"comma separated list of files" , not exactly
what I would consider the same thing.

You can still loop through files in the returned list using LoopUntil and GetToken. See DIR example in the on-line help file.

: According to the documentation DIR returns a
: "comma separated list of files" , not exactly
: what I would consider the same thing.