By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,784 Members | 1,182 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,784 IT Pros & Developers. It's quick & easy.

help needed with filnames as command line arguments

P: n/a
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.

I'm familiar with fopen, ascii mode, binary mode. What I'm doing
now is specifying the filenames in the source code.
So I give different names to each source code file
and recompile each time.

The data in the files is signed ints and I read from files in ascii mode,
not binary.

Also, I'd be glad to have some references about
command line argument programming or simple examples.

I have K&R, Harbison and Steele's ``C A Reference Manual" and
I know where to find the FAQ for comp.lang.c

thanks

Dvid Bernier

Nov 13 '05 #1
Share this Question
Share on Google+
25 Replies


P: n/a
"David Bernier" <da******@sympatico.ca> wrote in message
news:_k*********************@news20.bellglobal.com ...
I'd like to pass on the command line two filenames.

Also, I'd be glad to have some references about
command line argument programming or simple examples.


One specification for main() is:
int main(int argc, char *argv[])

With that, you can receive command line args, argv[0] to argv[argc - 1]. Try
this for instance:
int main(int argc, char *argv[])
{
int i;
for (i = 0; i < argc; i++)
puts(argv[i]);
return 0;
}

Hope it helps.
Nov 13 '05 #2

P: n/a
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.


#include <stdio.h>
#include <stdlib.h>

/* this will print out all command line arguments, then exit */
int main(int argc, char[] *argv)
{
int n;

for (n = 0; n < argc; n ++)
{
printf("argument %d: %s\n", n, argv[n]);
}

return 0;
}

The above code is untested & uncompiled. YMMV :-)
Nov 13 '05 #3

P: n/a
In your source code, define main with this prototype.

main(int args, char *argv[])
{
int i;
printf("executable file : %s", argv[0]);
printf("Number of arguments is : %d", args);
for(i=1;i<args;i++)
{
printf("Argument %d is : %s\n", i, argv[i]);
}
}

Hope this helps.

Regards,
Rama Krishna.

David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.

I'm familiar with fopen, ascii mode, binary mode. What I'm doing
now is specifying the filenames in the source code.
So I give different names to each source code file
and recompile each time.

The data in the files is signed ints and I read from files in ascii mode,
not binary.

Also, I'd be glad to have some references about
command line argument programming or simple examples.

I have K&R, Harbison and Steele's ``C A Reference Manual" and
I know where to find the FAQ for comp.lang.c

thanks

Dvid Bernier

Nov 13 '05 #4

P: n/a
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2


/* -------- start cut here ------------- */
#include<stdio.h>

int printargstuff(int aa, char *bb[]);
int main(int argc, char *argv[]) //NOTE - passing in command line argc/argv
{
printargstuff(argc, *argv[0]);
return(0);
}

int printargstuff(int aa, char *bb[])
{
int i1 = 1;
printf("%d argument(s) passed to the command \n", aa-1);
if (bb[1] != NULL)
{
while (i1 < aa)
{
printf ("%s, \n",bb[i1++]);
}
}
return(0);
}
/* --------------end cut here ------------------------*/
hope it helps.
Nov 13 '05 #5

P: n/a
dh*****@ihug.co.nz (Duncan Bayne) wrote:
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.
#include <stdio.h>
#include <stdlib.h>

/* this will print out all command line arguments, then exit */
int main(int argc, char[] *argv)

Parse error. Make it:

int main(int argc, char *argv[] )
or
int main(int argc, char **argv )
{
int n;

for (n = 0; n < argc; n ++)
{
printf("argument %d: %s\n", n, argv[n]);
}

return 0;
}

The above code is untested & uncompiled. YMMV :-)


The corrected version is. :-)

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #6

P: n/a
ra*************@yahoo.com (Rama Krishna) wrote:

First off, you forgot about this:

#include <stdio.h>
In your source code, define main with this prototype. main(int args, char *argv[])
No. define main as:

int main(int args, char *argv[])

or, alternatively:

int main(int args, char **argv)
{
int i;
printf("executable file : %s", argv[0]);
It's not required by the standard for an implementation to provide the
name of the executable in argv[0] (IOW argv[0][0] may equal 0).
Moreover, if argc equals 0, argv[0] is required to be a NULL pointer
(Generally, argv[argc] is required to be a NULL pointer).
printf("Number of arguments is : %d", args);
Note that this count includes argv[0] as well.
for(i=1;i<args;i++)
{
printf("Argument %d is : %s\n", i, argv[i]);
}
return 0;}


