Thread Subject: copyfile(..) loses spaces

Hi all,

just ran into undocumented and strange copyfile() behaviour (R2011b, Win7 x64)

the script to reproduce it is below:

=====================================================

%% create dirs
testdir = 'c:\temp\testdir';
sourcedir = [testdir '\source'];
targetdir = [testdir '\target'];

mkdir(sourcedir);
mkdir(targetdir);

%% create a file with name beginning with ' '
filename = ' a';
filepath = [sourcedir '\' filename];
fid = fopen(filepath,'w+');
fclose(fid);

%% check source
disp('********* source:');
d=dir(sourcedir); d.name
% result:
% ans =
% a
% ans =
% .
% ans =
% ..
% (space is OK)

%% copy
disp('********* copy:');
 [status,message,messageid] = copyfile(sourcedir,targetdir);
% this would result in "OK":
% status =
% 1
% message =
% ''
% messageid =
% ''

%% check result
disp('********* result:');
d=dir(targetdir); d.name
% result:
% ans =
% .
% ans =
% ..
% ans =
% a
% (space is gone)

====================================================

This doesn't depend on depth of filestructure, any '.\b\c\ a' would result in '.\b\c\a' too...

Looks like a bug, isn't it?

Looks like nobody's interested...

Well - may be there should be a short desription, here it is:
if you copy

'c:\temp\testdir\source\ a' (note the space before 'a')
to
'c:\temp\testdir\target\'

there would be a 'a' file ,not ' a' there.

On 11/20/2011 8:59 AM, Igor wrote:
> Looks like nobody's interested...
> Well - may be there should be a short desription, here it is:
> if you copy
> 'c:\temp\testdir\source\ a' (note the space before 'a')
> to
> 'c:\temp\testdir\target\'
> there would be a 'a' file ,not ' a' there.

One would certainly hope...anybody who would _want_ a file w/ even
embedded blanks deserves the hassle they get in handling them, what more
one w/ an (essentially invisible) leading one (blank, that is).

IM(NSH)0 :), it should never have been allowed (and I suspect it was an
oversight) to create such legal filenames.

As for actually dealing with it if one has to, send the proper strings
to the OS command processor directly.

Several things in Matlab utilities don't match precisely the
characteristics of the underlying OS.

--

dpb <none@non.net> wrote in message <jab7hf$2qg$1@speranza.aioe.org>...

> IM(NSH)0 :), it should never have been allowed (and I suspect it was an
> oversight) to create such legal filenames.

I agree, there should be one strict standard for all filenames. But there is nothing like this... Windows supports such filenames... User is able to create thousands of them, regardless of my wish... And I can see no adequate explanation for such copyfile() 's behaviour... A least such a limitation should be noticed in filecopy's documentation , I think...

On 11/20/2011 1:43 PM, Igor wrote:
> dpb <none@non.net> wrote in message <jab7hf$2qg$1@speranza.aioe.org>...
>
>> IM(NSH)0 :), it should never have been allowed (and I suspect it was
>> an oversight) to create such legal filenames.
>
> I agree, there should be one strict standard for all filenames. But
> there is nothing like this... Windows supports such filenames... User is
> able to create thousands of them, regardless of my wish... And I can see
> no adequate explanation for such copyfile() 's behaviour... A least such
> a limitation should be noticed in filecopy's documentation , I think...

Well, you can file a bug/deficiency report w/ TMW official support, but
as I noted before, there are a number of such discrepancies in which the
Matlab-implemented utilities don't strictly follow the underlying OS and
have been so for "since forever" so it seems unlikely they'll change any
time soon.

If you must deal with them w/ Matlab at the moment, you'll have to shell
or mex...

--

dpb <none@non.net> wrote in message <jabqfd$pof$1@speranza.aioe.org>...
> Well, you can file a bug/deficiency report w/ TMW official support,...
yep... just wanted to check myself once again...

> If you must deal with them w/ Matlab at the moment, you'll have to shell
> or mex...

I'm using dos('xcopy ...') for now...


Thanks for your replies!

just FYI,
you know you can run the DOS command directly from MATLAB, which gives you more stability from MATLAB, because you will indirectly be using the DOS.

For example, if u want to copy all the files in your current MATLAB directory to a directory in say C:\mydir..... from the MATLAB command window:
>> str = 'copy *.* c:\mydir'
>> system(str);

so using the function 'system' at the command prompt will take care of the issue u are having with the "\ a" copyfile.

Regards.

"ade77 " <ade100a@gmail.com> wrote in message <jac3g2$5c4$1@newscl01ah.mathworks.com>...
> >> system(str);

Hi ade77,
thanks for your concern !
 
Do you mean system('xcopy ...') is any better then dos('xcopy ..') ?
I always thought this is just the same...

On 20 Nov, 16:49, dpb <n...@non.net> wrote:
> On 11/20/2011 8:59 AM, Igor wrote:
>
> > Looks like nobody's interested...
> > Well - may be there should be a short desription, here it is:
> > if you copy
> > 'c:\temp\testdir\source\ a' (note the space before 'a')
> > to
> > 'c:\temp\testdir\target\'
> > there would be a 'a' file ,not ' a' there.
>
> One would certainly hope...anybody who would _want_ a file w/ even
> embedded blanks deserves the hassle they get in handling them, what more
> one w/ an (essentially invisible) leading one (blank, that is).
>
> IM(NSH)0 :), it should never have been allowed (and I suspect it was an
> oversight) to create such legal filenames.

I certainly agree with your main concern: These kinds of file names
should never have been allowed!

However, they were not allowed by oversight, they were
introduced by design.

Whitespace characters were first allowed in filenames in
windows 95 or thereabouts, introduced in the mid '90s.
One can only speculate what went on inside the minds of
the people who hatched that idea, as it plays all kinds
of havoc with script interactions with the underlying OS.

The lack of script interactions is, of course, one main
reason why people are unable to use their computers
efficiently. And note, not 'easily'; 'efficiently'.

> As for actually dealing with it if one has to, send the proper strings
> to the OS command processor directly.

Yep.

> Several things in Matlab utilities don't match precisely the
> characteristics of the underlying OS.

That's because the OS'es differ in certain essential ways.
One of the main benefits of matlab is that it is portable
across platforms: What works on one platform also works on
all the others where that version of matlab is available.
Not so common these days, but once upon a time I juggeled
between four different OS'es (Solaris, IRIX, HP-UX and
windows) on a daily basis, with the odd visit to a DEC Alpha
with its NEXT OS in between.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <6f1129a0-b2ca-4063-a004-d8449b688937@m19g2000yqh.googlegroups.com>...
> One of the main benefits of matlab is that it is portable
> across platforms: What works on one platform also works on
> all the others where that version of matlab is available.

Certainly.
That's why it should support those spaces.
It won't introduce new conflicts, it would just allow me and others not to think too much about "is copyfile() compatible with windows?"

