Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Matlab 2010a dir cmd

Subject: Matlab 2010a dir cmd

From: Derik

Date: 12 May, 2010 21:42:04

Message: 1 of 25

I found this to be kind of interesting. I was trying to find all the subdirectories in my current directory when I used dir *.
In my 2009a and previous version of matlab it always returned just the directories. Now it is returning everything.
I tried a dos('dir *.') and that worked as expected, but I can't use the output. Anyone know if this is a bug in 2010a, or am I doing something incorrectly.

Thanks!

Subject: Matlab 2010a dir cmd

From: us

Date: 12 May, 2010 22:33:07

Message: 2 of 25

"Derik " <derik.alles+matlab@gmail.com> wrote in message <hsf7bc$f7m$1@fred.mathworks.com>...
> I found this to be kind of interesting. I was trying to find all the subdirectories in my current directory when I used dir *.
> In my 2009a and previous version of matlab it always returned just the directories. Now it is returning everything.
> I tried a dos('dir *.') and that worked as expected, but I can't use the output. Anyone know if this is a bug in 2010a, or am I doing something incorrectly.
>
> Thanks!

well, no...
THIS is the classic DIR behaviour...
most likely you had some proprietary DIR in your older versions, which filtered non-folder stuff out...

us

Subject: Matlab 2010a dir cmd

From: Walter Roberson

Date: 12 May, 2010 22:57:53

Message: 3 of 25

us wrote:
> "Derik " <derik.alles+matlab@gmail.com> wrote in message
> <hsf7bc$f7m$1@fred.mathworks.com>...
>> I found this to be kind of interesting. I was trying to find all the
>> subdirectories in my current directory when I used dir *.
>> In my 2009a and previous version of matlab it always returned just the
>> directories. Now it is returning everything.
>> I tried a dos('dir *.') and that worked as expected, but I can't use
>> the output. Anyone know if this is a bug in 2010a, or am I doing
>> something incorrectly.

> well, no...
> THIS is the classic DIR behaviour...
> most likely you had some proprietary DIR in your older versions, which
> filtered non-folder stuff out...

To cross-check: Derik was including a period in the name. Is it classic
DIR behaviour to discard that trailing period? It wouldn't be the
behavior I would expect on Unix systems, where the trailing period would
be treated as a literal, and only names ending in period would be returned.

Subject: Matlab 2010a dir cmd

From: Derik

Date: 12 May, 2010 23:06:03

Message: 4 of 25

Walter Roberson <roberson@hushmail.com> wrote in message <RnGGn.6843$wV2.3222@newsfe23.iad>...
> us wrote:
> > "Derik " <derik.alles+matlab@gmail.com> wrote in message
> > <hsf7bc$f7m$1@fred.mathworks.com>...
> >> I found this to be kind of interesting. I was trying to find all the
> >> subdirectories in my current directory when I used dir *.
> >> In my 2009a and previous version of matlab it always returned just the
> >> directories. Now it is returning everything.
> >> I tried a dos('dir *.') and that worked as expected, but I can't use
> >> the output. Anyone know if this is a bug in 2010a, or am I doing
> >> something incorrectly.
>
> > well, no...
> > THIS is the classic DIR behaviour...
> > most likely you had some proprietary DIR in your older versions, which
> > filtered non-folder stuff out...
>
> To cross-check: Derik was including a period in the name. Is it classic
> DIR behaviour to discard that trailing period? It wouldn't be the
> behavior I would expect on Unix systems, where the trailing period would
> be treated as a literal, and only names ending in period would be returned.