BTW, please don't top-post, thank you.

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #7

P: n/a
cr****@smartchat.net.au (Craigb) wrote:
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

If the follwing compiles at all, it'll most certainly not work as
intended.

/* -------- start cut here ------------- */
#include<stdio.h>

int printargstuff(int aa, char *bb[]);
int main(int argc, char *argv[]) //NOTE - passing in command line argc/argv
{
printargstuff(argc, *argv[0]);
WARNING: passing arg 2 of `printargstuff' makes pointer from integer
without a cast

make it:

printargstuff(argc, argv);
return(0);
}

int printargstuff(int aa, char *bb[])
{
int i1 = 1;
printf("%d argument(s) passed to the command \n", aa-1);
if (bb[1] != NULL)
{
while (i1 < aa)
{
printf ("%s, \n",bb[i1++]);
}
}
return(0);
}
/* --------------end cut here ------------------------*/
hope it helps.


<meta rant>
I am impressed by the fact that only one out of four replies (so far)
contained correct code. Please, test your code before you post it.
Thank you.
</meta rant>

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #8

P: n/a


Craigb wrote:
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...

I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2
#include<stdio.h>

/*** NOTE: I added #include <string.h> here ***/

int printargstuff(int aa, char *bb[]);
int main(int argc, char *argv[]) //NOTE - passing in command line argc/argv
{
printargstuff(argc, *argv[0]); //DB: line 9: Warning issued about this line, see below...
return(0);
}

int printargstuff(int aa, char *bb[])
{
int i1 = 1;
printf("%d argument(s) passed to the command \n", aa-1);
if (bb[1] != NULL)
{
while (i1 < aa)
{
printf ("%s, \n",bb[i1++]);
}
}
return(0);
}

It didn't quite work. I got a warning about this line:

printargstuff(argc, *argv[0]); here it is:

``line 9: warning: improper pointer/integer combination: arg #2 "

Here's some sample output:

% ./a.out hello there
2 argument(s) passed to the command
Bus Error (core dumped)

thanks for your help,

David Bernier


Nov 13 '05 #9

P: n/a
David Bernier <da******@sympatico.ca> wrote:

Craigb wrote:
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2
#include<stdio.h>

/*** NOTE: I added #include <string.h> here ***/


You don't use anything defined in string.h, so why include it?
int printargstuff(int aa, char *bb[]);

int main(int argc, char *argv[]) //NOTE - passing in command line argc/argv
{
printargstuff(argc, *argv[0]); //DB: line 9: Warning issued about this line, see below...


Make it match the prototype:

printargstuff(argc, argv);

<snip>It didn't quite work. I got a warning about this line:

printargstuff(argc, *argv[0]); here it is:


See above.

<snip>

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #10

P: n/a


Duncan Bayne wrote:
David Bernier <da******@sympatico.ca> wrote in message news:<_k*********************@news20.bellglobal.co m>...

I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.


#include <stdio.h>
#include <stdlib.h>

/* this will print out all command line arguments, then exit */

[...]

Following the reply by Irrwahn Grausewitz, I edited your code, and I'm
happy that the
edited version compiles and does what it's supposed to do.

thanks again,

David Bernier
------------------------------------

Edited code follows:
----------------------------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

/* this will print out all command line arguments, then exit */

int main(int argc, char *argv[])
{
int n;

for (n = 0; n < argc; n ++)
{
printf("argument %d: %s\n", n, argv[n]);
}

return 0;
}
-------------------------------------------------------------------------------------------------
Nov 13 '05 #11

P: n/a
In <_k*********************@news20.bellglobal.com> David Bernier <da******@sympatico.ca> writes:
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.

I'm familiar with fopen, ascii mode, binary mode. What I'm doing
now is specifying the filenames in the source code.
So I give different names to each source code file
and recompile each time.

The data in the files is signed ints and I read from files in ascii mode,
not binary.

Also, I'd be glad to have some references about
command line argument programming or simple examples.

I have K&R, Harbison and Steele's ``C A Reference Manual" and
I know where to find the FAQ for comp.lang.c


What's the point in having C books if you can't be bothered to read them?
K&R explains the issue in great detail.

You also need to know that you have to read the FAQ *before* posting.
But your question is far too basic to be worth addressing in the FAQ:
any good tutorial C book will describe the parameters of the main
function and their usage.

#include <stdio.h>

int main(int argc, char **argv)
{
while (*argv) puts(*argv++);
return 0;
}

Couldn't be any easier.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #12

P: n/a
> <meta rant>
I am impressed by the fact that only one out of four replies (so far)
contained correct code. Please, test your code before you post it.
Thank you.
</meta rant>

Regards


Tested... *still* works fine for me, however.. appreciate the
feedback. Tested on Bloodshed gcc and Cygwins gcc also in case you're
wondering.
/cb
Nov 13 '05 #13

P: n/a
cr****@smartchat.net.au (Craigb) wrote:
<meta rant>
I am impressed by the fact that only one out of four replies (so far)
contained correct code. Please, test your code before you post it.
Thank you.
</meta rant>

Regards


Tested... *still* works fine for me, however.. appreciate the
feedback. Tested on Bloodshed gcc and Cygwins gcc also in case you're
wondering.


Really? Let's see...

Output generated by MingW32 (gcc 3.2, the version that comes with
Bloodshed DevCpp, so probably the same you use):

[...]
gcc.exe "D:\Temp\CraigB_1.c" -o "D:\Temp\CraigB_1.exe" -W -Wall
-std=c99 -O3 -I[...] -L[...]
[...]
D:/Temp/CraigB_1.c:8: warning: passing arg 2 of `printargstuff'
makes pointer from integer without a cast [1]

OK, now let's review your code:
....
003 int printargstuff(int aa, char *bb[]);
....
006 int main(int argc, char *argv[])
007 {
008 printargstuff(argc, *argv[0]);
....

The second argument of printargstuff() has to be a
pointer-to-pointer-to-character. You pass *argc[0] to it,
which is a character. Now please explain how this is
supposed to work without invoking undefined behaviour.
[1] You most probably didn't set your warning level to a
suitable amount. Warnings usually _are_ errors!

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #14

P: n/a
"David Bernier" <da******@sympatico.ca> wrote:
I'd like to pass on the command line two filenames.

As for example:

my_executable filename_1 filename_2

I haven't done any C programming with command line arguments so far.

I'm familiar with fopen, ascii mode, binary mode. What I'm doing
now is specifying the filenames in the source code.
So I give different names to each source code file
and recompile each time.

The data in the files is signed ints and I read from files in ascii mode,
not binary.


I think you mean text mode. There is no "ascii mode" in C.

C:\docs\prog\c>type dbernier.c
#include <stdio.h>

int main(int argc, char **argv)
{
int i;
for(i = 1; i < argc; i++)
{
int value = 0;
FILE *fp = fopen(argv[i], "r");
if(fp)
{
if(fscanf(fp, "%d", &value) == 1)
{
printf("%s: %d\n", argv[i], value);
}
fclose(fp);
}
}
return 0;
}

C:\docs\prog\c>gcc -std=c99 -pedantic -Wall -W -O2 dbernier.c -o dbernier

C:\docs\prog\c>dbernier *
42.txt: 69
comb.txt: 0
fig.out: 2147483647
input.raw: 6
lotto.diff: 1781
tmp2: 9

These files just happened to have a number at the beginning.

--
Simon.
Nov 13 '05 #15

P: n/a
Simon Biber wrote (minisculy edited):
.... snip ...
#include <stdio.h>
int main(int argc, char **argv)
{
int i;
for (i = 1; i < argc; i++) {
int value = 0;
FILE *fp = fopen(argv[i], "r");
if (fp) {
if (fscanf(fp, "%d", &value) == 1)) {
printf("%s: %d\n", argv[i], value);
}
fclose(fp);
}
}
return 0;
}


While C has, for some time, allowed this sort of declaration
within a block, I see very little use for it. The code is much
more flexible if broken into a separate routine. The only cost is
(possibly) the time to call and return, which would be vanishingly
small here compared with the actual routine action. Thus I would
recommend:

#include <stdio.h>
static void tryfile(const char *fn)
{
int value;
FILE *fp;
if (fp = fopen(fn, "r"))
if (fscanf(fp, "%d", &value) == 1) {
printf("%s: %d\n", fn, value);
}
fclose(fp);
}
}

