NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/msdos/programm/11566

Text File | 1992-12-22 | 6.0 KB | 127 lines

Newsgroups: comp.os.msdos.programmer
Path: sparky!uunet!uunet.ca!ohrd!twriter
From: [e-mail] (Timothy Writer)
Subject: Re: Normal MSDOS multitasking!
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: "Ontario Hydro - Research Division"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 22 Dec 92 00:35:09 GMT
Lines: 115

[e-mail] (Duncan Murdoch) writes:

>In article <[e-mail]> [e-mail] (Timothy Writer) writes:
>>>The number of times where it really matters whether two programs are run
>>>concurrently at half speed or sequentially at full speed is so tiny, that I
>>>doubt if it's on anybody's "10 most important projects" list.
>>
>>Can you support that statement?  I doubt it.  It may be true for DOS
>>users because they have never had the option but I don't think it's true
>>for the wider user community.  Consider the following (UNIX commands):
>>
>>    cc -E program.c | more
>>
>>I use this to view the result of running the C preprocessor on my
>>program when I suspect a problem with a complex macro.  I don't want to
>>wait for the first command to complete before I can view the results.

>I don't deny that there are some cases where there's a difference.  But
>how often do you really have problems with complex macros?  If it's as
>often as once a week, I'd suggest that you're doing something wrong.

You missed the point.  My programming skill (or possible lack thereof)
is not the issue.  The issue is:  Are (UNIX style) pipelines, where each
program (process) in the pipeline runs concurrently, a useful device in
ANY operating system/environment be it DOS, Windows, Desqview, VMS, CICS
or (heaven forbid ;-) a UNIX derivative?  Without providing examples or
an argument to support your assertion, you stated that they are rarely
useful.  That is your opinion and you are entitled to it.  However, I
have a different opinion.  Consequently, I provided several simple
examples supporting my assertion that pipelines are useful.  I chose
simple examples to illustrate my point so that others who may be
unfamiliar with UNIX style pipelines would understand.  The fact that
you (or I for that matter) may not actually use one of these specific
examples on a daily basis does not refute my argument.  Although I did

>>    man cc | more
>>
>>Suppose I just want to check the syntax of a particular option for the C
>>compiler.  The most common options are documented at the beginning (for
>>obvious reasons) so I don't want to wait for the entire manual page to
>>be formatted first.  In fact, if I quit once I've found what I'm looking
>>for, man cc never runs to completeion!  This may not matter to me much
>>but it may matter to other users who are sharing the CPU with me.

>Under DOS, nobody is sharing the CPU with you.  Under DOS, the weird idea
>that you should pass a manual page through a text formatter every time you
>want to look at it never caught on; help systems keep their text in a format
>that's convenient to display.

True, under *DOS* nobody is sharing the CPU with you.  However, under
Windows or Desqview you maybe sharing the CPU with yourself!  For
example, you may have a huge compile running in the background while you
do some other useful work.  Or perhaps you have a long running numerical
application also running in the background.  Do you want to steal CPU
cycles from your own background jobs?

I don't buy your second point either.  First, man is not a text
formatter.  It may pass your manual page through a text formatter if it
is not already preformatted; however, most systems now store manual
pages in compressed, formatted form.  Every time you want to look at
them you do have to uncompress them.  What's wrong with that?  Furthermore,
some sites prefer to install unformatted manual pages because they use
less disk space.  This is just another form or compression with the
added benefit that they can easily be formatted for a variety of output
devices including terminals, line printers, laser printers, and
bitmapped displays.

>>zcat huge.tar.Z | tar tvf - | grep 'foo*.c'
>>
>>Here I'm just looking for some files matching a pattern in a LARGE
>>compressed archive.  Do you really want to uncompress and list the
>>entire contents of the archive?  What if you don't have the disk space
>>for the entire archive?

>Under DOS, there are lots of programs available to search the text contained
>in archives without uncompressing them, and every archive program that I've

These (and others) are available for UNIX too.  What's your point?

>ever seen will list the filenames without uncompressing the archive.  For
>example, I'd probably run

>  pkunzip -v huge foo*.c

That won't work very well on a compressed tar archive!  Oh, I get it,
I'm supposed to have a zip file.  But I don't have a zip file, I have a
tar archive.

The purpose of the example was to illustrate the utility of a pipeline
not the merits of tar and compress.

>to do what you did above.  The idea that you have to uncompress
>anything at all just to see the filenames strikes me as a very bad design.

So on an individual basis, you didn't like any of my examples.  You
weren't supposed to consider them on an individual basis you were
supposed to look at the whole and say, 'Just maybe he's right, maybe
pipes are useful, too bad DOS or Windows doesn't have them'.  Instead
you chose to nitpick example by example.  I could cite 100 more examples
but I suppose you would just nitpick those too.

Here's another argument for pipes.  Have you ever written a program
where you wanted the output of some system command, DIR for example?
Of course you can use a temporary file but what if there's not enough
disk space?  Why not use a pipe instead?

Tim

>Duncan Murdoch
>[e-mail]
--
Tim Writer                 phone:  [phone] ext. 6990
Ontario Hydro Research Division         fax:    [phone]
Toronto, Ontario             e-mail: [e-mail]
CANADA