Prev: autocorrelation
Next: resetting Gui Slider position
From: dpb on 13 May 2010 00:22
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.

--
From: dpb on 13 May 2010 00:34
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...

--

From: Yair Altman on 13 May 2010 04:56
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
From: Loren Shure on 13 May 2010 15:00
In article <hsfuub$dr6$1(a)news.eternal-september.org>, none(a)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
From: Walter Roberson on 13 May 2010 15:29
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 ?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: autocorrelation
Next: resetting Gui Slider position