isdir does not work

Hello yesterday i made a scipt that could search for specific filetypes in sub dictories and it was working fine.

   fileList= dir('C:\Users\xxx\xxx')
   fileList= fileList(~[fileList.isdir]); 
   txtFiles = dir(fullfile(fileList, '*.txt'));

But when i restarted i my computer the script didn't work. I have tried debug it and the problem seems to be that

fileList= fileList(~[fileList.isdir]);

wont list any files in the subfolders (it returns nothing). And it's like it just stopped working when on turned on my computer this morning.

[dpb]

Since we can't see the content of the subject directory we can't tell much...the first (via crystal ball) guess is that you're not looking in the same subdirectory you were in yesterday. The script above looks ok on first blush; what is result for fileList?

Answer 1

[Jan]

Don't panik. Matlab does not magically stop to work.

Use the debugger to examine, what's going on:

fileList = dir('C:\Users\xxx\xxx')

What is the contents of fileList? Is it empty? If so, this must be empty also:

   fileList = fileList(~[fileList.isdir])

This "wont list any files in the subfolders"? Of course, because filList does not contain files in subfolders also. Or does "\xxx\" contain a "\**\"?

After this command fileList is still a struct array. Then:

dir(fullfile(fileList, '*.txt'))

fails with an error message: fullfile needs a string or cell string as input, not a struct array.

I guess, that you run another function then you assume. Please set a breakpoint in the code and check, if it is reached at all.

[dpb]

[dpb moved saxocat response to Jan's queries here from Answer]

What do you mean by "\**\" ?

when i run

fileList = dir('C:\Users\xxx\xxx')

It gives me a 12x1 struct array with fields::

'.'  '28-Feb-2017 18:38:57'  0  true  736754.777048611
'..'  '28-Feb-2017 18:38:57'  0  true  736754.777048611
'John'  '28-Feb-2017 18:38:53'  0  true  736754.777002315
'Kim'  '28-Feb-2017 18:38:54'  0  true  736754.777013889
'Jim'  '28-Feb-2017 18:38:54'  0  true  736754.777013889
'Bim'  '28-Feb-2017 18:38:55'  0  true  736754.777025463
'Zim'  '28-Feb-2017 18:38:55'  0  true  736754.777025463
'Tuna'  '28-Feb-2017 18:38:55'  0  true  736754.777025463
'Pie'  '28-Feb-2017 18:41:51'  0  true  736754.779062500
'Lip'  '28-Feb-2017 18:38:56'  0  true  736754.777037037
'Dip'  '28-Feb-2017 18:38:57'  0  true  736754.777048611
'Hip'  '28-Feb-2017 18:38:57'  0  true  736754.777048611

Inside these folders there are 50 text files.

and when i run

fileList = fileList(~[fileList.isdir])

fileList variable is changed to an empty 0x1 struct and there is no error.

[dpb]

"Inside these folders there are 50 text files...and when i run fileList = fileList(~[fileList.isdir]) [result is] an empty structure"

And, that is precisely what it should be. The .txt files are not in the ..\xxx\xxx subdirectory but in one of the subdirectories under it. As the result shows, there are no files resident in this location only the subdirectory names. You'll have to iterate over this resulting list to find the .txt files themselves; dir does not have the /s switch to automagically traverse a directory tree.

There have been a number of threads and at least a couple of tutorials on traversing a directory at Answers; I don't recall who had the really nice demo but a search for the keyword should uncover it...

[Image Analyst]

is a new capability with R2016b where you can have dir() also drill down into all subfolders of what you passed in, instead of just looking at the folder you passed in.

[dpb]

About time... :)

[Jan]

@Image Analyst: I'm not sure if I like the new recursive dir(). For many years I thought about adding my own implementation to the FEX, preferrably as C-Mex. The world was waiting for this. But now... At least I have the chance to publish another progressbar. ;-)

[dpb]

I can't run the release here (no 32-bit version) so can't really try it out to see how it actually works in practice. I'd've thunk mimicking the OS command with a switch to request instead of mucking around with the file search string would've been the way to implement it, though.

I read the doc and didn't see another complaint I've lodged and requested as enhancement that can't see why wasn't implemented from the git-go is the ? wildcard character besides the *.

One can regexp after the fact, but often it's doable for a desired match straight from the search if had the ability to write the equivalent of the OS command. I never could understand why that wasn't just done to begin with.