From what I understand doing a dir *. should return everything that has no extension (the reason why I'm getting the folders) It works the way I expected using the DOS command. I didn't have any proprietary DIR in my previous versions of matlab, and it doesn't explain why it is working with the DOS('dir *.')

Thanks for the quick replies, can anyone else see if it is working the same way if they have 2010a installed as well. (I can only check 2008a and 2009a and they both behave the was I am expecting.)

Subject: Matlab 2010a dir cmd

From: James

Date: 12 May, 2010 23:15:24

Message: 5 of 25

Yes, you received two quick replies from two people who obviously had no idea what they were talking about... or did not attempt to verify your problem before writing to this thread.

I recently installed Matlab 2010 and have run into this issue as well. Very frustrating... many legacy scripts no longer work properly as a result of this flaw. I, too, would be very interested to hear if there is a workaround of any sort available...

- James

Subject: Matlab 2010a dir cmd

From: us

Date: 13 May, 2010 00:22:06

Message: 6 of 25

"James " <james.downs@ngc.com> wrote in message <hsfcqc$688$1@fred.mathworks.com>...
> Yes, you received two quick replies from two people who obviously had no idea what they were talking about... or did not attempt to verify your problem before writing to this thread.
>
> I recently installed Matlab 2010 and have run into this issue as well. Very frustrating... many legacy scripts no longer work properly as a result of this flaw. I, too, would be very interested to hear if there is a workaround of any sort available...
>
> - James

no, you are simply wrong
if you have a folder named foo.goo
     dir *.
does NOT show it in the listing

HENCE, the assumption that this syntax returns subfolders is flawed and should never have been used on first place (legacy is always a bad excuse for not coding properly, in particular if it comes to system related issues such as folder listings) - and has never been used by most of us (on first place)...

the proper way to look for folder has ALWAYS been to check the .directory flag

d=dir;
fn={d([d.isdir]).name}.'
% now foo.goo shows up...
%{
fn =
    '#SSC'
    '.' % <- note...
    '..'
    'arch'
    'fig'
    'foo.foo'
%}

my impression is that some know pretty well what they are talking about
us

Subject: Matlab 2010a dir cmd

From: Walter Roberson

Date: 13 May, 2010 00:35:29

Message: 7 of 25

James wrote:
> Yes, you received two quick replies from two people who obviously had no
> idea what they were talking about...

~ 500> matlab7_ng -nodisplay -nojvm

                             < M A T L A B (R) >
                   Copyright 1984-2008 The MathWorks, Inc.
                          Version 7.7.0.471 (R2008b)
                              September 17, 2008

Warning: X does not support locale en_CA.UTF-8

   To get started, type one of these: helpwin, helpdesk, or demo.
   For product information, visit www.mathworks.com.

 >> dir('*.')

. ..

 >> !touch foobar.
 >> dir('*.')

. .. foobar.


Does that disagree in any way with my statement that,

"It wouldn't be the behavior I would expect on Unix systems, where the
trailing period would be treated as a literal, and only names ending in
period would be returned."

Or did I "not know what" I was "talking about" when I stated that "Derik
was including a period in the name." ? And was the remainder of my
article not in the form of a question?

 > or did not attempt to verify your
 > problem before writing to this thread.

If you provide a Windows PC and Matlab license valid for the appropriate
releases, then I would be happy to test the boundaries of the Windows
behaviour.

> I recently installed Matlab 2010 and have run into this issue as well.
> Very frustrating... many legacy scripts no longer work properly as a
> result of this flaw. I, too, would be very interested to hear if there
> is a workaround of any sort available...

I do not see the referenced dir behaviour documented by Mathworks. What
Mathworks does say,
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/dir.html
is that,

"DOS File Names

The MATLAB dir function is consistent with the Microsoft Windows
operating system dir command in that both support short file names
generated by DOS."

In DOS, the file names for a directory include a .DIR extension, and the
names at the Windows level are shown with the .DIR extension striped
off, including the trailing period. There is thus no documented reason
to expect that a trailing period is a short cut for indicating
directories to the dir() command.

I am not doubting that it "happened to work" in the past, but if it did
then it relied upon undocumented Matlab behaviour.

Is the use of trailing period correct for Windows? Microsoft says not:
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx

 >>> Do not end a file or directory name with a space or a period.
 >>> Although the underlying file system may support such names, the
 >>> Windows shell and user interface does not. However, it is acceptable
 >>> to specify a period as the first character of a name. For example,
 >>> ".temp"


I would not say that there is a workaround -- but there is obvious
coding that is portable, operating-system independent, and fully
documented, and thus is _correct_ coding for the situation:

names = dir('*');
names = names([names.isdir]);

Subject: Matlab 2010a dir cmd

From: dpb

Date: 13 May, 2010 00:39:34

Message: 8 of 25

Derik wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message
> <RnGGn.6843$wV2.3222@newsfe23.iad>...
>> us wrote:
>> > "Derik " <derik.alles+matlab@gmail.com> wrote in message >
>> <hsf7bc$f7m$1@fred.mathworks.com>...
>> >> I found this to be kind of interesting. I was trying to find all
>> the >> subdirectories in my current directory when I used dir *.
>> >> In my 2009a and previous version of matlab it always returned just
>> the >> directories. Now it is returning everything.
>> >> I tried a dos('dir *.') and that worked as expected, but I can't
>> use >> the output. Anyone know if this is a bug in 2010a, or am I
>> doing >> something incorrectly.
>>
>> > well, no...
>> > THIS is the classic DIR behaviour...
>> > most likely you had some proprietary DIR in your older versions,
>> which > filtered non-folder stuff out...
>>
>> To cross-check: Derik was including a period in the name. Is it
>> classic DIR behaviour to discard that trailing period? It wouldn't be
>> the behavior I would expect on Unix systems, where the trailing period
>> would be treated as a literal, and only names ending in period would
>> be returned.
>
>
> From what I understand doing a dir *. should return everything that has
> no extension (the reason why I'm getting the folders) It works the way I
> expected using the DOS command. I didn't have any proprietary DIR in my
> previous versions of matlab, and it doesn't explain why it is working
> with the DOS('dir *.')
>
> Thanks for the quick replies, can anyone else see if it is working the
> same way if they have 2010a installed as well. (I can only check 2008a
> and 2009a and they both behave the was I am expecting.)

As us says, the reliable way to find only directories is to either check
the directory attribute or use the the /A: attributes switch to tell the
DIR command to only return files w/ the D attribute. Assuming that
directories (and only directories) do not have extensions is a bad
assumption in general.

OTOH, it sounds as though the behavior of ML has indeed changed and
perhaps the default now is for it to transparently use the /A:-D switch
internally to return only files instead of all files including those w/
directory attribute.

I'd presume that the optional return values of the dos() command could
still be used but again as us says, it would be cleaner to use the
attribute of the dir() command to find directories w/o the assumption on
the form of their name(s).

--

Subject: Matlab 2010a dir cmd

From: Derik

Date: 13 May, 2010 00:48:02

Message: 9 of 25

"us " <us@neurol.unizh.ch> wrote in message <hsfgne$bur$1@fred.mathworks.com>...
> "James " <james.downs@ngc.com> wrote in message <hsfcqc$688$1@fred.mathworks.com>...
> > Yes, you received two quick replies from two people who obviously had no idea what they were talking about... or did not attempt to verify your problem before writing to this thread.
> >
> > I recently installed Matlab 2010 and have run into this issue as well. Very frustrating... many legacy scripts no longer work properly as a result of this flaw. I, too, would be very interested to hear if there is a workaround of any sort available...
> >
> > - James
>
> no, you are simply wrong
> if you have a folder named foo.goo
> dir *.
> does NOT show it in the listing
>
> HENCE, the assumption that this syntax returns subfolders is flawed and should never have been used on first place (legacy is always a bad excuse for not coding properly, in particular if it comes to system related issues such as folder listings) - and has never been used by most of us (on first place)...
>
> the proper way to look for folder has ALWAYS been to check the .directory flag
>
> d=dir;
> fn={d([d.isdir]).name}.'
> % now foo.goo shows up...
> %{
> fn =
> '#SSC'
> '.' % <- note...
> '..'
> 'arch'
> 'fig'
> 'foo.foo'
> %}
>
> my impression is that some know pretty well what they are talking about
> us

Right.. I've never been in the habit of naming folders with a '.' in the name.
And I used the '.' and the '..' in the past as well.

But the question still remains of why does the

dir *.

List everything in the directory in 2010 where in previous version it did not.
I'm just curious to what changed. Maybe it has something to do with the wildcard, but I'm just grasping at air.

I forgot about the isdir flag. Thanks for that!

Subject: Matlab 2010a dir cmd

From: Walter Roberson

Date: 13 May, 2010 00:53:51

Message: 10 of 25

Derik wrote:

> From what I understand doing a dir *. should return everything that has
> no extension (the reason why I'm getting the folders)

The problem with that is that at the DOS level, directories *do* have an
extension: it is .DIR . If my memory on the matter has not given out on
me, support for *. as denoting directories was a programmed convention,
rather than it being that case that the extension wasn't there. It has
been rather a long time, so I am no longer completely certain, but I
think the original DOS required at least one character for the
extension, but that at some point (but well before "long filename
support"), it become valid to use an empty extension for files. Or maybe
it was a case that a program could create such a thing while users could
not do so directory. Sorry... it has been 29 years and I wasn't a DOS
hacker: my first home computer was a Unix clone (Cromemo CROMIX, which
was a Unix and CP/M hybrid, and could execute CP/M natively because it
had both a Z80 and M68000 CPU)


At the "long filename" level, there are a lot of different files that
"have no extension"...

Subject: Matlab 2010a dir cmd

From: us

Date: 13 May, 2010 00:56:05

Message: 11 of 25

dpb <none@non.net>
> OTOH, it sounds as though the behavior of ML has indeed changed and
> perhaps the default now is for it to transparently use the /A:-D switch
> internally to return only files instead of all files including those w/
> directory attribute...

i'm currently running a 2007b version and, therefore, cannot check what could(!) have happened:
it is possible that newer ML versions rely on (very fast) .net1+ system functions (for folder/file listings), which may(!) implement a different wildcard behavior...

again, just a thought... have to check this later...
us

Subject: Matlab 2010a dir cmd

From: James

Date: 13 May, 2010 01:45:20

Message: 12 of 25

Perhaps I have just been lucky as I have never named a folder "foo.goo"

- James

Subject: Matlab 2010a dir cmd

From: James

Date: 13 May, 2010 02:00:23

Message: 13 of 25

Despite the fact that this one guy has a strange proclivity for naming folders such things as "foo.goo", the fact of the matter is that the behaviour to the command "dir *." has changed in the latest Matlab release from all prior releases. It is unfortunate that The Mathworks places such low priority on maintaining backwards compatibility with their products.

- James

Subject: Matlab 2010a dir cmd

From: Walter Roberson

Date: 13 May, 2010 02:07:53

Message: 14 of 25

James wrote:
> Perhaps I have just been lucky as I have never named a folder "foo.goo"

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx

"Note that a directory is simply a file with a special attribute
designating it as a directory, but otherwise must follow all the same
naming rules as a regular file."

And thus as far as Microsoft is concerned, there is no reason why a
directory could not be named "foo.goo", and that has been true for some
time.

You spoke of "legacy scripts" breaking: were those scripts able to
handle generalized long directory names, which might have multiple
periods in them? Such as This.is.a.valid.directory.name ? If those
scripts broke with such names, then for the sake of legacy support,
under the reasoning of your previous "don't know what they are talking
about" posting, would it not be important for Matlab to continue to have
broken behaviour? I am unclear as to what your preference is here,
whether you are looking for _correct_ behaviour from Matlab, or if you
are looking for "Bug For Bug Compatability" ??

Subject: Matlab 2010a dir cmd

From: us

Date: 13 May, 2010 02:20:21

Message: 15 of 25

"James " <james.downs@ngc.com> wrote in message <hsfmfn$kqi$1@fred.mathworks.com>...
> Despite the fact that this one guy has a strange proclivity for naming folders such things as "foo.goo", the fact of the matter is that the behaviour to the command "dir *." has changed in the latest Matlab release from all prior releases. It is unfortunate that The Mathworks places such low priority on maintaining backwards compatibility with their products.
>
> - James

very wrong...
...and you're simply suffering from old mistakes, which understandably anger you...
but don't let your frustration go into the wrong direction...

1) TMW has never used/promoted your particular syntax DIR *. in any doc to guarantee to return subfolders...
2) this is an issue with the underlying system...
3) any person being aware of such idiosyncrasies would NEVER rely on such formulas as dir *.
4) TMW's DIR has ALWAYS returned a .directory flag .ISDIR, which makes it fully backward compatible...

