Prev: autocorrelation
Next: resetting Gui Slider position
From: us on 12 May 2010 20:22
"James " <james.downs(a)ngc.com> wrote in message <hsfcqc$688$1(a)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
From: Walter Roberson on 12 May 2010 20:35
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]);
From: dpb on 12 May 2010 20:39
Derik wrote:
> Walter Roberson <roberson(a)hushmail.com> wrote in message
> <RnGGn.6843$wV2.3222(a)newsfe23.iad>...
>> us wrote:
>> > "Derik " <derik.alles+matlab(a)gmail.com> wrote in message >
>> <hsf7bc$f7m$1(a)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).

--
From: Derik on 12 May 2010 20:48
"us " <us(a)neurol.unizh.ch> wrote in message <hsfgne$bur$1(a)fred.mathworks.com>...
> "James " <james.downs(a)ngc.com> wrote in message <hsfcqc$688$1(a)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!
From: Walter Roberson on 12 May 2010 20:53
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"...
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: autocorrelation
Next: resetting Gui Slider position