int main(int argc, char **argv)
{
int i;
for (i = 1; i < argc; i++) {
tryfile(argv[i]);
}
return 0;
}

which, at least to me, is clearer in that each routine has one
simple responsibility. With C99 you can also have all the
benefits of the single routine method by using the inline
directive. YMMV.

With this organization it is easier (to me) to see that one should
worry about the action of fopen on an empty string, and trivial to
avoid it. We can also easily see that initialization during
declaration is not needed anywhere.

There is no need to agree with me :-) but at least you can
evaluate my preference after seeing the reasons.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 13 '05 #16

P: n/a
CBFalconer <cb********@yahoo.com> wrote:
Simon Biber wrote (minisculy edited):

... snip ...

#include <stdio.h>
int main(int argc, char **argv)
{
int i;
for (i = 1; i < argc; i++) {
int value = 0;
FILE *fp = fopen(argv[i], "r");
if (fp) {
if (fscanf(fp, "%d", &value) == 1)) {
printf("%s: %d\n", argv[i], value);
}
fclose(fp);
}
}
return 0;
}


While C has, for some time, allowed this sort of declaration
within a block, I see very little use for it.


Alas, I sometimes use initialization within a block in switch
statements, e.g. where a helper variable is needed in only one
special case and I want to have it declared where it's used:

/*...*/
int foo, bar;

switch( whatever )
{
case CASE_X:
/* do something */
break;

case CASE_SWAP:
{
int tmp = foo;
foo = bar;
bar = tmp;
}
break;

case CASE_Y:
/* do something else */
break;

default:
/* perform default action */
}
Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #17

P: n/a
Irrwahn Grausewitz wrote:
CBFalconer <cb********@yahoo.com> wrote:

.... snip ...

While C has, for some time, allowed this sort of declaration
within a block, I see very little use for it.


Alas, I sometimes use initialization within a block in switch
statements, e.g. where a helper variable is needed in only one
special case and I want to have it declared where it's used:


You snipped my point, which was that such usage often indicates
the need to repartition the code.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #18

P: n/a
CBFalconer <cb********@yahoo.com> wrote:
Irrwahn Grausewitz wrote:
CBFalconer <cb********@yahoo.com> wrote:

... snip ...
>
> While C has, for some time, allowed this sort of declaration
> within a block, I see very little use for it.


Alas, I sometimes use initialization within a block in switch
statements, e.g. where a helper variable is needed in only one
special case and I want to have it declared where it's used:


You snipped my point, which was that such usage often indicates
the need to repartition the code.


I snipped it because your point remains valid and I support it, but in
special cases I ignore it, when I don't want to repartition the code.

Admittedly my actual example was a rather silly one. A more realistic
example would've been a message handler routine, but I didn't want to
clutter my post with ugly OT windowish code.

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #19

P: n/a
> The second argument of printargstuff() has to be a
pointer-to-pointer-to-character. You pass *argc[0] to it,
which is a character. Now please explain how this is
supposed to work without invoking undefined behaviour.
[1] You most probably didn't set your warning level to a
suitable amount. Warnings usually _are_ errors!

Regards


There you go, now I learned something!..
I re-did it in the ide and of course found what you are saying. I
won't go too far off topic, but the reason I was in the threads at all
was to find out exactly that sort of thing, so no-bad from my point of
view. Of course now I'll be doing searches on your login to find out
what other tips I can glean.
/cb.
Nov 13 '05 #20

P: n/a
cr****@smartchat.net.au (Craigb) wrote:

<snip>
Of course now I'll be doing searches on your login to find out
what other tips I can glean.


Er, be careful, I'm not an expert, and thus my posts are often an
example for how to /not/ do things. You'd better do a search for
posts originating from regulars like (in no particular order):

Chris Torek
Dan Pop
Douglas A. Gwyn
Jack Klein
Richard Heathfield
...
<list incomplete>

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #21

P: n/a
Irrwahn Grausewitz <ir*******@freenet.de> wrote:
cr****@smartchat.net.au (Craigb) wrote:

<snip>
Of course now I'll be doing searches on your login to find out
what other tips I can glean.


Er, be careful, I'm not an expert, and thus my posts are often an
example for how to /not/ do things. You'd better do a search for
posts originating from regulars like (in no particular order):