One would never ran into a case that a script running just OK under most conditions would provide some ridiculous result if the only thing changed is a dataset filename. imho, THIS is called cross-platform compatibility.

On 22 Nov, 14:45, "Igor " <i...@mail.ru> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <6f1129a0-b2ca-4063-a004-d8449b688...@m19g2000yqh.googlegroups.com>...
> > One of the main benefits of matlab is that it is portable
> > across platforms: What works on one platform also works on
> > all the others where that version of matlab is available.
>
> Certainly.
> That's why it should support those spaces.
> It won't introduce new conflicts, it would just allow me and others not to think too much about "is copyfile() compatible with windows?"
>
> One would never ran into a case that a script running just OK under most conditions would provide some ridiculous result if the only thing changed is a dataset filename. imho, THIS is called cross-platform compatibility.

I think you will find that this issue occurs only on the
platform with broken OS. There is no need to spread the
disease to other platforms as well.

Rune

On 11/22/2011 6:08 AM, Rune Allnor wrote:
> On 20 Nov, 16:49, dpb<n...@non.net> wrote:
...
>> one w/ an (essentially invisible) leading one (blank, that is).
>>
>> IM(NSH)0 :), it should never have been allowed (and I suspect it was an
>> oversight) to create such legal filenames.
>
> I certainly agree with your main concern: These kinds of file names
> should never have been allowed!
>
> However, they were not allowed by oversight, they were
> introduced by design.
...

I'm certainly aware that MS deliberately introduced embedded spaces in
files names w/ the (mistaken) intent that there would thus be a parallel
to English writing of "folder" names, etc.., ...

My comment was specifically on allowing a _leading_ space--that does
_NOT_ have a precedent in ordinary usage and I still think is likely to
be an unintended artifact in the initial introduction.

--

On 11/22/2011 6:08 AM, Rune Allnor wrote:
> On 20 Nov, 16:49, dpb<n...@non.net> wrote:
...

>> Several things in Matlab utilities don't match precisely the
>> characteristics of the underlying OS.
>
> That's because the OS'es differ in certain essential ways.
> One of the main benefits of matlab is that it is portable
> across platforms: What works on one platform also works on
> all the others where that version of matlab is available.

...

But it ends up that it doesn't work the same...it would still work on
both platforms but have the more likely expected result if behavior was
as the OS behavior.

In this case, the result would be to copy all files in one OS but not
all in another.

Another case that at least used to be is the '?' wild card on filenames
isn't honored on the version of Matlab here (don't know if that's been
fixed or not) but it's surely a pita and afaics there's no reason.

I'm w/ OP here; the user-friendly thing to do is for Matlab utilities to
mimic the OS under which they're running; it's user- belligerent
otherwise. (Again, M(NSH)O, $0.02, ymmv, etc., etc., etc., ...)

I'm sure one could find places where there's a need to do something
unique, but the ones I can think of and this one, "not so much".

--

On 22 Nov, 15:21, dpb <n...@non.net> wrote:
> On 11/22/2011 6:08 AM, Rune Allnor wrote:> On 20 Nov, 16:49, dpb<n...@non.net>  wrote:
> ...
> >> one w/ an (essentially invisible) leading one (blank, that is).
>
> >> IM(NSH)0 :), it should never have been allowed (and I suspect it was an
> >> oversight) to create such legal filenames.
>
> > I certainly agree with your main concern: These kinds of file names
> > should never have been allowed!
>
> > However, they were not allowed by oversight, they were
> > introduced by design.
>
> ...
>
> I'm certainly aware that MS deliberately introduced embedded spaces in
> files names w/ the (mistaken) intent that there would thus be a parallel
> to English writing of "folder" names, etc.., ...

MS has done the world few (any?) favours in their OS design.

The GUI philosophy is fundamentally flawed, in that it is
designed to mimic human actions in the pre-computer world:

- Instead of handling a piece of paper in the past, we now
  handle a document (file).
- Instead of handling a binder full of paers in the past,
  we now handle a folder.

And so on.

The problem is that MS has only changed what manual operations
we do, not the way we work: We still do manual operations.

All the efficiency (not ease!) of scripting has been lost.

> My comment was specifically on allowing a _leading_ space--that does
> _NOT_ have a precedent in ordinary usage and I still think is likely to
> be an unintended artifact in the initial introduction.

Making a file name that starts with a whitespace is stupid, but
legal. So is making a file name that contains *only* whitespaces:
Extremely stupid, but still legal.

There is a limit to how far one should respect consequences of
previous stupidity: I am with TMW, in that you, the user, has
to suffer the consequences of doing stupid stuff. Even if legal.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <b99d6fe6-d07f-4f4d-a78d-ac26087a2410@k26g2000yqd.googlegroups.com>...
> I think you will find that this issue occurs only on the
> platform with broken OS. There is no need to spread the
> disease to other platforms as well.

This feature could be easily limited to those OS.

You either support all possible OS's filenames, or a support of that OS is "limited".

On 11/22/2011 8:48 AM, Rune Allnor wrote:
...

>> My comment was specifically on allowing a _leading_ space--that does
>> _NOT_ have a precedent in ordinary usage and I still think is likely to
>> be an unintended artifact in the initial introduction.
>
> Making a file name that starts with a whitespace is stupid, but
> legal. So is making a file name that contains *only* whitespaces:
> Extremely stupid, but still legal.
...

Nothing different there. I reiterate...

I still think that allowing leading whitespace is likely to
be an unintended artifact in the initial introduction (iow, it wasn't
thought through to specifically address preventing and so got left in by
default rather than by specific, named/designed inclusion).

I had already in initial response to OP noted that it's a generally
silly thing for a user to do.

MSDN specifically mentions that _trailing_ whitespace is allowed (but
not recommended but I can find no specific mention of leading spaces
other than one comment in passing that the gui will not process them for
some cases and that the behavior in versions of IE is also not
consistent in that some will and at least one more recent version will
not honor the leading space(s).

All in all, it's a mishmash left over from not having specified the
behavior fully in the beginning (again, imo, I wasn't there, can only
observe).

Anyway, there's no further point here--OP as his answer that he has to
use base OS functions to deal with his situation. Whether it's a good
one or not isn't mine to solve.

--

On 22 Nov, 15:37, dpb <n...@non.net> wrote:
> On 11/22/2011 6:08 AM, Rune Allnor wrote:> On 20 Nov, 16:49, dpb<n...@non.net>  wrote:
>
> ...
>
> >> Several things in Matlab utilities don't match precisely the
> >> characteristics of the underlying OS.
>
> > That's because the OS'es differ in certain essential ways.
> > One of the main benefits of matlab is that it is portable
> > across platforms: What works on one platform also works on
> > all the others where that version of matlab is available.
>
> ...
>
> But it ends up that it doesn't work the same...it would still work on
> both platforms but have the more likely expected result if behavior was
> as the OS behavior.

Once one messes directly with the OS, portability is thrown
out the window. Don't expect portability or the same
behaviour across OSes.

> In this case, the result would be to copy all files in one OS but not
> all in another.

You could turn that argument upside down and ask how the
FOPEN command should work in an OS that does *not* support
whitespaces in file names, if the user specifies

fid = fopen('My File.txt');

Would you persist arguing that the function should behave
the same across all OSes?

> Another case that at least used to be is the '?' wild card on filenames
> isn't honored on the version of Matlab here (don't know if that's been
> fixed or not) but it's surely a pita and afaics there's no reason.