us, just a guy who happens to name folders foo.goo

Subject: Matlab 2010a dir cmd

From: TideMan

Date: 13 May, 2010 03:47:47

Message: 16 of 25

On May 13, 2:20 pm, "us " <u...@neurol.unizh.ch> wrote:
> "James " <james.do...@ngc.com> wrote in message <hsfmfn$kq...@fred.mathworks.com>...
> > Despite the fact that this one guy has a strange proclivity for naming folders such things as "foo.goo", the fact of the matter is that the behaviour to the command "dir *." has changed in the latest Matlab release from all prior releases.  It is unfortunate that The Mathworks places such low priority on maintaining backwards compatibility with their products.
>
> > - James
>
> very wrong...
> ...and you're simply suffering from old mistakes, which understandably anger you...
> but don't let your frustration go into the wrong direction...
>
> 1) TMW has never used/promoted your particular syntax DIR *. in any doc to guarantee to return subfolders...
> 2) this is an issue with the underlying system...
> 3) any person being aware of such idiosyncrasies would NEVER rely on such formulas as dir *.
> 4) TMW's DIR has ALWAYS returned a .directory flag .ISDIR, which makes it fully backward compatible...
>
> us, just a guy who happens to name folders foo.goo

In recent times, us, you've been called a f****g retard, and this
bugger James has said you are wrong and is calling you a guy with a
strange proclivity.
Please don't take all this to heart.
Some of us still love you,
with all your quirks.

