> Cc: "Luke Dunstan" <coder_infidel@...>,
> From: Keith MARSHALL <keith.marshall@...>
> Date: Fri, 6 Jan 2006 15:10:24 +0000
> Eli Zaretskii wrote, quoting Luke Dunstan:
> >> FWIW I agree that your comments were arrogant
> > Since when expressing an opinion that something is a bug counts as
> > arrogant?
> The arrogance lay not in the expression of the opinion per se, but in
> the manner of its expression; if you persistently indicate that your
> opinions are "not so humble" -- as you do -- that is, by definition,
> downright arrogance.
Ah, okay, so an opinion is either humble, if it's explicitly qualified
as such, or arrogant otherwise? Don't you think your standards are a
tad too touchy and unrealistic?
> > I'm not as ignorant as some people try to describe me.
> By "some people", I presume that you are referring to me. The name
> of Eli Zaretskii carries a considerable reputation in the free software
> world, and I have no doubt that you are actually an extremely accomplished
> software engineer; no, I do not believe that you actually are ignorant.
> However, you do display a certain ignorance of MSYS, and yet you still
> persist in arrogantly expressing so called expert opinion on it.
After working in the field of porting GNU and Unix software to DOS and
Windows for more than 15 years (and counting), I think I can offer
expert opinion even if I didn't have the chance of reading the MSYS
internals. One can judge design and user interface even without a
deep knowledge of the code, just by looking at the consequences. And
having myself bumped into similar issues more than twice, I think I
know something about possible alternative solutions, and merits and
demerits of each one of them.
But even if I did not know anything about these matters, I think you
should have embraced a layman's opinion. Naive newbies sometimes tell
us something that we professionals fail to see, I'm sure you know
that. I'm astonished that people here are requested to be experts in
the details before they can comment on the results.
> Given the apparently uninformed nature of your arrogantly expressed
> opinions on MSYS, you expose yourself to the potential criticism that
> you are a pompous ass, consequentially damaging your reputation; it
> is exposing yourself to such criticism, I would suggest, that might
> be construed as stupid.
Look, what I wrote was supposed to be a criticism of how MSYS resolved
the issues of running Posix software on MS-Windows. I assumed that,
as customary among professionals in general and in the Free Software
community in particular, criticism is accepted as aimed at improving
the quality of your work. I expected that MSYS maintainers will want
to ask what I suggest as alternative solutions to the underlying
issues,and might benefit from my suggestions. But if the MSYS
community can offer nothing in response except harsh, uncivilized
language and NIH-style defensiveness, then I'm sorry I've ever spoken,
because a community that does not embrace outside criticism does not
deserve the effort of reporting a bug!
> > And yet I think that this translation is a misfeature, because a
> > general-purpose code cannot possibly know what the user meant by "/c".
> While it may not be immediately obvious in the current context, when
> viewed in the full context of your earlier remarks on the same subject,
> this statement is so patently ridiculous, that it simply beggars belief.
> Of course the user's intent is perfectly clear, because he himself knows
> that "/c" refers to the MSYS mount point, where the Windows "C:" drive is
> attached to the file system, as it is represented in the POSIX-like model
> that MSYS uses at the command interpreter level. He also knows, because
> he read it in the README file he was shown, when he installed MSYS, that
> if he needs to pass a "/c" option flag to a native Windows application,
> then he must enter that, on the command line, in the form "//c". (Of
> course, there will be users who neglect to look at README files; to
> them, I offer no apology, for they are victims of their own folly).
That is an extremely narrow view, both of your audience and the area
of application of your tools. First, you assume that users always
read all the documentation, where in practice they expect things that
are obvious to them to ``just work''. Thus, failure to behave
according to user expectations is an annoyance, even if it is well
Second, you assume that the users write all commands themselves. In
practice, it is much more probable that the offending command came
from some script or Makefile whose author knew nothing about this MSYS
limitation, and in fact assumed that no development environment and no
ported utility will ever break something as basic as program
invocation by second-guessing the meaning of the command-line
arguments. The case of the NTEmacs build system, which I mentioned
earlier in this thread, is an excellent example: MSYS was the only
environment that broke the build, because no one could imagine that a
command-line argument will not be passed to a program in the same form
as it appeared in the Makefile.
And third, while it might be reasonable to assume that, in the context
of _file_names_ "/c" refers to a mount point of drive C:, no one said
that every command-line argument is always a file name. For example,
a Sed command line can quite legitimately say something like this:
sed -e /c/s/foo/bar/g
I think it's clear that, although this looks like a file name, it
really isn't, and treating it as a file name that can be converted to
C:\s\foo\bar will produce utterly unexpected results.
I could continue telling you why I think this /c treatment is not a
very good design. But since I will most probably get nothing in
response but more of ad hominem attacks, why should I even bother?