Sure. Then there is the case about no recursive searching
down the directory tree in the DIR command (might have been
fixed in recent matlab versions; I don't know).

> I'm w/ OP here; the user-friendly thing to do is for Matlab utilities to
> mimic the OS under which they're running; it's user- belligerent
> otherwise.  (Again, M(NSH)O, $0.02, ymmv, etc., etc., etc., ...)

Once upon a time I saved a file under MS-DOS with the name
MyFile^2.txt where '^2' means 'superscript 2'. A ridiculous thing
to do (but legal, what the OS was concerned), as I either forgot
what voodoo to use to type the '^2', or the keyboard was set up
somewhat differently that on the first PC; I don't remember.

Again, 'legal' does not mean 'ought to be done' or even 'supported'.

> I'm sure one could find places where there's a need to do something
> unique, but the ones I can think of and this one, "not so much".

The recursive DIR command combined with regular expressions ought
to go a long way, in those few cases one needs it.

Rune

On 11/22/2011 11:49 AM, Rune Allnor wrote:
> On 22 Nov, 15:37, dpb<n...@non.net> wrote:
>> On 11/22/2011 6:08 AM, Rune Allnor wrote:> On 20 Nov, 16:49,
dpb<n...@non..net> wrote:
>>
>> ...
>>
...

> Once one messes directly with the OS, portability is thrown
> out the window. Don't expect portability or the same
> behaviour across OSes.
>
>> In this case, the result would be to copy all files in one OS but not
>> all in another.
>
> You could turn that argument upside down and ask how the
> FOPEN command should work in an OS that does *not* support
> whitespaces in file names, if the user specifies
>
> fid = fopen('My File.txt');
>
> Would you persist arguing that the function should behave
> the same across all OSes?

No, I just got through saying that IM(NSH)O ( :) ) they should _MIMIC_
the underlying OS. If it would fail on the OS, I'd expect Matlab to
error and tell me so.

>> Another case that at least used to be is the '?' wild card on filenames
>> isn't honored on the version of Matlab here (don't know if that's been
>> fixed or not) but it's surely a pita and afaics there's no reason.
>
> Sure. Then there is the case about no recursive searching
> down the directory tree in the DIR command (might have been
> fixed in recent matlab versions; I don't know).
>
>> I'm w/ OP here; the user-friendly thing to do is for Matlab utilities to
>> mimic the OS under which they're running; it's user- belligerent
>> otherwise. (Again, M(NSH)O, $0.02, ymmv, etc., etc., etc., ...)
>
> Once upon a time I saved a file under MS-DOS with the name
> MyFile^2.txt where '^2' means 'superscript 2'. A ridiculous thing
> to do (but legal, what the OS was concerned), as I either forgot
> what voodoo to use to type the '^2', or the keyboard was set up
> somewhat differently that on the first PC; I don't remember.
>
> Again, 'legal' does not mean 'ought to be done' or even 'supported'.
>
>> I'm sure one could find places where there's a need to do something
>> unique, but the ones I can think of and this one, "not so much".
>
> The recursive DIR command combined with regular expressions ought
> to go a long way, in those few cases one needs it.
...

If I had a version of ML that supported regexp, perhaps.

My complaint is the OS supports a set of wildcards (not necessarily the
best, but hey, it's what's there) and so there's no cost to TMW to pass
that through to the OS API. Instead, they chose to neuter functionality
in the sake of vanilla-based conformity.

It was a design decision; just one on which I disagree w/ the choice
selected. I'd rather have the builtin functions do what I expect such a
function to do on the OS and deal w/ the OS-specific issues in coding
practice or other means rather than have to shell; it just seems cleaner
to me that way (or forget about implementing the utilities in Matlab
entirely and shell for all). It's having the utility implemented but
_still_ having to shell that doesn't seem to make any sense as an
implementation choice that I don't grok/like/understand. Not that TMW
is going to make such modifications at this point; as told OP way
upthread--he can make an official bug/deficiency/enhancement
report/request but it's _extremely_ unlikely to be acted upon in a
manner he and I would think appropriate; we simply disagree w/ TMW on
this implementation detail/choice.

--

On 22 Nov, 19:39, dpb <n...@non.net> wrote:
> On 11/22/2011 11:49 AM, Rune Allnor wrote:> On 22 Nov, 15:37, dpb<n...@non.net>  wrote:
> >> On 11/22/2011 6:08 AM, Rune Allnor wrote:> On 20 Nov, 16:49,
> dpb<n...@non..net> wrote:
>
> >> ...
>
> ...
>
> > Once one messes directly with the OS, portability is thrown
> > out the window. Don't expect portability or the same
> > behaviour across OSes.
>
> >> In this case, the result would be to copy all files in one OS but not
> >> all in another.
>
> > You could turn that argument upside down and ask how the
> > FOPEN command should work in an OS that does *not* support
> > whitespaces in file names, if the user specifies
>
> > fid = fopen('My File.txt');
>
> > Would you persist arguing that the function should behave
> > the same across all OSes?
>
> No, I just got through saying that IM(NSH)O ( :) ) they should _MIMIC_
> the underlying OS.  If it would fail on the OS, I'd expect Matlab to
> error and tell me so.

While I might agree with the intention, I can see no practical
way of achieving it: It would mean that every version of matlab
would need to be kept up to date not only with the OS it is
supposed to run on (a formidable task in itself), but also
with all the other OSes matlab might run on.

I can easily see why TMW backs away from that sort of commitment.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message
> way of achieving it: It would mean that every version of matlab
> would need to be kept up to date not only with the OS it is
> supposed to run on (a formidable task in itself), but also
> with all the other OSes matlab might run on.

There's the official list of OS's supported... And some basic stuff like fopen(), copyfile() and ~10 more basic IO functions should be kept up to date, well-documented and reliable. That's not too much work to do...

On 11/22/2011 1:39 PM, Rune Allnor wrote:
...

> While I might agree with the intention, I can see no practical
> way of achieving it: It would mean that every version of matlab
> would need to be kept up to date not only with the OS it is
> supposed to run on (a formidable task in itself), but also
> with all the other OSes matlab might run on.
...

