Opinion) Overuse of symbolic constants
Sandeep Sharma
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):
#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1
It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).
Any opinions?
--SS
Niels Dybdahl
I consider three important uses for defines or constants:
1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).
I do not think that the examples shown above fits into any of these usages.
Niels Dybdahl
Christopher Benson-Manica
(comp.lang.c only, I don't see clc++ caring much about this)
> #define DASH '-'
> #define SLASH '/'
> #define SINGLE_BYTE 1
I'm dealing with similar code, except that ours look like
#define Splat '*'
#define Andpersand '&'
#define Asterik '*'
Those are verbatim - yes, ampersand and asterisk are misspelled, and
the constants aren't capitalized. I make a point of not using these
at any time in the code that *I* write. And the author is my boss, so
I guess he's "distinguished" too :)
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Joona I Palaste
> In comp.lang.c Sandeep Sharma <sande...@yahoo.com> wrote:
> (comp.lang.c only, I don't see clc++ caring much about this)
>> #define DASH '-'
>> #define SLASH '/'
>> #define SINGLE_BYTE 1
> I'm dealing with similar code, except that ours look like
> #define Splat '*'
> #define Andpersand '&'
> #define Asterik '*'
> Those are verbatim - yes, ampersand and asterisk are misspelled, and
> the constants aren't capitalized. I make a point of not using these
> at any time in the code that *I* write. And the author is my boss, so
> I guess he's "distinguished" too :)
Your boss obviously hasn't read enough European comics. =)
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'So called' means: 'There is a long explanation for this, but I have no
time to explain it here.'"
- JIPsoft
- Kees van der Bent -
> I'm dealing with similar code, except that ours look like
>
> #define Splat '*'
> #define Andpersand '&'
> #define Asterik '*'
So why don't you:
#define SPLAT Splat
#define AMPERSAND Andpersand
#define ASTERISK Asterik
Cheers,
Kees
:-)
Fred L. Kleinschmidt
Sandeep Sharma wrote:
>
> Right from the time the first edition of K?R was released, the
I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:
#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 (206)544-5225
Darrell Grainger
I use macros for data that is subject to change or to make the code more
readable. Symbols are just as readable as words so I see no point in two
of the three examples.
However, the SLASH might have a place. I have seen code like:
#ifdef WINDOWS
#define SEPERATOR '\\'
#else
#define SEPERATOR '/'
#endif
Have you asked the distinguished collegue why the need for the macros? If
they have a good reason maybe a comment in the source code would be
helpful.
I'm guessing they are just blindly following something they were taught
without understanding why.
--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.pr...@whitehouse.gov
Martin Dickopp
> Sandeep Sharma wrote:
>>
>> Right from the time the first edition of K?R was released, the
>> advantages of using symbolic constants, as opposed to "magic numbers",
>> has been emphasized ---- and for good reason. I don't dispute that at
>> all. However, it gets on my nerves when people carry this practice
>> too far. Consider these examples (from the code written by a
>> distinguished colleague):
>>
>> #define DASH '-'
>> #define SLASH '/'
>> #define SINGLE_BYTE 1
>>
>> It is one thing to use symbolic constants with meaningful (and in some
>> cases, abstract) names, but methinks that use of symbolic constants in
>> this way is a complete waste. Let us take the first example. Either
>> the definition of DASH will never change (in which case it's usage is
>> superfluous) or the definition of DASH will change in the future (in
>> which case it will be completely misleading).
>>
>> Any opinions?
>
> I use the SLASH definition to distinguish the directory name separator
> for Unix vs. Windows:
>
> #ifdef WIN32
> #define SLASH '\\'
> #else
> #define SLASH '/'
> #endif
I find this misleading. I'd prefer
#ifdef WIN32
#define DIR_SEP '\\'
#else
#define DIR_SEP '/'
#endif
Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Dan Pop
>However, the SLASH might have a place. I have seen code like:
>
>#ifdef WINDOWS
>#define SEPERATOR '\\'
>#else
>#define SEPERATOR '/'
>#endif
It was probably written by someone ignoring both English and Windows.
In most contexts, Windows accepts the forward slash as path separator.
The only exception coming to mind is COMMAND.COM (newer command
interpreters are perfectly happy with Unix-style path specifications).
So, in a C context, it's only strings prepared to be passed to system()
that need the distinction. But such strings are typically affected by
much more important portability issues...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Jerry Coffin
I agree. To be useful, a symbolic name needs to be symbolic -- it
needs to symbolize something. These are roughly equivalent to
comments like:
a=b; /* assign b to a */
that only repeat what's already obvious. To be useful, the symbol
needs to add meaning that isn't obvious without it. A constrast would
be names like the following:
#define switch_char '-'
#define path_sep '/'
which really add meaning, as well as the flexibility of (for example)
allowing a path separator to be changed from '/' to '\\' to ':' as
appropriate.
Later,
Jerry.
--
The universe is a figment of its own imagination.
Old Wolf
> > Consider these examples (from the code written by a
> > distinguished colleague):
> >
> > #define DASH '-'
> > #define SLASH '/'
> > #define SINGLE_BYTE 1
> >
> > It is one thing to use symbolic constants with meaningful (and in some
> > cases, abstract) names, but methinks that use of symbolic constants in
> > this way is a complete waste. Let us take the first example. Either
> > the definition of DASH will never change (in which case it's usage is
> > superfluous) or the definition of DASH will change in the future (in
> > which case it will be completely misleading).
>
> I consider three important uses for defines or constants:
>
> 1. For values that are subject to change.
> 2. To distinguish a certain usage of a value from other usages, so that
> searches are more efficient.
> 3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).
>
> I do not think that the examples shown above fits into any of these usages.
From a C99 implementation near you:
#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=
This is interesting because a co-developer of mine has a standard include
file (predating C99 by a long way) which has:
#define AND &&
#define OR ||
#define NOT !
So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.
CBFalconer
>
... snip ...
>
> From a C99 implementation near you:
>
> #define and &&
> #define and_eq &=
> #define bitand &
> #define bitor |
> #define compl ~
> #define not !
> #define not_eq !=
> #define or ||
> #define or_eq |=
> #define xor ^
> #define xor_eq ^=
This has been in C90 since about 1995. #include <iso646.h>
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dan Pop
>Old Wolf wrote:
>>
>... snip ...
>>
>> From a C99 implementation near you:
>>
>> #define and &&
>> #define and_eq &=
>> #define bitand &
>> #define bitor |
>> #define compl ~
>> #define not !
>> #define not_eq !=
>> #define or ||
>> #define or_eq |=
>> #define xor ^
>> #define xor_eq ^=
>
>This has been in C90 since about 1995. #include <iso646.h>
More correctly, this has been in C94 since about 1995. I don't know
if C94 implementations were popular enough to be worth messing with
<iso646.h> if you cared about portable programming.
Kenneth Brody
[...]
> I use the SLASH definition to distinguish the directory name separator
> for Unix vs. Windows:
>
> #ifdef WIN32
> #define SLASH '\\'
> #else
> #define SLASH '/'
> #endif
Why bother? Unless you are building a filename to pass to system(),
and that specific command doesn't like '/', the above is superfluous.
(That, and misleading by using the name SLASH rather than something
like PATH_SET.)
All versions of MS-Windows, and all versions of MS-DOS back to 2.0
when they first allowed subdirectories can use the following:
FILE *f = fopen("/foo/bar/foobar.txt","r");
And even system() works if you're not exectuting a brain-dead command.
For example:
system("vi /foo/bar/foobar.txt");
It's amazing how many code samples I see that have code to build path
names differently under DOS/Windows, when these are used strictly for
internal purposes and not for system commands. And it's amazing how
many people are shocked when asked "since when?" and I tell them
"since always".
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Jakob Bieling
news:843a4f78.04042...@posting.google.com...
The point was not primarily readabilty, but rather to enable people to
use those operators if their keyboard either did not support some/all of
those characters, or if it was unconviniently difficult to type them.
regards
--
jb
(replace y with x if you want to reply by e-mail)
Michael Wojcik
In article <c667e8$qok$3...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
> In <Pine.GSO.4.58.04...@drj.pf> dar...@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
>
> >However, the SLASH might have a place. I have seen code like:
> >
> >#ifdef WINDOWS
> >#define SEPERATOR '\\'
> >#else
> >#define SEPERATOR '/'
> >#endif
>
> It was probably written by someone ignoring both English and Windows.
>
> In most contexts, Windows accepts the forward slash as path separator.
Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro; and when
parsing paths, you need to handle both slash and backslash, so the
macro won't help. It's doubly wrong.
As is often the case, attempting to hide platform-dependent code here
just produces a solution that's less obviously broken.
--
Michael Wojcik michael...@microfocus.com
Therefore, it is possible to enjoy further by using under the
Netscape 2.0. However, Netscape will hangup at sometimes. You
should give it up. -- roro
Keith Thompson
> "Fred L. Kleinschmidt" wrote:
> [...]
> > I use the SLASH definition to distinguish the directory name separator
> > for Unix vs. Windows:
> >
> > #ifdef WIN32
> > #define SLASH '\\'
> > #else
> > #define SLASH '/'
> > #endif
>
> Why bother? Unless you are building a filename to pass to system(),
> and that specific command doesn't like '/', the above is superfluous.
> (That, and misleading by using the name SLASH rather than something
> like PATH_SET.)
>
> All versions of MS-Windows, and all versions of MS-DOS back to 2.0
> when they first allowed subdirectories can use the following:
>
> FILE *f = fopen("/foo/bar/foobar.txt","r");
>
> And even system() works if you're not exectuting a brain-dead command.
> For example:
>
> system("vi /foo/bar/foobar.txt");
Disclaimer: I don't write programs for Windows (except under Cygwin,
but that doesn't count in this context.)
If a file name is going to be displayed to a Windows end user, the
user is likely to be confused if the path name contains '/' characters
rather than '\' characters. Confusing users is seldom a good idea.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Joe Wright
typically done by newbies at play. Have you ever seen any code by a
professional programmer (someone who gets paid for it) using this
kind of stuff? I have not.
--
Joe Wright mailto:joeww...@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nick Landsberg
> Jakob Bieling wrote:
>
>> "Old Wolf" <old...@inspire.net.nz> wrote in message
>> news:843a4f78.04042...@posting.google.com...
>>
>>> "Niels Dybdahl" <n...@fjern.detteesko-graphics.com> wrote:
>>>
>>>>> Consider these examples (from the code written by a
>>>>> distinguished colleague):
>>>>>
>>>>> #define DASH '-'
>>>>> #define SLASH '/'
>>>>> #define SINGLE_BYTE 1
>>>>>
[SNIP]
>>
>>> From a C99 implementation near you:
>>>
>>> #define and &&
>>> #define and_eq &=
>>> #define bitand &
>>> #define bitor |
>>> #define compl ~
>>> #define not !
>>> #define not_eq !=
>>> #define or ||
>>> #define or_eq |=
>>> #define xor ^
>>> #define xor_eq ^=
>>>
[SNIP]
>>
>>
>>
>> The point was not primarily readabilty, but rather to enable
>> people to
>> use those operators if their keyboard either did not support some/all of
>> those characters, or if it was unconviniently difficult to type them.
>>
> I suppose not. This business of abusing the preprocessor is typically
> done by newbies at play. Have you ever seen any code by a professional
> programmer (someone who gets paid for it) using this kind of stuff? I
> have not.
>
As a matter of fact, the first time I saw code for what was
to become the Bourne Shell (circa 1982), it was written exactly like
that except all the #defines were in CAPS.
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Stephen Sprunk
news:4087BAA2...@spamcop.net...
> All versions of MS-Windows, and all versions of MS-DOS back to 2.0
> when they first allowed subdirectories can use the following:
>
> FILE *f = fopen("/foo/bar/foobar.txt","r");
>
> And even system() works if you're not exectuting a brain-dead command.
> For example:
>
> system("vi /foo/bar/foobar.txt");
>
> It's amazing how many code samples I see that have code to build path
> names differently under DOS/Windows, when these are used strictly for
> internal purposes and not for system commands. And it's amazing how
> many people are shocked when asked "since when?" and I tell them
> "since always".
This was true even for the DOS CLI prior to 5.0 when MS appropriated the
forward slash for command options instead of following unix's dash
convention. While a forward slash may work in most API calls and many apps
today, that doesn't mean MS will continue to support it tomorrow, so using a
backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
source.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Joe Wright
seen it too and just forgot. Let me ask it another way..
Assuming you are a professional programmer, would you use these
#defines? If you were a teacher, would you recommend them to your
students?
if (A and B or C and D) {} doesn't look like C to me.
Nick Landsberg
You're right, Joe... it don't look like C and it don't
smell like C and it don't taste like C. (Pardons
for the bad grammar but is was to make a point.)
The example *was* about preprocessor abuse and by
a respected developer within the company. Unfortunately,
no one could easily debug the code since we could not
read it as "C". (or easily add functionality to it
since we weren't sure of just about anything at that
point.)
Personally I wouldn't use them.
If I *were* a teacher of C, I would deduct points for
"excessive cuteness" if someone came up with them
(unless it were a quiz on how to abuse the preprocessor P)
Jakob Bieling
news:q5OdnebNd-B...@comcast.com...
> >>#define AND &&
> >>#define OR ||
> >>#define NOT !
> >>So I guess there is a fourth category, which the OP's definitions might
> >>fall into: improving readability.
> > The point was not primarily readabilty, but rather to enable people
to
> > use those operators if their keyboard either did not support some/all of
> > those characters, or if it was unconviniently difficult to type them.
> I suppose not. This business of abusing the preprocessor is
> typically done by newbies at play. Have you ever seen any code by a
> professional programmer (someone who gets paid for it) using this
> kind of stuff? I have not.
Me neither, as I have not worked with people who use a keyboard that
does not allow easy access to those characters, and I am sure you have not
either. I did not say that it is commmon practice nor that it should be
encouraged in any way. All I am saying is, that those things primarily exist
to enable people who do not have easy access to those characters, to use
them anyway.
Christian Bau
Joe Wright <joeww...@comcast.net> wrote:
> Assuming you are a professional programmer, would you use these
> #defines? If you were a teacher, would you recommend them to your
> students?
>
> if (A and B or C and D) {} doesn't look like C to me.
If you are a professional programmer, and you intend to use them, please
use them in your probational period in a new job, so the company can get
rid of you quickly and at minimal cost.
If I saw this in a code review, I wouldn't know whether to laugh or to
cry. If you checked in this kind of stuff without a code review, you
would get killed.
Peter Koch Larsen
Apart from the fact that using the preprocessor in this context is
horrible, the above makes sense if the code could eventually be ported
to unicode.
In this case the code would look something like:
stdchar const dash(CHAR_T('-'));
where CHART would be a preprocesser define:
#if defined(WIDE_CHAR_USE)
# define CHAR_T(_x) L#x
#else
# define CHAR_T(_x) x
#endif
Regards
Peter
Richard Bos
> In article <c667e8$qok$3...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
> > In <Pine.GSO.4.58.04...@drj.pf> dar...@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
> >
> > >However, the SLASH might have a place. I have seen code like:
> > >
> > >#ifdef WINDOWS
> > >#define SEPERATOR '\\'
> > >#else
> > >#define SEPERATOR '/'
> > >#endif
> >
> > It was probably written by someone ignoring both English and Windows.
> >
> > In most contexts, Windows accepts the forward slash as path separator.
>
> Which means that in Windows, you can generally use the forward slash
> when generating paths, so there's no need for the macro;
You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.
Richard
[1] Read: Gates.
Kenneth Brody
> > It's amazing how many code samples I see that have code to build path
> > names differently under DOS/Windows, when these are used strictly for
> > internal purposes and not for system commands. And it's amazing how
> > many people are shocked when asked "since when?" and I tell them
> > "since always".
>
> This was true even for the DOS CLI prior to 5.0 when MS appropriated the
> forward slash for command options instead of following unix's dash
> convention.
Well "since always" includes "prior to 5.0". ;-)
The problem goes all the way back to MS-DOS 1.0 using slashes for command-
line flags. Then, when 2.0 allowed subdirectories, they were stuck.
> While a forward slash may work in most API calls and many apps
> today, that doesn't mean MS will continue to support it tomorrow, so using a
> backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
> source.
I don't think that even MS has the balls to break that compatibility.
Joona I Palaste
on comp.lang.c:
> Stephen Sprunk wrote:
>> While a forward slash may work in most API calls and many apps
>> today, that doesn't mean MS will continue to support it tomorrow, so using a
>> backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
>> source.
> I don't think that even MS has the balls to break that compatibility.
They're MS. They'd rather see UNIX adopt \ as a directory separator.
Erm, wait, scratch that. They'd rather not see UNIX at all.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
Dan Pop
In portable code, the file names are specified by the user. If the user
gets confused by his own input, there is very little the programmer can
do...
Dan Pop
The good question is whether such people do exist. 20 years ago, they
did, but back then there was no <iso646.h>...
Dan Pop
>As a matter of fact, the first time I saw code for what was
>to become the Bourne Shell (circa 1982), it was written exactly like
>that except all the #defines were in CAPS.
The Bourne Shell is older than that (it was the shell of Unix V7, released
at about the same time as K&R1) and it got these macros (and others, a lot
uglier, to hide the C's execution control syntax) by including "algol.h".
The result was something no one ever wanted to maintain...
Dan Pop
>"Kenneth Brody" <kenb...@spamcop.net> wrote in message
>news:4087BAA2...@spamcop.net...
>> All versions of MS-Windows, and all versions of MS-DOS back to 2.0
>> when they first allowed subdirectories can use the following:
>>
>> FILE *f = fopen("/foo/bar/foobar.txt","r");
>>
>> And even system() works if you're not exectuting a brain-dead command.
>> For example:
>>
>> system("vi /foo/bar/foobar.txt");
>>
>> It's amazing how many code samples I see that have code to build path
>> names differently under DOS/Windows, when these are used strictly for
>> internal purposes and not for system commands. And it's amazing how
>> many people are shocked when asked "since when?" and I tell them
>> "since always".
>
>This was true even for the DOS CLI prior to 5.0 when MS appropriated the
>forward slash for command options instead of following unix's dash
>convention. While a forward slash may work in most API calls and many apps
>today, that doesn't mean MS will continue to support it tomorrow, so using a
>backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
>source.
As far as I know, ever since MSDOS 2.0, MS OSs used / internally and \
only in the user interface. It's a bit late for them to change...
Jakob Bieling
news:c6bi40$28k$5...@sunnews.cern.ch...
> >encouraged in any way. All I am saying is, that those things primarily
exist
> >to enable people who do not have easy access to those characters, to use
> >them anyway.
>
> The good question is whether such people do exist. 20 years ago, they
> did, but back then there was no <iso646.h>...
Good point .. and as I have no knowledge about any other type of
keyboard other than the German and the US layout, I cannot tell if there is
not some kind of keyboard that does not have those keys. Maybe for a
different system, other than IBM compatible, that has a completely different
keyboard, but still has a C++ compiler .. just speculating, tho. But if it
does exist somewhere out there, those guys and girls using it sure will be
glad to have iso464.h ;)
Keith Thompson
If the file names are specified by the user, the issue doesn't arise;
re-displaying whatever the user provided is entirely reasonable.
(Mapping the user's input to a more canonical form may or may not be
reasonable; it depends on the circumstances.)
Obviously we're talking about non-portable code with file names
provided or constructed by the program. In that context, it makes
sense to use something that's not going to confuse the user; under
Windows, that means using '\\' rather than '/' as the path separator.
It may not matter if the program never shows any file names to the
user, but a future version of the program may do so even if the
current one doesn't -- or a future version may try to pass a file name
to the command interpreter. (Or there might be some other obscure
circumstances in Windows where '/' and '\\' are not equivalent as path
separators; I'm not assuming there are, but I wouldn't bet against
it.)
Dan Pop
>Obviously we're talking about non-portable code with file names
>provided or constructed by the program.
In this case, even the file name construction algorithm is platform
specific, so there is nothing to be achieved by hiding the path separator
behind a macro (the topic of this thread). Use the native convention
on each platform.
Michael Wojcik
In article <c6b9ts$moh$2...@oravannahka.helsinki.fi>, Joona I Palaste <pal...@cc.helsinki.fi> writes:
> Kenneth Brody <kenb...@spamcop.net> scribbled the following
> on comp.lang.c:
> > Stephen Sprunk wrote:
> >> While a forward slash may work in most API calls and many apps
> >> today, that doesn't mean MS will continue to support it tomorrow, so using a
> >> backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
> >> source.
>
> > I don't think that even MS has the balls to break that compatibility.
>
> They're MS. They'd rather see UNIX adopt \ as a directory separator.
OK, I enjoy bashing MS and Windows as much as the next fellow, but
seriously, this is never going to change. It'd break compatibility
all over the place. MS is still providing sufficient compatibility
to run many ancient DOS programs; they're not going to screw with
something this basic.
--
Michael Wojcik michael...@microfocus.com
It's like being shot at in an airport with all those guys running
around throwing hand grenades. Certain people function better with
hand grenades coming from all sides than other people do when the
hand grenades are only coming from inside out.
-- Dick Selcer, coach of the Cinci Bengals
Michael Wojcik
In article <4088dfdb....@news.individual.net>, r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
> mwo...@newsguy.com (Michael Wojcik) wrote:
>
> > when generating paths, so there's no need for the macro;
>
> You both forget something. Windows _functions_ may be able to understand
> forward slashes; but Windows _users_ are, in most cases, incapable of
> comprehending that the backslash is not a god[1]-given holy marking.
> Ditto, but less so, under Unix. Thus, for human-readable output, you
> must use the system-sanctified species of slash.
I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts. I assume I am not the only Windows
user who does. Yet I have never heard of this confusing a single
user.
I suspect this is just idle luser bashing. Anyone care to provide
any evidence whatsoever that presenting a pathname with slashes to
a Windows user causes difficulty?
--
Michael Wojcik michael...@microfocus.com
Any average educated person can turn out competent verse. -- W. H. Auden
Michael Wojcik
In article <c6bi40$28k$5...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
> In <c6a8vm$7co$01$1...@news.t-online.com> "Jakob Bieling" <net...@gmy.net> writes:
>
> >"Joe Wright" <joeww...@comcast.net> wrote in message
> >news:q5OdnebNd-B...@comcast.com...
> >
> >to
> >> > use those operators if their keyboard either did not support some/all of
> >> > those characters, or if it was unconviniently difficult to type them.
> >
> >> I suppose not. This business of abusing the preprocessor is
> >> typically done by newbies at play. Have you ever seen any code by a
> >> professional programmer (someone who gets paid for it) using this
> >> kind of stuff? I have not.
> >
> > Me neither, as I have not worked with people who use a keyboard that
> >does not allow easy access to those characters, and I am sure you have not
> >either.
>
I assure you, we exist. As recently as 1998 I was writing C using a
keyboard (attached to an IBM 5250 terminal) that did not have square
brackets. I didn't use iso646.h, because long before 1994 we had
programmed the terminals to insert square-bracket characters as
terminal macros (a two-keystroke operation). The macros replaced a
four-key sequence that required entering the hex codes for the square
brackets in the current EBCDIC code page - they're not part of the
base EBCDIC code set - and remembering what those hex codes were in
the first place.
--
Michael Wojcik michael...@microfocus.com
Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net
Kenneth Brody
[...]
> > You both forget something. Windows _functions_ may be able to understand
> > forward slashes; but Windows _users_ are, in most cases, incapable of
> > comprehending that the backslash is not a god[1]-given holy marking.
> > Ditto, but less so, under Unix. Thus, for human-readable output, you
> > must use the system-sanctified species of slash.
>
> I don't believe this. I see pathnames in Windows software every day
> that use slashes, or a mix of slashes and backslashes, for path
> separators in various contexts. I assume I am not the only Windows
> user who does. Yet I have never heard of this confusing a single
> user.
>
> I suspect this is just idle luser bashing. Anyone care to provide
> any evidence whatsoever that presenting a pathname with slashes to
> a Windows user causes difficulty?
<raising_hand>
Over here!
Well, not exactly "causing difficulty", but over the years our tech
support people have gotten reports about errors which displayed a
filename using forward slashes, wondering if that was the cause of
the problem.
</raising_hand>
Joona I Palaste
> In article <4088dfdb....@news.individual.net>, r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
>> mwo...@newsguy.com (Michael Wojcik) wrote:
>> > Which means that in Windows, you can generally use the forward slash
>> > when generating paths, so there's no need for the macro;
>>
>> You both forget something. Windows _functions_ may be able to understand
>> forward slashes; but Windows _users_ are, in most cases, incapable of
>> comprehending that the backslash is not a god[1]-given holy marking.
>> Ditto, but less so, under Unix. Thus, for human-readable output, you
>> must use the system-sanctified species of slash.
> I don't believe this. I see pathnames in Windows software every day
> that use slashes, or a mix of slashes and backslashes, for path
> separators in various contexts. I assume I am not the only Windows
> user who does. Yet I have never heard of this confusing a single
> user.
> I suspect this is just idle luser bashing. Anyone care to provide
> any evidence whatsoever that presenting a pathname with slashes to
> a Windows user causes difficulty?
This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames. Already we're seeing URLs written as
http:\\www.something.com\something.html, and I've even seen Usenet
article titles such as "Input \ output question". Sooner or later
greengrocers will start writing "Potatoes in 1\2 kg bags" in actual
pen-and-paper.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
Keith Thompson
> In article <4088dfdb....@news.individual.net>,
> r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
> > mwo...@newsguy.com (Michael Wojcik) wrote:
> >
> > > Which means that in Windows, you can generally use the forward slash
> > > when generating paths, so there's no need for the macro;
> >
> > You both forget something. Windows _functions_ may be able to understand
> > forward slashes; but Windows _users_ are, in most cases, incapable of
> > comprehending that the backslash is not a god[1]-given holy marking.
> > Ditto, but less so, under Unix. Thus, for human-readable output, you
> > must use the system-sanctified species of slash.
>
> I don't believe this. I see pathnames in Windows software every day
> that use slashes, or a mix of slashes and backslashes, for path
> separators in various contexts. I assume I am not the only Windows
> user who does. Yet I have never heard of this confusing a single
> user.
>
> I suspect this is just idle luser bashing. Anyone care to provide
> any evidence whatsoever that presenting a pathname with slashes to
> a Windows user causes difficulty?
Do you see slashes in the source code for Windows software, or do you
see it actually displayed when the program runs?
I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup. Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user, and I've never seen any mention of this feature
in Windows documentation. At least one Windows application I use
rejects a path name with '/' characters as invalid, but accepts the
equivalent path name with '\' characters (I suppose that's a bug in
that particular application).
I am a Windows user, but I'm not a Windows programmer. I haven't seen
very much source code intended to run under Windows, and I don't think
I've ever seen any such code that uses a '/' separator.
I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.
Allin Cottrell
>>I suspect this is just idle luser bashing. Anyone care to provide
>>any evidence whatsoever that presenting a pathname with slashes to
>>a Windows user causes difficulty?
In my experience (teaching university students), presenting _any_
sort of pathname to Windows users causes difficulty. Their ability
to comprehend anything but point-and-click has atrophied to the
point of disappearance.
> This is actually a bit off the topic, but this backslash thing has led
> to people thinking that the backslash (\) should be used *everywhere*,
> not just in file pathnames.
Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.
Allin Cottrell
Joe Wright
Most computer users know nothing at all about computers, what they
are, where they are or even whether they are currently using one or
more of them. What's your point?
Just curious, what do you teach at university?
We do not and should not expect anything at all from computer users
except that they use computers. They are our market. Bless them.
Allin Cottrell
>> Most computer users don't know what "backslash" means. There's about
>> an even chance they'll type "/" or "\" if asked to type a backslash.
> Most computer users know nothing at all about computers, what they are,
> where they are or even whether they are currently using one or more of
> them. What's your point?
My point, following from the discussion of '/' versus '\' in Windows
pathnames, is that the it's moot, because pathnames are simply not
something Windows users conjure with. (Of course I'm not talking
about programmers, but I am talking about reasonably intelligent people
who use a computer every working day.)
> Just curious, what do you teach at university?
Economics. When I teach econometrics (economic statistics), the full
effects of point-and-click-ism hit me in the face (i.e. almost total
inability to do anything that involves typing a command of any sort).
Allin Cottrell
Richard Bos
> Michael Wojcik <mwo...@newsguy.com> scribbled the following:
> > In article <4088dfdb....@news.individual.net>, r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
> >> mwo...@newsguy.com (Michael Wojcik) wrote:
> >> > Which means that in Windows, you can generally use the forward slash
> >> > when generating paths, so there's no need for the macro;
> >>
> >> You both forget something. Windows _functions_ may be able to understand
> >> forward slashes; but Windows _users_ are, in most cases, incapable of
> >> comprehending that the backslash is not a god[1]-given holy marking.
> >> Ditto, but less so, under Unix. Thus, for human-readable output, you
> >> must use the system-sanctified species of slash.
>
> > I don't believe this. I see pathnames in Windows software every day
> > that use slashes, or a mix of slashes and backslashes, for path
> > separators in various contexts.
Which software? I don't think I've ever seen something like that except,
perhaps, in GNUed software.
> > I assume I am not the only Windows user who does. Yet I have never
> > heard of this confusing a single user.
I have. Personal experience, and I took no notes, so that's no evidence
to anyone but me.
> Sooner or later greengrocers will start writing "Potatoes in 1\2 kg bags"
Inconceivable. Unless you mean "Potato's in 1\2 kg bag's".
Richard
Dan Pop
>In article <c6bi40$28k$5...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
>> In <c6a8vm$7co$01$1...@news.t-online.com> "Jakob Bieling" <net...@gmy.net> writes:
>>
>> >"Joe Wright" <joeww...@comcast.net> wrote in message
>> >news:q5OdnebNd-B...@comcast.com...
>> >
>> >> > The point was not primarily readabilty, but rather to enable people
>> >to
>> >> > use those operators if their keyboard either did not support some/all of
>> >> > those characters, or if it was unconviniently difficult to type them.
>> >
>> >> I suppose not. This business of abusing the preprocessor is
>> >> typically done by newbies at play. Have you ever seen any code by a
>> >> professional programmer (someone who gets paid for it) using this
>> >> kind of stuff? I have not.
>> >
>> > Me neither, as I have not worked with people who use a keyboard that
>> >does not allow easy access to those characters, and I am sure you have not
>> >either.
>>
>> The good question is whether such people do exist.
>
>I assure you, we exist. As recently as 1998 I was writing C using a
>keyboard (attached to an IBM 5250 terminal) that did not have square
>brackets. I didn't use iso646.h, because long before 1994 we had
>programmed the terminals to insert square-bracket characters as
>terminal macros (a two-keystroke operation).
That's the point. C has been available on IBM mainframes for almost 30
years and the people using it didn't wait for C89's trigraphs or C95's
digraphs and iso646.h to solve their terminal-related problems. All this
nonsense was due to one Scandinavian country ISO representatives insisting
on C providing a solution to a no longer existing problem (7-bit ASCII
derived character sets that replaced $, # and certain punctuation
characters by other characters).
Michael Wojcik
In article <ln65bm5...@nuthaus.mib.org>, Keith Thompson <ks...@mib.org> writes:
> mwo...@newsguy.com (Michael Wojcik) writes:
> >
> > I don't believe this. I see pathnames in Windows software every day
> > that use slashes, or a mix of slashes and backslashes, for path
> > separators in various contexts. I assume I am not the only Windows
> > user who does. Yet I have never heard of this confusing a single
> > user.
> >
> > I suspect this is just idle luser bashing. Anyone care to provide
> > any evidence whatsoever that presenting a pathname with slashes to
> > a Windows user causes difficulty?
>
> Do you see slashes in the source code for Windows software, or do you
> see it actually displayed when the program runs?
Both. This is particularly true with console-mode software, but it's
frequently true of GUI-mode as well.
> I happen to know that Windows accepts '/' as a path separator, but
> only because it's been mentioned in this newsgroup.
And you believe this is generally true of Windows users because?
> Most Windows
> programs avoid using '/' as a path separator, at least in paths
> displayed to the user
And your evidence for this is what?
> At least one Windows application I use
> rejects a path name with '/' characters as invalid, but accepts the
> equivalent path name with '\' characters (I suppose that's a bug in
> that particular application).
Yes, it is. For example, OpenFile() in Windows 3.1 had this problem,
and MS considered it a bug; see MS KB article Q111588.
> I am a Windows user, but I'm not a Windows programmer. I haven't seen
> very much source code intended to run under Windows, and I don't think
> I've ever seen any such code that uses a '/' separator.
Which tells us pretty much nothing.
> I'm probably more conscious of these issues than the vast majority of
> Windows users, and I'm only peripherally aware that '/' is a valid
> path separator.
It's pretty much utterly beside the point whether the average Windows
user knows that forward slash can be used as a path separator. The
question is whether said user will be confused upon encountering a
forward slash in a path. I don't believe so, and I've seen no
evidence offered to the contrary.
In fact, from what I've seen, Windows users show significant facility
at compensating for all sorts of potentially confusing UI elements.
Windows is full of them, after all.
--
Michael Wojcik michael...@microfocus.com
She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster
Keith Thompson
> In article <ln65bm5...@nuthaus.mib.org>, Keith Thompson
> <ks...@mib.org> writes:
> > I happen to know that Windows accepts '/' as a path separator, but
> > only because it's been mentioned in this newsgroup.
>
> And you believe this is generally true of Windows users because?
I'm guessing. No, I don't think that most Windows users read this
newsgroup, but I'm guessing, based on my own experience, that most
Windows users aren't aware that '/' is a valid path separator.
(Probably a lot of Windows users aren't aware that '\' is a valid path
separator.)
> > Most Windows
> > programs avoid using '/' as a path separator, at least in paths
> > displayed to the user
>
> And your evidence for this is what?
I've never seen a Windows program (excluding Cygwin and other Unix
emulation layers) display a directory path using '/' as a path
separator, except perhaps when it had been entered by the user. This
is, of course, anecdotal evidence, not proof.
[...]
> > I'm probably more conscious of these issues than the vast majority of
> > Windows users, and I'm only peripherally aware that '/' is a valid
> > path separator.
>
> It's pretty much utterly beside the point whether the average Windows
> user knows that forward slash can be used as a path separator. The
> question is whether said user will be confused upon encountering a
> forward slash in a path. I don't believe so, and I've seen no
> evidence offered to the contrary.
I think others have presented such evidence in this thread.
In any case, this discussion is off topic and not of much concern to
me personally. I have nothing to offer but anecdotal evidence.
marcus hall
Kenneth Brody <kenb...@spamcop.net> wrote:
>Stephen Sprunk wrote:
>The problem goes all the way back to MS-DOS 1.0 using slashes for command-
>line flags. Then, when 2.0 allowed subdirectories, they were stuck.
Come on, be fair.. The problem started before MS-DOS, since CP/M used
'/' for options before MS-DOS even existed. And CP/M got it from various
DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
the idea, or if they got it from somewhere previous, but by now we'er
talking about earlier then Unix V6, so DEC can hardly be faulted for not
following "the one true way".
Marcus Hall
mar...@tuells.org
Michael Wojcik
In article <lnhdv52...@nuthaus.mib.org>, Keith Thompson <ks...@mib.org> writes:
> mwo...@newsguy.com (Michael Wojcik) writes:
> >
> > It's pretty much utterly beside the point whether the average Windows
> > user knows that forward slash can be used as a path separator. The
> > question is whether said user will be confused upon encountering a
> > forward slash in a path. I don't believe so, and I've seen no
> > evidence offered to the contrary.
>
> I think others have presented such evidence in this thread.
Yes, and more of it than I expected. I yield on this one. While
I try not to underestimate users, I appear to have erred in the
opposite direction in this case.
> In any case, this discussion is off topic and not of much concern to
> me personally.
Agreed.
--
Michael Wojcik michael...@microfocus.com
You brung in them two expert birdwatchers ... sayin' it was to keep us from
makin' dern fools of ourselfs ... whereas it's the inherent right of all to
make dern fools of theirselfs ... it ain't a right held by you official types
alone. -- Walt Kelly
Michael Wojcik
In article <c6lkrd$mo1$4...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
> In <c6jj9...@news1.newsguy.com> mwo...@newsguy.com (Michael Wojcik) writes:
> >In article <c6bi40$28k$5...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
> >> In <c6a8vm$7co$01$1...@news.t-online.com> "Jakob Bieling" <net...@gmy.net> writes:
> >>
> >> > Me neither, as I have not worked with people who use a keyboard that
> >> >does not allow easy access to those characters, and I am sure you have not
> >> >either.
> >>
> >> The good question is whether such people do exist.
> >
> >I assure you, we exist.
>
> years and the people using it didn't wait for C89's trigraphs or C95's
> digraphs and iso646.h to solve their terminal-related problems.
Sure, but I was responding to Jakob's query about "people who use a
keyboard that does not allow easy access", and your reply to it. I'm
not claiming that trigraphs, digraphs, and iso646.h were necessary or
a good idea (I don't have strong feelings either way - I've never been
troubled by the "wacky punctuation in a string literal turns out to
be a trigraph" bug, since I never use such punctuation, and I'm not
aware of any other argument against them). I'm just noting that there
are C programmers who have had to cope with C-unfriendly keyboards.
--
Michael Wojcik michael...@microfocus.com
We are subdued to what we work in. (E M Forster)
Dan Pop
And I have explicitly acknowledged their existence, in the past:
The good question is whether such people do exist. 20 years ago, they
did, but back then there was no <iso646.h>...
The biggest source of problems is gone: the terminals replacing
punctuation characters by accented characters, because they used a 7-bit
character set that had to support various languages using an alphabet
with more than 26 letters.
I have no idea whether brain dead IBM terminals are still being used by
C programmers, OTOH. Back when I had access to an IBM mainframe, the
local setup was perfectly happy with VT100s and was performing all the
necessary character conversions and buffering. And those with an X
server could use the x3270 terminal emulator...
Ross Kendall Axe
Hash: SHA1
Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
:-). Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.
Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAkuB79bR4xmappRARAiDoAJ9v5I6Bt8mBa7/MuioNpFvXQ0rLAwCePwNb
PXPOrDynSuH19OjELKezPuo=
=gGte
-----END PGP SIGNATURE-----
Claudio Puviani
> Hash: SHA1
>
> marcus hall wrote:
> | In article <40891D82...@spamcop.net>,
> | Kenneth Brody <kenb...@spamcop.net> wrote:
> |
> |>Stephen Sprunk wrote:
> |>The problem goes all the way back to MS-DOS 1.0 using slashes for command-
> |>line flags. Then, when 2.0 allowed subdirectories, they were stuck.
> |
> |
> | Come on, be fair.. The problem started before MS-DOS, since CP/M used
> | '/' for options before MS-DOS even existed. And CP/M got it from various
> | DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
> | the idea, or if they got it from somewhere previous, but by now we'er
> | talking about earlier then Unix V6, so DEC can hardly be faulted for not
> | following "the one true way".
> |
> | Marcus Hall
> | mar...@tuells.org
>
> Just thumbing through my CP/M manual, I have to say I don't notice any
> forward slashes mentioned anywhere (apart from in the name of the OS
> :-). Seems all the standard CP/M utilities like their options in square
> brackets...
> That's not to say that the practice wasn't used in 3rd party CP/M
> programs, just not in the system itself.
Um... the square brackets indicated optional arguments. You didn't actually type
the brackets. :-)
Claudio Puviani
Joona I Palaste
on comp.lang.c:
>> forward slashes mentioned anywhere (apart from in the name of the OS
>> :-). Seems all the standard CP/M utilities like their options in square
>> brackets...
>> That's not to say that the practice wasn't used in 3rd party CP/M
>> programs, just not in the system itself.
> Um... the square brackets indicated optional arguments. You didn't actually type
> the brackets. :-)
I'd bet a lot of users still tried to, though, and were surprised at why
it didn't work.
I've seen my fair share of Commodore 64 BASIC programs that begin by
printing "<CLR>" (literally, as in a less than sign, C, L, R, and a
greater than sign) to the screen, followed by the introductory text.
The writer of the program copied it from a magazine listing where
"<CLR>" was used as a transcript of the CLR control character, which
could be typed by hand on a Commodore 64 but which wasn't printed very
well on paper. The magazine was bound to have an introductory paragraph
about transcripts of control characters, that they were not to be typed
literally, but many readers ignored it when typing in the programs.
I was once in the Finnish science center Heureka and went over to a
computer running a cuneiform scripting program. The program displayed
a menu:
"Please select your language:
Finnish: type 1 + enter
Swedish: type 2 + enter
English: type 3 + enter"
At least one person *insisted* that the choice must be made by first
typing the digit 1, 2 or 3, then by typing the plus sign "+", and
finally by pressing enter.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
Goran Larsson
Claudio Puviani <puv...@hotmail.com> wrote:
> Um... the square brackets indicated optional arguments. You didn't actually type
> the brackets. :-)
Have you actually used CP/M? The CP/M manuals use curly braces to indicate
optional arguments. The arguments that you type in on the command line are
enclosed in square brackets or start with a $ sign (older utilities).
Examples from the "CP/M Plus Command Summary":
A>DEVICE LPT [XON,9600]
A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
A>DIR [EXCLUDE] *.DAT
A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
A>MAC SAMPLE $PB AA HB SX -M
A>SET MYFILE.TEX [PASSWORD=MYFIL]
A>SET [DEFAULT=password]
A>SET [CREATE=ON,UPDATE=ON]
MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
introduce program options, where they got this from I don't know (but
it certainly wasn't from CP/M).
--
Göran Larsson http://www.mitt-eget.com/
Claudio Puviani
> Claudio Puviani <puv...@hotmail.com> wrote:
>
> > Um... the square brackets indicated optional arguments. You didn't actually
type
> > the brackets. :-)
>
> Have you actually used CP/M?
Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
computers (not "other" computers with CP/M cartridges). Does that count?
> The CP/M manuals use curly braces to indicate
> optional arguments. The arguments that you type in on the command line are
> enclosed in square brackets or start with a $ sign (older utilities).
>
> Examples from the "CP/M Plus Command Summary":
>
> A>DEVICE LPT [XON,9600]
> A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
> A>DIR [EXCLUDE] *.DAT
> A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
> A>MAC SAMPLE $PB AA HB SX -M
> A>SET MYFILE.TEX [PASSWORD=MYFIL]
> A>SET [DEFAULT=password]
> A>SET [CREATE=ON,UPDATE=ON]
CP/M Plus (or 3.0) was a too-little-too-late response from Digital Research after
CP/M had already lost the war. CP/M 2.2 is the version that had captured the
maket when there was a market to capture and it's still the baseline that all
CP/M software development targeted. Its commands were different from CP/M Plus,
as you can see at: http://www.gaby.de/cpm/manuals/archive/cpm22htm/index.htm
You'll also note that the original documentation did use square brackets to
indicate optional arguments.
> MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
> introduce program options, where they got this from I don't know (but
> it certainly wasn't from CP/M).
Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.
Claudio Puviani
Goran Larsson
Claudio Puviani <puv...@hotmail.com> wrote:
> Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
> computers (not "other" computers with CP/M cartridges). Does that count?
Sure.
> Since CP/M itself didn't enforce any delimiters, programs used whatever they
> wanted. Some used slashes, some use dashes, some used nothing at all.
Yes, but the programs delivered with CP/M never used / for options.
Programs delivered with CP/M 2 prefer to use $ for options.
Programs delivered with CP/M 3 prefer to use [ and ] for options.
Programs sold by MicroSoft opted to use / for options.
Blaming CP/M for MicroSoft's use of / for options is wrong. The blame
must be somewhere else, probably DEC as MicroSoft used DECsystem 10
to cross compile their CP/M programs.
Michael Wojcik
[Followups set to alt.folklore.computers, where this is topical. AFC
readers: this thread sprang out of a discussion of path separator
characters, and has now become a shouting match over where Microsoft
got the idea to use the forward slash as an option separator, and
then fell back on the backslash as a path separator.]
"Blame" seems a bit harsh, since slash as an option separator was
already established by VMS when MS-DOS 1.0 came out.[*] Blame
Microsoft instead for a poor choice of path syntax in MS-DOS 2.0.
Since they already used the VMS syntax for options, they might as
well have adopted its syntax for paths, rather than trying for some
weird mix of VMSisms and half-assed Unixisms and ending up with two
crucial punctuation characters that many users (apparently) can't
reliably distinguish.
In any case, MS-DOS 1.0 was basically a rebranding of Seatle
Computer Systems' QDOS, wasn't it? Did QDOS use the slash as an
option delimiter? It might not have even been Microsoft's choice.
[*] I'm assuming here that VMS's use of slash as option separator
dates back earlier than MS-DOS 1.0. VMS 1.0 was released in 1978,
but I didn't use it myself before 1986, so I couldn't say.