Chris Torek
Dan Pop
Douglas A. Gwyn
Jack Klein
Richard Heathfield
...
<list incomplete>


Lawrence Kirby unfortunately hasn't been posting to clc for over
a year now, but for relative newbies who want to search the
archives, /Lawrence/ /Kirby/ stands second only to /Chris/ /Torek/
in the history of comp.lang.c for having spent _many_ years
posting readable, tolerant, tutorial articles that are not only
accurate and detailed, but written in a style that can be read
and understood by the neophyte as well as the expert.

I don't mean to suggest that others lack knowledge of C or even
longevity on c.l.c, but Chris and Larry stand out from the crowd
when it comes to style and writing ability.

Hence, along with Steve Summit's FAQ, using google to search for
articles by "Chris Torek (no****@elf.eng.bsdi.com)" and/or
"Lawrence Kirby (fr**@genesis.demon.co.uk)" is probably about
the most productive learning tool for C available on the web.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl***@barrow.com
Nov 13 '05 #22

P: n/a
Floyd Davidson wrote:
Irrwahn Grausewitz <ir*******@freenet.de> wrote: <snip>
You'd better do a search for
posts originating from regulars like (in no particular order):

Chris Torek
Dan Pop
Douglas A. Gwyn
Jack Klein
Richard Heathfield
(cough)

Add Ben Pfaff, Dann Corbit, Christian Bau, Joe Maun (not that he's been
around for a while either), Steve Summit (ditto, alas), and "those who know
me have no need of my name". If my name belongs on the list (which is
arguable), all these names most certainly belong on it too.
...
<list incomplete>


....even after my additions.
Lawrence Kirby unfortunately hasn't been posting to clc for over
a year now, but for relative newbies who want to search the
archives, /Lawrence/ /Kirby/ stands second only to /Chris/ /Torek/
in the history of comp.lang.c for having spent _many_ years
posting readable, tolerant, tutorial articles that are not only
accurate and detailed, but written in a style that can be read
and understood by the neophyte as well as the expert.


I will cheerfully second that statement. Lawrence Kirby is a byword (all
right, make that two bywords) for excellence in comp.lang.c.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #23

P: n/a
On 20 Oct 2003 03:57:17 -0800, Floyd Davidson <fl***@barrow.com>
wrote:
<snip>
Lawrence Kirby unfortunately hasn't been posting to clc for over
a year now, but for relative newbies who want to search the
archives, /Lawrence/ /Kirby/ stands second only to /Chris/ /Torek/
in the history of comp.lang.c for having spent _many_ years
posting readable, tolerant, tutorial articles <snip>
Hence, along with Steve Summit's FAQ, using google to search for
articles by "Chris Torek (no****@elf.eng.bsdi.com)" and/or
"Lawrence Kirby (fr**@genesis.demon.co.uk)" is probably about
the most productive learning tool for C available on the web.


Don't specify that exact address for Chris, he's had to change
(several times, if I recall) so you won't find everything. Without
actually trying, I'd guess Torek + comp.lang.c should be enough.

- David.Thompson1 at worldnet.att.net
Nov 13 '05 #24

P: n/a
In article <87************@barrow.com>
Floyd Davidson <fl***@barrow.com> writes:
At one time, just prior to C89, there was some serious thought
given to collecting the c.l.c articles of Chris Torek for
publication as a C tutorial. That became a moot when the
Standard was released ...
I must also note that there is an enormous difference between
a "collection of vignettes" and a "complete novel", as it were.
However, I wonder if Chris has ever given any thought to the
specifics of his writing style? And if he would be willing to
consider a tutorial for writing technical articles for Usenet?
Or, maybe even just a few words on the subject?


I am not really sure what you mean by the first question. As for
the second or third -- well, it would help if I knew how I do it. :-)
I think there are a few key points, however, that I could mention.

The first is simple enough. If you want to write good code, you
should read good code. If you want to write good prose, you should
read good prose. If you want to write good tutorials...

Obviously, you must know the material. But in this case there is
a subtler, yet key, point: you must also know the audience, after
a fashion. Here, Usenet has an advantage over books, because the
writers interact (to whatever limited extent) with their readers.
This means that the writer gets *some* feedback -- at the least,
something on the level of "oh I get it" vs "huh?" -- now and then.