Subject: Matlab 2010a dir cmd

From: dpb

Date: 13 May, 2010 04:22:55

Message: 17 of 25

James wrote:
> Despite the fact that this one guy has a strange proclivity for naming
> folders such things as "foo.goo", the fact of the matter is that the
> behaviour to the command "dir *." has changed in the latest Matlab
> release from all prior releases. It is unfortunate that The Mathworks
> places such low priority on maintaining backwards compatibility with
> their products.

I've complained of TMW breaking compatibility occasionally in the past
but this is one that I can't elicit much sympathy for the user over --
the assumption that directories and only directories do not have
extensions is wrong in general and so relying on that behavior was poor
practice from the git-go despite it "working" for some special cases.

--

Subject: Matlab 2010a dir cmd

From: dpb

Date: 13 May, 2010 04:34:51

Message: 18 of 25

Walter Roberson wrote:
> Derik wrote:
>
>> From what I understand doing a dir *. should return everything that
>> has no extension (the reason why I'm getting the folders)
>
> The problem with that is that at the DOS level, directories *do* have an
> extension: it is .DIR . If my memory on the matter has not given out on
> me, support for *. as denoting directories was a programmed convention,
> rather than it being that case that the extension wasn't there. ...

I'm sure that isn't so w/ current versions and don't think that was ever
so in MS-DOS (and I don't believe it was in DR-DOS or other work-alikes,
either). There was an attribute from the git-go for directory I think.

I don't recall there ever being a proscription against the missing or
empty file extension, either, at least from DOS 2.x and later. As you
note, prior to that is long enough my recollection is blurry at best.

There _was_ a convention of users not giving directories extensions, but
that was at the user level and to best of my recollection wasn't ever
anything more than that at the actual OS-level.

Afaic(an)r(emember) the /A:D switch existed on DIR as the way to
differentiate/segregate in return info from the earliest versions.

CP/M was somewhat different but I forget the specifics...

--

Subject: Matlab 2010a dir cmd

From: Yair Altman

Date: 13 May, 2010 08:56:03

Message: 19 of 25

I get a deja-vu from another case when the dir command modified some undocumented behavior. In that case, it stopped sorting the results in R12 (a.k.a. Matlab 6.0): http://www.mathworks.com/matlabcentral/newsreader/view_thread/25268

(that post is such an oldie that Brett Schoelson was still not in TMW and Peter Acklam was still active on CSSM...)

Yair Altman
http://UndocumentedMatlab.com

Subject: Matlab 2010a dir cmd

From: Loren Shure

Date: 13 May, 2010 19:00:03

Message: 20 of 25

In article <hsfuub$dr6$1@news.eternal-september.org>, none@non.net
says...
> James wrote:
> > Despite the fact that this one guy has a strange proclivity for naming
> > folders such things as "foo.goo", the fact of the matter is that the
> > behaviour to the command "dir *." has changed in the latest Matlab
> > release from all prior releases. It is unfortunate that The Mathworks
> > places such low priority on maintaining backwards compatibility with
> > their products.
>
> I've complained of TMW breaking compatibility occasionally in the past
> but this is one that I can't elicit much sympathy for the user over --
> the assumption that directories and only directories do not have
> extensions is wrong in general and so relying on that behavior was poor
> practice from the git-go despite it "working" for some special cases.
>
> --
>

Folks, this is a bug and not an intended behavior. It has been reported
and is not meant to be an incompatibility. Do note that using the
approach about getting the dir info into a struct and checking the isdir
field is robust despite this dir bug.

--
Loren
http://blogs.mathworks.com/loren
http://matlabwiki.mathworks.com/MATLAB_FAQ

Subject: Matlab 2010a dir cmd

From: Walter Roberson

Date: 13 May, 2010 19:29:22

Message: 21 of 25

Loren Shure wrote:

> Folks, this is a bug and not an intended behavior. It has been reported
> and is not meant to be an incompatibility.


Based on the research I have done, I can find a little bit of justification
for dir('*.') on Windows to return all names that do not have an extension --
but I cannot find a justification for dir('*.') to be treated as "return all
of the subdirectories" as the semantics.

Or was "return all names that do not have an extension" the previous
behaviour, and one of the posters had misinterpreted that as "return all of
the subdirectories" due to not having happened to encounter a non-directory
that did not have an extension nor a directory that did have an extension ?

Subject: Matlab 2010a dir cmd

From: us

Date: 13 May, 2010 22:27:06

Message: 22 of 25

Loren Shure
> Folks, this is a bug and not an intended behavior. It has been reported
> and is not meant to be an incompatibility. Do note that using the
> approach about getting the dir info into a struct and checking the isdir
> field is robust despite this dir bug.

loren???
i hope you don't mean to tell that the syntax
     dir *.
is/was ever meant to just return subfolders...
it's broken (yes, i tried it on a r2010a sys) as it does not do what the corresponding dos-dir syntax does...
but by no means should people be let to believe now that, indeed, it returns subfolders...

urs

Subject: Matlab 2010a dir cmd

From: dpb

Date: 14 May, 2010 00:52:40

Message: 23 of 25

Loren Shure wrote:
> In article <hsfuub$dr6$1@news.eternal-september.org>, none@non.net
> says...
>> James wrote:
>>> Despite the fact that this one guy has a strange proclivity for naming
>>> folders such things as "foo.goo", the fact of the matter is that the
>>> behaviour to the command "dir *." has changed in the latest Matlab
>>> release from all prior releases. It is unfortunate that The Mathworks
>>> places such low priority on maintaining backwards compatibility with
>>> their products.
>> I've complained of TMW breaking compatibility occasionally in the past
>> but this is one that I can't elicit much sympathy for the user over --
>> the assumption that directories and only directories do not have
>> extensions is wrong in general and so relying on that behavior was poor
>> practice from the git-go despite it "working" for some special cases.
>>
...

> Folks, this is a bug and not an intended behavior. It has been reported
> and is not meant to be an incompatibility. Do note that using the
> approach about getting the dir info into a struct and checking the isdir
> field is robust despite this dir bug.

Yeah, I had my thinking crossed about the symptoms Derik was reporting.
  Realized later my foopah and agree the new behavior is broken (as well
as being incompatible w/ previous versions :) ).