Well, just as the one example of '?' -- seems to me they have to
special-case it to not have the Win API FindFirstEtc... not honor it
already. Why would it be any harder/more effort to return what the OS
returns in the structure w/ it it acting as it does under shell('dir
...?...') as in the dir() command? Don't see it, meself...

I can imagine there are some areas, granted; the ones discussed here
just don't seem to be any fundamental reason for the behavior chosen
other than that they did (apparently) choose some LCD set of behaviors
to implement.

The biggest hassle w/ doing it that way is it isn't documented what
does/does not follow so folks (as OP here) get surprised (as I did when
I so carefully chose a set of filenames such that the ?? pattern would
nicely retrieve the particular ones I wanted only to find that Matlab
treats the '?' character as the absolute character in the filename, not
the wild card--bummer that was! :(

--

On 22 Nov, 22:56, dpb <n...@non.net> wrote:
> On 11/22/2011 1:39 PM, Rune Allnor wrote:
> ...
>
> > While I might agree with the intention, I can see no practical
> > way of achieving it: It would mean that every version of matlab
> > would need to be kept up to date not only with the OS it is
> > supposed to run on (a formidable task in itself), but also
> > with all the other OSes matlab might run on.
>
> ...
>
> Well, just as the one example of '?' -- seems to me they have to
> special-case it to not have the Win API FindFirstEtc... not honor it
> already.  Why would it be any harder/more effort to return what the OS
> returns in the structure w/ it it acting as it does under shell('dir
> ...?...') as in the dir() command?  Don't see it, meself...

No, I suppose you don't. It's one of those Pandora's boxes
one doesn't realize implications of until it's far too late.
Believe me, one doesn't want to mess with that kind of stuff
unless one have no choise whatsoever.

Rune

On 11/22/2011 4:17 PM, Rune Allnor wrote:
...

> No, I suppose you don't. It's one of those Pandora's boxes
> one doesn't realize implications of until it's far too late.
> Believe me, one doesn't want to mess with that kind of stuff
> unless one have no choise whatsoever.

I certainly understand that FindFirstFile and friends APIs honor the "*"
and "&" wildcards automagically so in fact TMW has to special-case them
in their utility under Windows rather than simply passing the string and
returning the found (or not) file(s).

So, they've already been "messing with that kind of stuff"...

--

On 23 Nov, 01:00, dpb <n...@non.net> wrote:
> On 11/22/2011 4:17 PM, Rune Allnor wrote:
> ...
>
> > No, I suppose you don't. It's one of those Pandora's boxes
> > one doesn't realize implications of until it's far too late.
> > Believe me, one doesn't want to mess with that kind of stuff
> > unless one have no choise whatsoever.
>
> I certainly understand that FindFirstFile and friends APIs honor the "*"
> and "&" wildcards automagically so in fact TMW has to special-case them
> in their utility under Windows rather than simply passing the string and
> returning the found (or not) file(s).

I don't know how those kinds of things are done 'under the hood'.
What I do know is that making one, consistent, unambiguous API
which is portable across platforms is a mess one does not want
to have more to do with than absolutely necessary.

> So, they've already been "messing with that kind of stuff"...

Sure. But only as much as necessary.

Rune

On 22 Nov, 15:57, "Igor " <i...@mail.ru> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <b99d6fe6-d07f-4f4d-a78d-ac26087a2...@k26g2000yqd.googlegroups.com>...
> > I think you will find that this issue occurs only on the
> > platform with broken OS. There is no need to spread the
> > disease to other platforms as well.
>
> This feature could be easily limited to those OS.
>
> You either support all possible OS's filenames, or a support of that OS is "limited".

You are complaining about the wrong issue.

Don't blame TMW for not keeping matlab exactly
in tune with windows. Instead, complain to microsoft
for allowing leading whitespaces in filenames at all.

Rune

On 11/22/2011 7:25 PM, Rune Allnor wrote:

>
> You are complaining about the wrong issue.
>
> Don't blame TMW for not keeping matlab exactly
> in tune with windows. Instead, complain to microsoft
> for allowing leading whitespaces in filenames at all.
>
> Rune

Having white spaces in file names is a bad idea to start with.
I never name a file or a directory with a white space in the name,
and I always use lower case letters (in case I need to copy files
around from windows to unix/linux system, to eliminate
possible problems).

Since I worked on unix system, I learned this long time ago.

It seems people who use windows are used to this bad habit of
having spaces and other strange characters in in file names.

Instead of making a file name like this

"this is a file name.txt"

One can write it as

"this_is_a_file_name.txt"

--Nasser

"Nasser M. Abbasi" <nma@12000.org> wrote in message <jahihb$hjd$1@speranza.aioe.org>...
> I never name a file or a directory with a white space in the name,

Me too!

> Instead of making a file name like this
>
> "this is a file name.txt"
>
> One can write it as
>
> "this_is_a_file_name.txt"

Yes, that's better, but there's a ton of "this is a file name.txt" and you can not do a thing with it.

Rune Allnor <allnor@tele.ntnu.no> wrote in message <21172cb4-713b-4170-949a-28083a04b3b3@m7g2000yqm.googlegroups.com>...
> Don't blame TMW for not keeping matlab exactly
> in tune with windows. Instead, complain to microsoft
> for allowing leading whitespaces in filenames at all.

Unfortunately it does not work that way. If you're writing a tool that supports an OS, you should honor any case possible under this OS, not complain that OS is bad.

Just like i had to use dos('xcopy') as a workaround to support any case possible.

Preferably, you should not introduce your own limitations that could make your tool incompatible with existing environment, you should support all cases.

If you do introduce a limitation, you should properly document it, one shouldn't say "it's obvious" or "no one would do that".


Let's suppose you're riding a bus, and a bridge towards you is crashed. (And it crashed 20 years before.) A driver is going straight to that bridge - since there was a bridge, and it was nice...

Do you think driver is doing everything just OK, it's just a municipality who's responsible for all bridges and a fact that there's no bridge here?

Sincerely yours,
Captain Obvious.

On 23 Nov, 13:21, "Igor " <i...@mail.ru> wrote:

> If you do introduce a limitation, you should properly document it, one shouldn't say "it's obvious" or "no one would do that".
>
> Let's suppose you're riding a bus, and a bridge towards you is crashed. (And it crashed 20 years before.) A driver is going straight to that bridge - since there was a bridge, and it was nice...
>
> Do you think driver is doing everything just OK, it's just a municipality who's responsible for all bridges and a fact that there's no bridge here?
>
> Sincerely yours,
> Captain Obvious.

The driver might well read a map and come up with a plan to
use a road that used to be OK. But he is himself responsible
for not driving off the road, or off a broken bridge.

After he has realized the problem, one can start arguing
how he should have been warned and who is to blame:

- Should he blame the map makers for not marking the
  bridge as broken?
- Should he blame the road authorites for not erecting
  a sign to warn that the bridge is broken?
- Should he blame the road authorites for not closing
  the road leading up to the bridge?
- Should he blame the road authorities for not fixing
  the bridge?

Even if you are disappointed that the map doesn't
match reality, blaming the map makers is not useful.
Any one used to using maps will know that they are
not exact in every detail, and allow for that.

If the map and terrain don't match, the terrain is
right. Every time.

Rune

I try under windows explorer adding a front space in an existing filename, and Windows remove it automatically, just like MATLAB.

The question is: does a filename starts with space is legal?

Might be copyfile is actually NOT buggy, but actually FOPEN that should return an error.

Bruno

Rune Allnor <allnor@tele.ntnu.no> wrote in message <401f6c79-c7e2-4af5-8424-c0585378cae2@g7g2000vbd.googlegroups.com>...
> Even if you are disappointed that the map doesn't
> match reality, blaming the map makers is not useful.
> Any one used to using maps will know that they are
> not exact in every detail, and allow for that.
>
> If the map and terrain don't match, the terrain is
> right. Every time.

Yep, but well-known issues should be fixed when they would be going to release a new version. that's what I'm trying to do.


"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <jairu8$hdd$1@newscl01ah.mathworks.com>...
> I try under windows explorer adding a front space in an existing filename, and Windows remove it automatically...

Explorer is trying to prevent a user from doing a stupid thing - it's right. Neither it would allow a trailing space.
Still you're able to create such a file with,for example
'copy "1.txt" " 1.txt"'
or a 3rd party tool, like Total commander..

>..Windows remove it automatically, just like MATLAB.
Hm... I've just tried
>> fopen(' 2.txt','w+');
>> fclose all
and it honored those space.
Were you talking about creating files with GUI ?

>
> The question is: does a filename starts with space is legal?

I was unable to find a proper documentation on this case... (well, I had not spent too much time on it). I've considered this legal since it's legal in 'copy'@cmd , fopen@Matlab and so on...

"Igor" wrote in message <jaiv79$s42$1@newscl01ah.mathworks.com>...
>
>
> Explorer is trying to prevent a user from doing a stupid thing - it's right. Neither it would allow a trailing space.

Can we consider then copyfile also prevents a user from doing a stupid thing? It's even rectify a stupid naming previously made. In fact to me it's very smart, admittedly not documented.
 
Bruno

On 11/22/2011 7:23 PM, Rune Allnor wrote:
> On 23 Nov, 01:00, dpb<n...@non.net> wrote:
>> On 11/22/2011 4:17 PM, Rune Allnor wrote:
>> ...
>>
>>> No, I suppose you don't. It's one of those Pandora's boxes
>>> one doesn't realize implications of until it's far too late.
>>> Believe me, one doesn't want to mess with that kind of stuff
>>> unless one have no choise whatsoever.
>>
>> I certainly understand that FindFirstFile and friends APIs honor the "*"
>> and "&" wildcards automagically so in fact TMW has to special-case them
>> in their utility under Windows rather than simply passing the string and
>> returning the found (or not) file(s).
>
> I don't know how those kinds of things are done 'under the hood'.
> What I do know is that making one, consistent, unambiguous API
> which is portable across platforms is a mess one does not want
> to have more to do with than absolutely necessary.

_Eventually_ it has to resolve to an appropriate OS system call. For the
particular miniscule nit of the "?" wildcard that would be
FindFirstFile() and friends FindNextFile() and an eventual FindClose()
call on Win32.

 From the SDK doc's one finds

> FindFirstFile
> The FindFirstFile function searches a directory for a file whose
> name matches the specified filename. FindFirstFile examines
> subdirectorynames as well as filenames.
>
> HANDLE FindFirstFile(
> LPCTSTR lpFileName, // pointer to name of file to search for
> LPWIN32_FIND_DATA lpFindFileData
> // pointer to returned information
> );
>
> Parameters
> lpFileName
> Pointer to a null-terminated string that specifies a valid directory or path and filename, which can contain wildcard characters (* and ?). ...
>
> ...
>
> lpFindFileData
> Pointer to the WIN32_FIND_DATA structure that receives information
> about the found file or subdirectory. The structure can be used in
> subsequent calls to the FindNextFile or FindClose function to refer
> tothe file or subdirectory.
>
> Return Values
> If the function succeeds, the return value is a search handle used
> in a subsequent call to FindNextFile or FindClose.
>
> If the function fails, the return value is INVALID_HANDLE_VALUE. To
> get extended error information, call GetLastError.
>
> Remarks
> The FindFirstFile function opens a search handle and returns
> information about the first file whose name matches the specified
> pattern. Once the search handle is established, you can use the
> FindNextFile function to search for other files that match the same
> pattern. When the search handle is no longer needed, close it by
> usingthe FindClose function.
>

Even if use the underlying C/C++ rtl, it will map to the OS call in the
end. So, they've had to do a special-casing already to ignore the ?
wildcard. My question is "Why go to the trouble to specifically neuter
a feature?" It's not like they chose to ignore _all_ wildcards so it
can't be they chose to not process multiple files returned in a call but
picked on "?" specifically. It's just not logical.

>> So, they've already been "messing with that kind of stuff"...
>
> Sure. But only as much as necessary.
...

More than "necessary", actually. My suggestion is to essentially forget
about the "unambiguous" API because in reality it's more ambiguous to
the enduser as is as what doesn't follow the expected paradigm on any
given OS isn't documented so one only learns when something doesn't
perform as expected (back to OP's OP). If it behaves differently on a
different OS, let the enduser deal with it--after all, he's the one
who's using multiple OS (or even more likely, not).

To reiterate it is a philosophy (combined w/ the lack of complete
documentation which I also regularly comment to TMW on before as being
descriptive/narrative style rather in too many areas) that isn't as
useful as it seems it might be and causes workarounds in one direction
as opposed to another. I'd prefer the other, on the whole.

--

On 11/23/2011 7:20 AM, Bruno Luong wrote:
> I try under windows explorer adding a front space in an existing
> filename, and Windows remove it automatically, just like MATLAB.
>
> The question is: does a filename starts with space is legal?
>
> Might be copyfile is actually NOT buggy, but actually FOPEN that should
> return an error.

MSDN addresses blankspace before/after filenames in KB articles although
the definition of legal filenames does not mention leading spaces it
notes the gui won't handle trailing spaces--

"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."

<http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names>

AFAIK, this is the limitation of requirements to be legal that MS has
prescribed.

That _using_ a leading whitespace for a file name is in general a dumb
idea isn't the question, however; the problem is that the limitation on
handling what one may receive from a source outside one's control can't
be dealt with with the internal utility. IM(again, NSH :) )O, the
programming language developer shouldn't be the one making the value
judgment but leave it to the enduser to be a responsible coder. (Yes,
no, I don't much like ADA, either... :) ).

--

On 11/23/2011 9:04 AM, Bruno Luong wrote:
...

> Can we consider then copyfile also prevents a user from doing a stupid
> thing? It's even rectify a stupid naming previously made. In fact to me
> it's very smart, admittedly not documented.

It's too clever by far yet still not clever enough.

It's also dangerous in that it will silently overwrite an existing file. :(

While as noted elsewhere that it may be an unwise thing to do, if the OS
supports it, the utility ought at a minimum not do _the_wrong_thing_ (tm).

--

On 23 Nov, 19:32, dpb <n...@non.net> wrote:

> While as noted elsewhere that it may be an unwise thing to do, if the OS
> supports it, the utility ought at a minimum not do _the_wrong_thing_ (tm).

Keep in mind that you are talking about windows!

Windows can trace its ancestory to MS-DOS, which in turn,
apparently, was based on something that was called QD-DOS,
"quick'n dirty operating system".

Micros soft has a not at all glorious track records what
technical decisions are concerned. Anyone remember that
insane 640kb memory limit, with all the hard-wired stuff
located at memory addresses *above* what was made availabe
to applications. At some point I explicitly decided *not*
to pursue computer programming as a profession, because
at the time that meant "find ways to work around the
640kb limit in systems that had 2MB RAM."

MS might have held users hostage for a few decades now,
but that is *not* because of technical excellence!

Rune

On 11/23/2011 1:16 PM, Rune Allnor wrote:
> On 23 Nov, 19:32, dpb<n...@non.net> wrote:
>
>> While as noted elsewhere that it may be an unwise thing to do, if the OS
>> supports it, the utility ought at a minimum not do _the_wrong_thing_ (tm).
>
> Keep in mind that you are talking about windows!
...

Has no bearing on anything, really. It's the OS under which probably
 >80% of TMW customers run (WAG, no data but certainly sizable majority).

Whatever one thinks of it, it is what it is and to not implement on the
basis of some vendetta that feature a or b is bad so since I don't like
it I'm not going to let my users at it is not (I'll come back to it
again :) ) IMNSHO a distinctly wrongheaded way to go at it.

I'm sure there are features in every OS _somebody_ disagrees with.

--

On 11/23/2011 5:01 PM, dpb wrote:
> On 11/23/2011 1:16 PM, Rune Allnor wrote:
>> On 23 Nov, 19:32, dpb<n...@non.net> wrote:
>>
>>> While as noted elsewhere that it may be an unwise thing to do, if the OS
>>> supports it, the utility ought at a minimum not do _the_wrong_thing_
>>> (tm).
>>
>> Keep in mind that you are talking about windows!
> ....
>
> Has no bearing on anything, really. It's the OS under which probably
> >80% of TMW customers run (WAG, no data but certainly sizable majority).
>
> Whatever one thinks of it, it is what it is and to not implement on the
> basis of some vendetta that feature a or b is bad so since I don't like
> it I'm not going to let my users at it is not (I'll come back to it
> again :) ) IMNSHO a distinctly wrongheaded way to go at it.

That should, of course, have been _is_ ... wrongheaded rather than is not.

> I'm sure there are features in every OS _somebody_ disagrees with.
>

Also note the issue OP had that I commented to Bruno on about the result
being dangerous in possibly unintentionally overwriting an existing file
is _not_ the feature of Windows but the behavior of the implemented
Matlab copyfile() utility that silently "eats" the blank.

That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
the choices of a) implementing a file system that allows a leading
whitespace character in a filename and b) using that ability are.
"First, do no harm."