Finally, there is no substitute for sitting back and thinking.
People say that Feynman's method of solving physics problems was:
(1) write down the problem; (2) sit and think; (3) write down the
answer. Not everyone can be a Feynman, but just about anyone can
do the "sit and think" part now and then. I think (after sitting
and thinking :-) ) that this is probably the hardest part of the
whole process, not just to do but to explain. How is it that we
(sentient beings in general) make connections and analogies? How
do we generalize? How do we test a generalization once made? (I
often resort to the "throw a few examples at it to see if they
pass" test, as if testing spaghetti for doneness by whether it
sticks to the wall. It works well for a first cut, at least.)

Computer programming is, at its heart, about abstraction --
controlling complexity by removing irrelevant detail, at the point
where it becomes irrelevant. I am not at all sure that tutorial-writing
is about abstraction. It seems different, somehow. Certainly
there are people who are quite good at one and terrible at the
other. But some of the elements are the same: programs can be
terribly complex, and often the only way to get them right is to
simplify them. This gives rise to program structures, including
data structures. Tutorials likewise need structure, so that details
appear only where they are relevant. But the structures themselves
are different, or at least, have quite different constraints.

Well, that seems quite a few words for saying "I don't know", but
I am prone to a certain prolixity. :-) There is really only one
part that I am sure of: if you want to write, you must read, read,
read.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #25

P: n/a
Chris Torek <no****@elf.eng.bsdi.com> wrote:
In article <87************@barrow.com>
Floyd Davidson <fl***@barrow.com> writes:
At one time, just prior to C89, there was some serious thought
given to collecting the c.l.c articles of Chris Torek for
publication as a C tutorial. That became a moot when the
Standard was released ...
I must also note that there is an enormous difference between
a "collection of vignettes" and a "complete novel", as it were.


Granted a *lot* of work would be needed to mold it into a novel.
But darned, given your style of writing, I thought then (and
still do) that it would be just a grand novel. I have always
thought the same about Lawrence Kirby's style of writing too.
It isn't just the facts, it's the life that you give those facts
in your expression of the story you tell. And indeed, you *do*
write stories, not just a list of facts.

I also have an interest in the style in which traditional Native
stories are told. There is a striking similarity between how
you would describe the inner workings a compiler, which is an
object most of us cannot really "see" with our own eyes or touch
with our own fingers, and the way an Eskimo elder might explain
to children the complex structure of something like the umiaq
boats used for whaling here in Barrow, or perhaps something even
more abstract such as spiritual relationships between humans and
animals. (You can, for example, find a great number of these
stories written down, but it is very hard to find one that will
make you sit up at the end and say, "Wow, I *understand*!".

Usually the response is more like, "Okay, if they think so...")

When I was young I learned a great deal about parenting skills
from an "old" Yup'ik Eskimo man (I am now the age he was then,
so I no longer think he was so old), whose adult children used
to tell me they would sometimes get him talking in the evening
and they would try so hard to stay awake because it was so
interesting. But of course, eventually they'd fall asleep
anyway. One of his youngest daughters, who was about 19 or 20
at the time, told me every time she woke up after one of those
sessions, realizing that she had fallen asleep too soon and had
missed something, she'd swear next time she would stay awake
longer.
[interesting stuff snipped]
Computer programming is, at its heart, about abstraction --
controlling complexity by removing irrelevant detail, at the point
where it becomes irrelevant. I am not at all sure that tutorial-writing
is about abstraction. It seems different, somehow. Certainly
there are people who are quite good at one and terrible at the
other. But some of the elements are the same: programs can be
terribly complex, and often the only way to get them right is to
simplify them. This gives rise to program structures, including
data structures.
I wanted to leave the context above and below the following
sentence, and yet separate this one part out from the rest. To
me, the ability to accomplish this seems to be the key to most
writing for Usenet, but certainly for tutorials in particular.
Tutorials likewise need structure, so that details appear only
where they are relevant.
Of course there's a lot of devils in the details of how to
accomplish that.
But the structures themselves are different, or at least, have
quite different constraints.

Well, that seems quite a few words for saying "I don't know", but
I am prone to a certain prolixity. :-) There is really only one
part that I am sure of: if you want to write, you must read, read,
read.


Thanks Chris, I enjoyed your comments and perspective.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl***@barrow.com
Nov 13 '05 #26

This discussion thread is closed

Replies have been disabled for this discussion.