--

Subject: Matlab 2010a dir cmd

From: Loren Shure

Date: 14 May, 2010 14:39:48

Message: 24 of 25

In article <hshubq$cu1$1@fred.mathworks.com>, us@neurol.unizh.ch says...
> Loren Shure
> > Folks, this is a bug and not an intended behavior. It has been reported
> > and is not meant to be an incompatibility. Do note that using the
> > approach about getting the dir info into a struct and checking the isdir
> > field is robust despite this dir bug.
>
> loren???
> i hope you don't mean to tell that the syntax
> dir *.
> is/was ever meant to just return subfolders...
> it's broken (yes, i tried it on a r2010a sys) as it does not do what the corresponding dos-dir syntax does...
> but by no means should people be let to believe now that, indeed, it returns subfolders...
>
> urs
>

dir *. should NOT find only subfolders.

--
Loren
http://blogs.mathworks.com/loren
http://matlabwiki.mathworks.com/MATLAB_FAQ

Subject: Matlab 2010a dir cmd

From: us

Date: 14 May, 2010 14:52:05

Message: 25 of 25

Loren Shure
> dir *. should NOT find only subfolders.

very good(!), loren...

'cause now we're back to the very beginning of this rather long dispute:
original tone OP
...In my 2009a and previous version of matlab it always returned just the directories. Now it is returning everything...

and all some of us said (and try to correct) was: this is NOT what this particular syntax is about...

:-)
urs

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us