--

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <jaj21b$98r$1@newscl01ah.mathworks.com>...
> "Igor" wrote in message <jaiv79$s42$1@newscl01ah.mathworks.com>...
> >
> >
> > Explorer is trying to prevent a user from doing a stupid thing - it's right. Neither it would allow a trailing space.
>
> Can we consider then copyfile also prevents a user from doing a stupid thing?

The difference is - you CREATE a filename or you COPY a filename. If you create one - there's a set of limitations on a filename, you should handle them somehow.
If you're going to copy a file, you already got a "proper" filename, and you expect a resulting filename to be EXACTLY the same. Even if filename is '1+1=3' I don't want anybody to "fix" it.

If there's already a "good" filename , why change it anyhow?

(In fact, you still may run into path length limitation, but that's a documented limitation. )

dpb <none@non.net> wrote in message <jajcia$hba$1@speranza.aioe.org>...

> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names>

Thanks for the link!
I've just noted one of the messages there:
---------------------------------------------------------------------------------
Vista explorer removes leading spaces
Explorer of Windows Vista and Windows 7 RC removes leading spaces on file- and directory names when copying. If you happen to have a file "example.txt" and a " example.txt" (with leading space) in the same source directory, it will even try to write one over the other at the target directory of the copy operation.

Explorer of Windows XP preserves leading spaces on file- and directory names when copying.

marble65
6/26/2009
---------------------------------------------------------------------------------
Well, now we know, where this bug came from! Somehow, I'm not surprised... ;)
I've just reproduced this on my Win7 x64. I only tested 'xcopy' 'copy' and Total Commander copy-behavior before....

On 24 Nov, 16:18, dpb <n...@non.net> wrote:
> On 11/23/2011 5:01 PM, dpb wrote:
>
>
>
>
>
> > On 11/23/2011 1:16 PM, Rune Allnor wrote:
> >> On 23 Nov, 19:32, dpb<n...@non.net> wrote:
>
> >>> While as noted elsewhere that it may be an unwise thing to do, if the OS
> >>> supports it, the utility ought at a minimum not do _the_wrong_thing_
> >>> (tm).
>
> >> Keep in mind that you are talking about windows!
> > ....
>
> > Has no bearing on anything, really. It's the OS under which probably
> >  >80% of TMW customers run (WAG, no data but certainly sizable majority).

The de facto market share of 100% is certainly a reason
not toignore what MS do. However, they have repeatedly
and consistently over several decades made horrendeous
techncal decisions.

> > Whatever one thinks of it, it is what it is and to not implement on the
> > basis of some vendetta that feature a or b is bad so since I don't like
> > it I'm not going to let my users at it is not (I'll come back to it
> > again :) ) IMNSHO a distinctly wrongheaded way to go at it.
>
> That should, of course, have been _is_ ... wrongheaded rather than is not.
>
> > I'm sure there are features in every OS _somebody_ disagrees with.
>
> Also note the issue OP had that I commented to Bruno on about the result
> being dangerous in possibly unintentionally overwriting an existing file
> is _not_ the feature of Windows but the behavior of the implemented
> Matlab copyfile() utility that silently "eats" the blank.

That problem would not appear in the first place, if
characters with no visible or non-empty graphical
representation were disallowed in file names.

> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
> the choices of a) implementing a file system that allows a leading
> whitespace character in a filename and b) using that ability are.
> "First, do no harm."

That's a nice, idealistic intention I would expect in,
say, 15-year-old girls.

In practice actions have consequences. The best one can do
is to be aware of what the consequences of one's actions
(including allowing filenames to contain whitespaces)
and otherwise rely on competent, sane users to know what
they are doing.

If you want to use whitespaces in filenames, then you are
on your own. If you want to blame others, blame those
who allowed that to happen in the first place, not those
who were forced to trod along and stopped well short of
preventing stuff that require downight stupidity to occur.

Rune

On 24 Nov, 17:22, "Igor " <i...@mail.ru> wrote:

> If you're going to copy a file, you already got a "proper" filename, and you expect a resulting filename to be EXACTLY the same. Even if filename is '1+1=3' I don't want anybody to "fix" it.

I think you will have to accept such limitations.
OS writers will likely provide optional parameters
to their commands, along the lines of

ls -r

in UNIX. Filenames can not be allowed to start with
hyphens, as the OS in that case will not be able to
distinguish between a file or directory name, and a
set of parameters.

Parsing these kinds of comamnd lines is hard enough
even with strict rules in place. Letting all kinds
of variants loose is insane. And again, it is up to
the writers of the lowest level API to keep track
of all that and issue an error message or something
when users attempt bad stuff.

But when OS vendors don't, programmers are wise to
include their own safeguards against studid users.
At some poit users will try and open files with
names you previously allowed them to save. If you
allow users to save an un-parseable filename, you
will also get the blame when they can't open it.

I suppose it comes down to how stupid one assumes
one's users to be. As they say, it takes one to
know one...

Rune

On 11/24/2011 10:19 AM, Rune Allnor wrote:
...

>> Also note the issue OP had that I commented to Bruno on about the result
>> being dangerous in possibly unintentionally overwriting an existing file
>> is _not_ the feature of Windows but the behavior of the implemented
>> Matlab copyfile() utility that silently "eats" the blank.
>
> That problem would not appear in the first place, if
> characters with no visible or non-empty graphical
> representation were disallowed in file names.

True, but they are, like it or not.

>> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
>> the choices of a) implementing a file system that allows a leading
>> whitespace character in a filename and b) using that ability are.
>> "First, do no harm."
>
> That's a nice, idealistic intention I would expect in,
> say, 15-year-old girls.
>
> In practice actions have consequences. The best one can do
> is to be aware of what the consequences of one's actions
> (including allowing filenames to contain whitespaces)
> and otherwise rely on competent, sane users to know what
> they are doing.
 >
> If you want to use whitespaces in filenames, then you are
> on your own. If you want to blame others, blame those
> who allowed that to happen in the first place, not those
> who were forced to trod along and stopped well short of
> preventing stuff that require downight stupidity to occur.

And that's precisely the attitude I'd expect from a person who prefers
to place the root of all evil at the feet of MS. :)

Of course (and we've agreed) it's a lousy choice; no reason to keep
harping on it.

The point is that TMW made a decision to try to fix up the problem and
ended up making it worse by the implementation instead of better.

A competent, sane user should _NOT_ expect a silent error in something
that is (I'll say it again for clarity) while poor practice a legal
operation under the OS in question to actually cause damage
(particularly silently).

There is a simple fix if TMW thinks so strongly it's their position to
protect users from such--simply error on the bad file name and return
rather than do the fixup behind the user's back and pretend all is well.

--

On 24 Nov, 18:23, dpb <n...@non.net> wrote:
> On 11/24/2011 10:19 AM, Rune Allnor wrote:
> ...
>
> >> Also note the issue OP had that I commented to Bruno on about the result
> >> being dangerous in possibly unintentionally overwriting an existing file
> >> is _not_ the feature of Windows but the behavior of the implemented
> >> Matlab copyfile() utility that silently "eats" the blank.
>
> > That problem would not appear in the first place, if
> > characters with no visible or non-empty graphical
> > representation were disallowed in file names.
>
> True, but they are, like it or not.
>
>
>
>
>
>
>
> >> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
> >> the choices of a) implementing a file system that allows a leading
> >> whitespace character in a filename and b) using that ability are.
> >> "First, do no harm."
>
> > That's a nice, idealistic intention I would expect in,
> > say, 15-year-old girls.
>
> > In practice actions have consequences. The best one can do
> > is to be aware of what the consequences of one's actions
> > (including allowing filenames to contain whitespaces)
> > and otherwise rely on competent, sane users to know what
> > they are doing.
>
> > If you want to use whitespaces in filenames, then you are
> > on your own. If you want to blame others, blame those
> > who allowed that to happen in the first place, not those
> > who were forced to trod along and stopped well short of
> > preventing stuff that require downight stupidity to occur.
>
> And that's precisely the attitude I'd expect from a person who prefers
> to place the root of all evil at the feet of MS.  :)

Well, yes of course. If one designs, as MS seems to have tried,
to implement a system that even a moron can use, then one is
limited to achieve only what morons are capable of.

> Of course (and we've agreed) it's a lousy choice; no reason to keep
> harping on it.
>
> The point is that TMW made a decision to try to fix up the problem and
> ended up making it worse by the implementation instead of better.
>
> A competent, sane user should _NOT_ expect a silent error in something
> that is (I'll say it again for clarity) while poor practice a legal
> operation under the OS in question to actually cause damage
> (particularly silently).

A competent sane user will not use filenames with whitespaces.

> There is a simple fix if TMW thinks so strongly it's their position to
> protect users from such--simply error on the bad file name and return
> rather than do the fixup behind the user's back and pretend all is well.

In that case somebody will attack them along the lines of
'who the hell do you think you are, who loudly criticises
what MS have accepted?' Of two evils, the present one is
the lesser bad.

Rune

On 11/24/2011 10:22 AM, Igor wrote:
...
> dpb <none@non.net> wrote in message <jajcia$hba$1@speranza.aioe.org>...
>
>> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names>
>>
>
> Thanks for the link!
> I've just noted one of the messages there:
> ---------------------------------------------------------------------------------
>
> Vista explorer removes leading spaces
> Explorer of Windows Vista and Windows 7 RC removes leading spaces on
> file- and directory names when copying. If you happen to have a file
> "example.txt" and a " example.txt" (with leading space) in the same
> source directory, it will even try to write one over the other at the
> target directory of the copy operation.
>
> Explorer of Windows XP preserves leading spaces on file- and directory
> names when copying.
>
...

> Well, now we know, where this bug came from! Somehow, I'm not
> surprised... ;)
> I've just reproduced this on my Win7 x64. I only tested 'xcopy' 'copy'
> and Total Commander copy-behavior before....

Yeah, I noted that (alluded indirectly) earlier.

The upshot is the commandline tools don't but the GUI ones do (remove
the space that is) iiuc. I don't have a Win7 system to check behavior
directly.

I suppose it's possible TMW uses a link thru explorer for
implementation, maybe, instead of calling OS APIs or C RTL and that's
where it occurs? Who knows...

All in all, it still would have been better if MS had had the foresight
to disallow the form initially (but, unfortunately they didn't :( so
it's a pita to deal with).

--

On 11/24/2011 11:28 AM, Rune Allnor wrote:
...

> ... Of two evils, the present one is
> the lesser bad.
...

There we'll have to continue to disagree and cease the pointless
continuation...

--

"Igor" wrote in message <jalqvg$4rq$1@newscl01ah.mathworks.com>...
> ---------------------------------------------------------------------------------
> Explorer of Windows XP preserves leading spaces on file- and directory names when copying.

I've just tested the script from thread's 1st message - space is preserved....

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:a9913cf1-cf57-4ef6-9c21-003528011802@o9g2000vbc.googlegroups.com...
> On 24 Nov, 16:18, dpb <n...@non.net> wrote:
>> On 11/23/2011 5:01 PM, dpb wrote:
<stuff deleted>
>> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
>> the choices of a) implementing a file system that allows a leading
>> whitespace character in a filename and b) using that ability are.
>> "First, do no harm."
>
> That's a nice, idealistic intention I would expect in,
> say, 15-year-old girls.
>
<stuff deleted>
> Rune

What is it with girls? Pick on your own kind ;-)

--
Loren
http://blogs.mathworks.com/loren/
http://www.mathworks.com/matlabcentral/

On 29 Nov, 14:40, "Loren Shure" <loren.sh...@mathworks.com> wrote:
> "Rune Allnor" <all...@tele.ntnu.no> wrote in message
>
> news:a9913cf1-cf57-4ef6-9c21-003528011802@o9g2000vbc.googlegroups.com...
>
> > On 24 Nov, 16:18, dpb <n...@non.net> wrote:
> >> On 11/23/2011 5:01 PM, dpb wrote:
> <stuff deleted>
> >> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an idea
> >> the choices of a) implementing a file system that allows a leading
> >> whitespace character in a filename and b) using that ability are.
> >> "First, do no harm."
>
> > That's a nice, idealistic intention I would expect in,
> > say, 15-year-old girls.
>
> <stuff deleted>
> > Rune
>
> What is it with girls?   Pick on your own kind ;-)

Well, I get beaten a and bashed enough as it is...

In my experience, girls often are the best, most diciplined,
accurate and conciencious workers. But I have no idea how
they think about computers. With boys the question is
not *if* they like computer games, but *which* type of
computer game they prefer: First person shooters? Sports
managers? Strategy? Very few girls show much interst in
computer games at all, and if they do, chances are that
they play Sims. Very few boys find that game interesting.

I consider the different ways boys and girls relate
to computer games (and thus to computers) as a gender
difference as fundamental and profound as any other
such differences one can think of.

Rune

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:3476fee0-37ef-4e18-9835-170ef971e01a@h3g2000yqa.googlegroups.com...
> On 29 Nov, 14:40, "Loren Shure" <loren.sh...@mathworks.com> wrote:
>> "Rune Allnor" <all...@tele.ntnu.no> wrote in message
>>
>> news:a9913cf1-cf57-4ef6-9c21-003528011802@o9g2000vbc.googlegroups.com...
>>
>> > On 24 Nov, 16:18, dpb <n...@non.net> wrote:
>> >> On 11/23/2011 5:01 PM, dpb wrote:
>> <stuff deleted>
>> >> That behavior is _NOT_ _a_good_thing_ (tm) irregardless how bad an
>> >> idea
>> >> the choices of a) implementing a file system that allows a leading
>> >> whitespace character in a filename and b) using that ability are.
>> >> "First, do no harm."
>>
>> > That's a nice, idealistic intention I would expect in,
>> > say, 15-year-old girls.
>>
>> <stuff deleted>
>> > Rune
>>
>> What is it with girls? Pick on your own kind ;-)
>
> Well, I get beaten a and bashed enough as it is...
>
> In my experience, girls often are the best, most diciplined,
> accurate and conciencious workers. But I have no idea how
> they think about computers. With boys the question is
> not *if* they like computer games, but *which* type of
> computer game they prefer: First person shooters? Sports
> managers? Strategy? Very few girls show much interst in
> computer games at all, and if they do, chances are that
> they play Sims. Very few boys find that game interesting.
>
> I consider the different ways boys and girls relate
> to computer games (and thus to computers) as a gender
> difference as fundamental and profound as any other
> such differences one can think of.
>

My experience with girls does not match yours. Both I, and some teenagers I
know today are totally into computers and not just "girly" games. In fact,
the girls I know now are better programmers than their male counterparts.

--
Loren
http://blogs.mathworks.com/loren/
http://www.mathworks.com/matlabcentral/

On 23.11.11 02:25, Rune Allnor wrote:

> Don't blame TMW for not keeping matlab exactly
> in tune with windows. Instead, complain to microsoft
> for allowing leading whitespaces in filenames at all.

Microsoft in this instance just did what Unix had been doing for
decades. Not that actually *using* such file names has ever been a good
idea. “Fixing” the whole thing by removing spaces at either end of the
file name obviously makes things only worse, at least as soon as you
start trying to do non-interactive (aka scripted/programmed) work on files.


Christopher

On 6 Des, 14:02, Christopher Creutzig
<Christopher.Creut...@mathworks.com> wrote:
> On 23.11.11 02:25, Rune Allnor wrote:
>
> > Don't blame TMW for not keeping matlab exactly
> > in tune with windows. Instead, complain to microsoft
> > for allowing leading whitespaces in filenames at all.
>
> Microsoft in this instance just did what Unix had been doing for
> decades.

Using whitespaces in filenames?

Could you please provide references for such
stuff happening in the UNIX world?

Rune

On 06.12.11 20:51, Rune Allnor wrote:
> On 6 Des, 14:02, Christopher Creutzig

>> Microsoft in this instance just did what Unix had been doing for
>> decades.
>
> Using whitespaces in filenames?

Sure. (That a lot of programs and scripts don't handle this properly is
a different issue, of course, and no different on Windows, either. The
philosophies of working with such things on the command line is a bit
different, which goes back to the different designs as to who is
responsible for argument splitting, wildcard expansion etc.)

> Could you please provide references for such
> stuff happening in the UNIX world?

Primarily personal experience, of course, which is kind of hard to cite
as a reference. Don't tell me google is broken again. But, sure, here
you go:

http://cmgm.stanford.edu/classes/unix/filenames.html

http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words (see
“Note 1”)



Christopher

Rune Allnor <allnor@tele.ntnu.no> wrote in message <9bdec79c-66e1-4735-a837-ad81d230d224@t16g2000vba.googlegroups.com>...

> Could you please provide references for such
> stuff happening in the UNIX world?


Say, some svn client...

Suppose you've got a script for it, and it works OK.. Before it ran into matlab @-folder.
Of course, there's an easy workaround - to add one more @ sign at the end of a filename.
 
Still, this is only a workaround, just like using doublequotes is a workaround for paths with spaces...

On 7 Des, 08:42, Christopher Creutzig
<Christopher.Creut...@mathworks.com> wrote:
> On 06.12.11 20:51, Rune Allnor wrote:

> > Could you please provide references for such
> > stuff happening in the UNIX world?
>
> Primarily personal experience, of course, which is kind of hard to cite
> as a reference. Don't tell me google is broken again. But, sure, here
> you go:

That's kind of thing was unheard of at the time.
My experience was that whitespaces in filenames
was a total No-No, where M$ were the first to
do that kind of thing.

Of course, these days HP-UX, IRIX or SUN-Sparc
are impossible to come by, so no one can test
what actually worked at the time; 1995 or
thereabouts.

Rune