c program - command line prompt - need help
raeiko
i urgently need your help
I have to write a C program that reads a series of strings and prints
only those that end with the letters “ed.” To enter the string i
should use the command line prompt and when i press the return key,
the program should print the string if it ends in "ed" and prompt for
another string if it doesn't.
My problem is that, even after reading from Dietel book and searching
in internet, I didn't get how to use the command line prompt...
Could you be so kind to give me some hints to start from?
Thanks in advance for your help,
Spiros Bousbouras
Left homework for the last moment , have we ?
> I have to write a C program that reads a series of strings and prints
> only those that end with the letters “ed.” To enter the string i
> should use the command line prompt and when i press the return key,
> the program should print the string if it ends in "ed" and prompt for
> another string if it doesn't.
>
> My problem is that, even after reading from Dietel book and searching
> in internet, I didn't get how to use the command line prompt...
>
> Could you be so kind to give me some hints to start from?
The right place to start is to describe the problem exactly. The
problem here is that it is unclear what you mean by "command
line prompt". The C standard doesn't say anything about a
"command line prompt" nor have I seen anywhere a description
of C which mentions a "command line prompt". It's not clear
whether you simply mean reading from stdin or whether you
are using some sort of specialised environment where C comes
with a "command line prompt".
Do you know how to do everything else and simply have trouble
with this prompt thingy ?
Richard Heathfield
> Hello guys,
>
> i urgently need your help
>
> I have to write a C program that reads a series of strings and
> prints only those that end with the letters ?ed.? To enter the
> string i should use the command line prompt and when i press the
> return key, the program should print the string if it ends in "ed"
> and prompt for another string if it doesn't.
>
> My problem is that, even after reading from Dietel book and
> searching in internet, I didn't get how to use the command line
> prompt...
You seem to be talking about what are usually known as command line
arguments.
> Could you be so kind to give me some hints to start from?
I think I see what you mean about Deitel and Deitel's explanation.
Okay, here's the basic idea:
We start off by using the other form of main(). You are probably
accustomed to int main(void), but to gain access to command line
arguments we need to use this instead:
int main(int argc, char **argv)
argc is a count of the command line arguments, and argv is a pointer
to the first element of an array of pointers, each of which points
to the first character in a command line argument. argv[0]
represents the name of the program (in some implementation-specific
way - it might be the program's name, or perhaps the name with the
full path as a prefix, or something bizarre like a process ID, but
it'll be *something*, anyway - and normally we'll just ignore it).
argv[argc] is defined to be a null pointer.
The remainder of the arguments, if there are any, are stored in
argv[1] through argv[argc - 1].
So let's imagine our program is called "foo", and we invoke it
thusly:
./foo bar baz quux
argv[0] might point to "./foo", or "foo", or
"/home/rjh/alldata/dev/foo/foo", or "71629", or something like
that.
argv[1] will point to "bar". argv[2] will point to "baz". argv[3]
will point to "quux". And argv[4] will be a null pointer.
argc will be 4.
To display each of these arguments in turn (a common student
exercise), we can do this:
#include <stdio.h>
int main(int argc, char **argv)
{
int thisarg = 1; /* skip the uninteresting program name */
while(argv[thisarg] != NULL)
{
printf("%d: %s\n", thisarg, argv[thisarg]);
++thisarg;
}
return 0;
}
When I call this program "foo" and invoke it as shown above, I get
the following output:
1: bar
2: baz
3: quux
I hope this explanation helps clarify things a little, but if you
are still stuck, please explain which bit it is that you are having
trouble with.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Curtis Dyer
What have you tried so far?
> Thanks in advance for your help,
One option might be using the `fgets()' function in a loop to read
from `stdin', one line at a time. You could then examine the data
for the current line in your loop, and make a decision as to what you
want to do.
Just a bit of a disclaimer, I'm still in the process of learning C as
well.
--
Curtis
s/sig\.invalid/gmail.com/;
Curtis Dyer
> raeiko said:
>
> > Hello guys,
> >
> > i urgently need your help
> >
> > I have to write a C program that reads a series of strings and
> > prints only those that end with the letters ?ed.? To enter the
> > string i should use the command line prompt and when i press the
> > return key, the program should print the string if it ends in "ed"
> > and prompt for another string if it doesn't.
> >
> > My problem is that, even after reading from Dietel book and
> > searching in internet, I didn't get how to use the command line
> > prompt...
>
> You seem to be talking about what are usually known as command line
> arguments.
>
> > Could you be so kind to give me some hints to start from?
>
> I think I see what you mean about Deitel and Deitel's explanation.
>
> Okay, here's the basic idea:
>
> We start off by using the other form of main(). You are probably
> accustomed to int main(void), but to gain access to command line
> arguments we need to use this instead:
Perhaps I'm misreading the OP's post still, but it seems like they
want something like getting input from STDIN interactively via a
shell terminal. Despite the OP mentioning not understanding how to
use "the command line prompt", their spec seems doesn't seem to
indicate the need for command line arguments.
This is an excerpt from the OP's spec:
Message-ID: <c45530e9-d711-4101-9458-
24ac6c...@a39g2000yqc.googlegroups.com>
... when i press the return key, the program should print the
string if it ends in "ed" and prompt for another string if it
^^^^^^^^^^^^^^^^^^^^^^^^^
> doesn't.
Sorry if I'm missing something painfully obvious. :-/
<snip>
--
Curtis
s/sig\.invalid/gmail.com/;
Phil Carmody
> raeiko said:
>
>> Hello guys,
>>
>> i urgently need your help
>>
>> I have to write a C program that reads a series of strings and
>> prints only those that end with the letters ?ed.? To enter the
>> string i should use the command line prompt and when i press the
>> return key, the program should print the string if it ends in "ed"
>> and prompt for another string if it doesn't.
>>
>> My problem is that, even after reading from Dietel book and
>> searching in internet, I didn't get how to use the command line
>> prompt...
>
> You seem to be talking about what are usually known as command line
> arguments.
"...and prompt for another string..." sounds more like stdin to me.
An array of char, and an fgets() call seems to be the order of the day.
Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Richard Heathfield
<snip>
> Perhaps I'm misreading the OP's post still, but it seems like they
> want something like getting input from STDIN interactively via a
> shell terminal. Despite the OP mentioning not understanding how to
> use "the command line prompt", their spec seems doesn't seem to
> indicate the need for command line arguments.
>
> This is an excerpt from the OP's spec:
>
> Message-ID: <c45530e9-d711-4101-9458-
> 24ac6c...@a39g2000yqc.googlegroups.com>
> ... when i press the return key, the program should print the
> string if it ends in "ed" and prompt for another string if it
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> > doesn't.
>
> Sorry if I'm missing something painfully obvious. :-/
Perhaps we both did. You're right to point out my omission, but now
I'm wondering whether he needs /both/ - command-line processing
/and/ standard input processing. (Alternatively, you're right, I'm
wrong, and I just chased him up a blind alley.)
Richard
> Curtis Dyer said:
>
> <snip>
>
>> Perhaps I'm misreading the OP's post still, but it seems like they
>> want something like getting input from STDIN interactively via a
>> shell terminal. Despite the OP mentioning not understanding how to
>> use "the command line prompt", their spec seems doesn't seem to
>> indicate the need for command line arguments.
>>
>> This is an excerpt from the OP's spec:
>>
>> Message-ID: <c45530e9-d711-4101-9458-
>> 24ac6c...@a39g2000yqc.googlegroups.com>
>> ... when i press the return key, the program should print the
>> string if it ends in "ed" and prompt for another string if it
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>> > doesn't.
>>
>> Sorry if I'm missing something painfully obvious. :-/
>
> Perhaps we both did. You're right to point out my omission, but now
> I'm wondering whether he needs /both/ - command-line processing
> /and/ standard input processing. (Alternatively, you're right, I'm
> wrong, and I just chased him up a blind alley.)
Why would you wonder that. Requirements analysis is simple enough in this
case because he *specifically* states:
,----
| >> ... when i press the return key, the program should print the
| >> string if it ends in "ed" and prompt for another string if it
`----
It could not be clearer.
nick_keigh...@hotmail.com
> i urgently need your help
:-(
> I have to write a C program that reads a series of strings and prints
> only those that end with the letters “ed.” To enter the string i
> should use the command line prompt and when i press the return key,
> the program should print the string if it ends in "ed" and prompt for
> another string if it doesn't.
I think other posters have seriously misunderstood you.
This is plainly an interactive program (no command line arguments
needed)
> My problem is that, even after reading from Dietel book and searching
> in internet, I didn't get how to use the command line prompt...
>
> Could you be so kind to give me some hints to start from?
>
> Thanks in advance for your help,
does this help?
#include <string.h>
#include <stdio.h>
int main (void)
{
for (;;)
{
char line [1024];
char *nl;
printf ("enter a string: ");
fflush (stdout); /* ensure prompt appears */
/* read a string, halt if get end-of-file */
if (fgets (line, sizeof line, stdin) == NULL)
return 0;
/* halt when get an empty string */
if (line[0] == '\n')
return 0;
/* remove end-of-line */
if ((nl = strchr (line, '\n')) != NULL)
*nl = '\0';
printf ("the string you entered was \"%s\"\n", line);
}
return 0;
}
nick_keigh...@hotmail.com
nevertheless you were correct
Han from China
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> int thisarg = 1; /* skip the uninteresting program name */
> while(argv[thisarg] != NULL)
> {
> printf("%d: %s\n", thisarg, argv[thisarg]);
> ++thisarg;
> }
> return 0;
> }
Readers may wish to disregard the above program from the troll
Richard Heathfield. Like every other program of his that I've
seen, the above contains a beginner-level bug.
See the new thread "Even more proof of errors going uncorrected"
for details.
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
jacob navia
> Richard Heathfield wrote:
>> #include <stdio.h>
>>
>> int main(int argc, char **argv)
>> {
>> int thisarg = 1; /* skip the uninteresting program name */
here there should be a test:
if (argc < 2) {
printf("Missing arguments!\n");
return 0;
}
Now, this is quite elementary. I do not see why Mr Heathfield poses as
the pope here if he posts code like this.
>> while(argv[thisarg] != NULL)
That should be
while (thisarg < argc)
>> {
>> printf("%d: %s\n", thisarg, argv[thisarg]);
>> ++thisarg;
>> }
>> return 0;
>> }
>
> Readers may wish to disregard the above program from the troll
> Richard Heathfield. Like every other program of his that I've
> seen, the above contains a beginner-level bug.
>
> See the new thread "Even more proof of errors going uncorrected"
> for details.
>
> Yours,
> Han from China
>
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Bartc
> Han from China wrote:
>> Richard Heathfield wrote:
>>> #include <stdio.h>
>>>
>>> int main(int argc, char **argv)
>>> {
>>> int thisarg = 1; /* skip the uninteresting program name */
>
> here there should be a test:
>
> if (argc < 2) {
> printf("Missing arguments!\n");
> return 0;
> }
>
> Now, this is quite elementary. I do not see why Mr Heathfield poses as
> the pope here if he posts code like this.
This is not wrong though: we don't know if the program requires any more
than 0 arguments; it just prints the ones that are given.
>>> while(argv[thisarg] != NULL)
>
> That should be
>
> while (thisarg < argc)
Why? What's wrong with the first form, other than being inefficient?
--
Bartc
jacob navia
> jacob navia wrote:
>> Han from China wrote:
>>> Richard Heathfield wrote:
>>>> #include <stdio.h>
>>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>> int thisarg = 1; /* skip the uninteresting program name */
>>
>> here there should be a test:
>>
>> if (argc < 2) {
>> printf("Missing arguments!\n");
>> return 0;
>> }
>>
>> Now, this is quite elementary. I do not see why Mr Heathfield poses as
>> the pope here if he posts code like this.
>
> This is not wrong though: we don't know if the program requires any more
> than 0 arguments; it just prints the ones that are given.
>
Hey Bart!
You fall into the same bug as Heathfield!
Look again: You see that "thisarg" is initialized to 1 ???????
If argc is zero you are indexing beyond the array length...
>>>> while(argv[thisarg] != NULL)
>>
>> That should be
>>
>> while (thisarg < argc)
>
> Why? What's wrong with the first form, other than being inefficient?
>
True, not a true bug
Just inefficient. Note that I said:
That should be
not that that was a bug. Only the first is a bug
Richard
> On 1 Mar, 23:07, raeiko <mariacastri...@gmail.com> wrote:
>
>> i urgently need your help
>
> :-(
>
>> I have to write a C program that reads a series of strings and prints
>> only those that end with the letters “ed.” To enter the string i
>> should use the command line prompt and when i press the return key,
>> the program should print the string if it ends in "ed" and prompt for
>> another string if it doesn't.
>
> I think other posters have seriously misunderstood you.
> This is plainly an interactive program (no command line arguments
> needed)
One other poster.
Bartc
"jacob navia" <ja...@nospam.org> wrote in message
news:49abe7c3$0$12620$ba4a...@news.orange.fr...
> Bartc wrote:
>> jacob navia wrote:
>>> Han from China wrote:
>>>> Richard Heathfield wrote:
>>>>> #include <stdio.h>
>>>>>
>>>>> int main(int argc, char **argv)
>>>>> {
>>>>> int thisarg = 1; /* skip the uninteresting program name */
>>>
>>> here there should be a test:
>>>
>>> if (argc < 2) {
>>> printf("Missing arguments!\n");
>>> return 0;
>>> }
>>>
>>> Now, this is quite elementary. I do not see why Mr Heathfield poses as
>>> the pope here if he posts code like this.
>>
>> This is not wrong though: we don't know if the program requires any more
>> than 0 arguments; it just prints the ones that are given.
>>
>
> Hey Bart!
>
> You fall into the same bug as Heathfield!
>
> Look again: You see that "thisarg" is initialized to 1 ???????
> If argc is zero you are indexing beyond the array length...
OK, but when would argc be zero?
The assumption seems to be that the program name would always be the first
argument and that argc will always be 1 or more.
--
Bartc
jacob navia
> The assumption seems to be that the program name would always be the
> first argument and that argc will always be 1 or more.
>
This is NOT justified, the standard explicitely accepts argc == 0.
Lew Pitcher
>
> "jacob navia" <ja...@nospam.org> wrote in message
> news:49abe7c3$0$12620$ba4a...@news.orange.fr...
>> Bartc wrote:
>>> jacob navia wrote:
>>>> Han from China wrote:
>>>>> Richard Heathfield wrote:
>>>>>> #include <stdio.h>
>>>>>>
>>>>>> int main(int argc, char **argv)
>>>>>> {
>>>>>> int thisarg = 1; /* skip the uninteresting program name */
>>>>
>>>> here there should be a test:
>>>>
>>>> if (argc < 2) {
>>>> printf("Missing arguments!\n");
>>>> return 0;
>>>> }
>>>>
>>>> Now, this is quite elementary. I do not see why Mr Heathfield poses as
>>>> the pope here if he posts code like this.
>>>
>>> This is not wrong though: we don't know if the program requires any more
>>> than 0 arguments; it just prints the ones that are given.
>>>
>>
>> Hey Bart!
>>
>> You fall into the same bug as Heathfield!
>>
>> Look again: You see that "thisarg" is initialized to 1 ???????
>> If argc is zero you are indexing beyond the array length...
>
> OK, but when would argc be zero?
This isn't the usual case, but the standards permit it, and it /can/ happen.
In a POSIX environment, an executing program (called a "process") can morph
itself into another program by invoking a special (non-C-standard)
operating system function called execl(); This special function takes as
it's arguments the location of the new program, and a list arguments to be
passed to the new program through the argc/argv mechanism. This list is
permitted to be empty, giving an argc == 0 to the new program.
So, If I have a program like
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
printf("In program SHOWARGS\n");
if (argc < 0)
{
printf("Impossible - argc is less than zero (argc == %d)\n",argc);
return EXIT_FAILURE;
}
else if (argc == 0)
{
printf("Unlikely but possible - argc is equal to zero "
"(argc == %d)\n",argc);
return EXIT_SUCCESS;
}
else if (argc > 0)
{
printf("Normal - argc is greater than zero (argc == %d)\n",argc);
while (argc--)
printf("Argument: \"%s\"\n",*argv++);
return EXIT_SUCCESS;
}
else
{
printf("Impossible - argc is completely unevaluable "
"(argc == %d)\n",argc);
return EXIT_FAILURE;
}
return EXIT_FAILURE;
}
that, when executed, returns results like...
~/code/args $ showargs a b c
In program SHOWARGS
Normal - argc is greater than zero (argc == 4)
Argument: "showargs"
Argument: "a"
Argument: "b"
Argument: "c"
~/code/args $ showargs
In program SHOWARGS
Normal - argc is greater than zero (argc == 1)
Argument: "showargs"
and I invoke it from a program that uses an execl() that looks like
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("./showargs",NULL);
return EXIT_FAILURE;
}
I will get an invocation of the target program where argc == 0, like
~/code/args $ noargs
In program SHOWARGS
Unlikely but possible - argc is equal to zero (argc == 0)
> The assumption seems to be that the program name
what ever that is. The standards don't define what significance the "program
name" has; it /could/ be the fully qualified path to the program executable
on some storage media, or it /could/ be "foobarbaz". Or even "".
> would always be the first argument and that argc will always be 1 or more.
That assumption would be wrong. The standards don't requre argc to be
greater than zero, and specifically permit it to be zero. The only caveat
that comes close is that argv[argc] must be equal to NULL, meaning that
when argc == 0, there still needs to be an argv[] array, and argv[0] must
be == NULL
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Mark Wooding
> The assumption seems to be that the program name would always be the
> first argument and that argc will always be 1 or more.
Unfortunately it's a false assumption.
Here's a simple (and, I think, portable) C program.
#include <stdio.h>
int main(int argc, char *argv[])
{
int i;
if (!argc)
fprintf(stderr, "warning: argc == 0!\n");
else for (i = 0; i < argc; i++)
printf("%4d: %s\n", i, argv[i]);
return (0);
}
If I compile this as `args', I can run it from the shell and it does
what I expect.
[ponder /tmp/mwooding]./args
0: ./args
[ponder /tmp/mwooding]./args hello world
0: ./args
1: hello
2: world
If I cared, I'd write more error checking. It works well enough for
this demonstration.
Here's a non-portable program.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
if (argc < 2) {
fprintf(stderr, "not enough arguments (want PROG ARGS...)\n");
exit(EXIT_FAILURE);
}
execvp(argv[1], argv + 2);
perror("exec");
return (EXIT_FAILURE);
}
I'll compile this as `execit' on my system. Now:
[ponder /tmp/mwooding]./execit ./args foo bar baz
0: foo
1: bar
2: baz
[ponder /tmp/mwooding]./execit ./args mumble
0: mumble
[ponder /tmp/mwooding]./execit ./args
warning: argc == 0!
Oops!
-- [mdw]
Keith Thompson
[...]
>> Richard Heathfield wrote:
>>> #include <stdio.h>
>>>
>>> int main(int argc, char **argv)
>>> {
>>> int thisarg = 1; /* skip the uninteresting program name */
>
> here there should be a test:
>
> if (argc < 2) {
> printf("Missing arguments!\n");
> return 0;
> }
>
> Now, this is quite elementary. I do not see why Mr Heathfield poses as
> the pope here if he posts code like this.
I don't recall Richard ever posing as the pope. If he has, I'd like
to see pictures.
If you think he's made a mistake, why not just point it out? Richard
has a long history of accepting corrections gracefully.
Oh, and speaking of corrections, the above should be:
if (argc < 2) {
fprintf(stderr, "MIssing arguments!\n");
return EXIT_FAILURE;
}
(I predict that you will interpret this as a personal attack.)
--
Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard
> jacob navia <ja...@nospam.org> writes:
> [...]
>>> Richard Heathfield wrote:
>>>> #include <stdio.h>
>>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>> int thisarg = 1; /* skip the uninteresting program name */
>>
>> here there should be a test:
>>
>> if (argc < 2) {
>> printf("Missing arguments!\n");
>> return 0;
>> }
>>
>> Now, this is quite elementary. I do not see why Mr Heathfield poses as
>> the pope here if he posts code like this.
>
> I don't recall Richard ever posing as the pope. If he has, I'd like
> to see pictures.
>
> If you think he's made a mistake, why not just point it out? Richard
> has a long history of accepting corrections gracefully.
>
> Oh, and speaking of corrections, the above should be:
>
> if (argc < 2) {
> fprintf(stderr, "MIssing arguments!\n");
> return EXIT_FAILURE;
> }
>
> (I predict that you will interpret this as a personal attack.)
No it shouldn't. It's up to him what integer he returns and to what
stream he outputs error messages. You also probably meant "Missing
argument!\n". There is no such word as "MIssing" in the English language
and we get easily confused.
Antoninus Twink
> jacob navia <ja...@nospam.org> writes:
>> if (argc < 2) {
>> printf("Missing arguments!\n");
>> return 0;
>> }
> Oh, and speaking of corrections, the above should be:
>
> if (argc < 2) {
> fprintf(stderr, "MIssing arguments!\n");
> return EXIT_FAILURE;
> }
Since stdlib.h is not #included in the above program, Jacob's version
has the advantage of not incorporating a constraint violation for the
undeclared identifier EXIT_FAILURE. He also followed standard English
capitalization rules in his error message.
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
...
>No it shouldn't. It's up to him what integer he returns and to what
>stream he outputs error messages. You also probably meant "Missing
>argument!\n". There is no such word as "MIssing" in the English language
>and we get easily confused.
So true. So obvious too. Hard to believe that a formerly great
nitpicker like Mr. Thompson could let something like this slide.
>I predict that you will interpret this as a personal attack.
Guffaw! I just love infinite reducibility!
Kenny McCormack
Antoninus Twink <nos...@nospam.invalid> wrote:
...
>Since stdlib.h is not #included in the above program, Jacob's version
>has the advantage of not incorporating a constraint violation for the
>undeclared identifier EXIT_FAILURE. He also followed standard English
>capitalization rules in his error message.
Indeed. Keith's really losing it lately, isn't he?
Richard Heathfield
> Han from China wrote:
>> Richard Heathfield wrote:
>>> #include <stdio.h>
>>>
>>> int main(int argc, char **argv)
>>> {
>>> int thisarg = 1; /* skip the uninteresting program name */
>
> here there should be a test:
>
> if (argc < 2) {
> printf("Missing arguments!\n");
> return 0;
> }
Fine. (The return value is a matter of taste. 0 is certainly
defensible; EXIT_FAILURE would be a reasonable alternative,
requiring an additional #include.)
>
> Now, this is quite elementary.
Yes, it is.
> I do not see why Mr Heathfield
> poses as the pope here if he posts code like this.
Your statement about papal posing is factually incorrect. As for the
code, it's fine as it is. It's true that my reply doesn't address
the situation where argc can be 0, but so what? K&R don't discuss
that (rather abstruse) possibility either, and they even present a
program which will break if argc is 0, but I don't see you accusing
/them/ of impersonating the Pope.
<snip>
Han from China
> See the new thread "Even more proof of errors going uncorrected"
> for details.
I'll put it in here for the sake of completeness:
---------------------------------------------------------------------------
Subject: Even more proof of errors going uncorrected
Richard Heathfield wrote:
> argv[0] represents the name of the program (in some implementation-
> specific way - it might be the program's name, or perhaps the name
> with the full path as a prefix, or something bizarre like a process
> ID, but it'll be *something*, anyway - and normally we'll just ignore
> it).
[From thread "c program - command line prompt - need help"]
Wrong on two counts.
First, the Standard says that argc may be 0, in which case argv[0]
will be a null pointer.
Second, even if argc > 0, the name of the program needn't be
available, in which case argv[0][0] will be a null character.
References: 5.1.2.2.1{2}
> To display each of these arguments in turn (a common student
> exercise), we can do this:
>
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> int thisarg = 1; /* skip the uninteresting program name */
> while(argv[thisarg] != NULL)
> {
> printf("%d: %s\n", thisarg, argv[thisarg]);
> ++thisarg;
> }
> return 0;
>
> }
And what happens if argc is 0, Heathfield? Boom!
Student name: Richard Heathfield
Grade: F
Comments: Poor grasp of basic C concepts.
It's been half a day since you posted your misinformation. Where
are all the nitpicking pouncers? That's right -- dead silence.
Remind us again why you and Thompson strike up an authoritarian tone
on this newsgroup and try to impose your will on the rest of the
posters. You definitely aren't C experts, that's for sure (neither
am I, for the record, which makes this whole thing even more amusing!).
This newsgroup really is in the gutter.
I refer readers to my previous thread:
More proof of errors going uncorrected among the "regs"
In that one, I blow the lid off the Thompson case and expose the fact
that his domineering personality has led to a sad state of affairs for
a once trusted source of technical information.
This one was for you, Billy Pursell! "Technical accuracy" my ass.
It's sickening that Thompson, Heathfield, & Co. get a free pass on this
newsgroup while every other poster has his posts put under their
stupid nitpicking microscope.
If I may quote Kenny McCormack:
So, and this is the key point, in order for the system to work, where
the regs can continue to rule and can continue to have their fun bashing
the newbs, it has to be setup such that the nitpicks cannot flow back up
the pipe. It has to be a one-way pipe - or else, as I say, the system
will fall apart. Thus, you can't hold the regs to the same brutal
standards to which the rank-and-file are held.
---------------------------------------------------------------------------
Han from China
> As for the code, it's fine as it is. It's true that my reply doesn't
> address the situation where argc can be 0, but so what?
Then it's *not* fine as it is, you twit.
Cue the graceful acceptance! Here it comes...
Antoninus Twink
> Richard Heathfield wrote:
>> As for the code, it's fine as it is. It's true that my reply doesn't
>> address the situation where argc can be 0, but so what?
>
> Then it's *not* fine as it is, you twit.
>
> Cue the graceful acceptance! Here it comes...
I'm on tenterhooks! Any minute now, that celebrated graceful
Heathfieldian acceptance of correction will appear!
Han from China
> Richard has a long history of accepting corrections gracefully.
The above is a lie.
Evidence: January thread called
(part 9) More Schildt-like errors in Dicky Heathen's book
You can see Heathfield's true colors in that thread. I recommend
all readers who value technical integrity have a read of that thread,
or at least the Heathfield posts in it.
The evidence is there. You don't need to hear it from me.
CBFalconer
> jacob navia said:
>
... snip ...
>
>> I do not see why Mr Heathfield
>> poses as the pope here if he posts code like this.
>
> Your statement about papal posing is factually incorrect. As for
> the code, it's fine as it is. It's true that my reply doesn't
> address the situation where argc can be 0, but so what? K&R don't
> discuss that (rather abstruse) possibility either, and they even
> present a program which will break if argc is 0, but I don't see
> you accusing /them/ of impersonating the Pope.
Then you also omit the fact that, from the time of Henry VIII until
comparatively recently, one of the precepts of the English nation
has been that the Pope has been replaced by the reigning monarch.
(There were a few minor periods when this did not apply, largely
involving Stuarts)
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Han from China
<snip off-topic English history>
Wow, this thread is really covering all bases, isn't it? We
get Falconer's hypocrisy in there as a bonus!
Han from China
> Indeed. Keith's really losing it lately, isn't he?
Yeah, it looks as if the Thompson/Heathfield attempts to ostracize
people on this newsgroup (instead of simply maintaining a private
mental killfile and letting others decide for themselves whose
posts are worth reading) have come back to bite them in the ass.
Now we know what Thompson and Heathfield mean when they say an
exception has been made on this newsgroup for K&R C -- the K stands
for Keith, the R stands for Richard, and the need for an exception
goes without saying.
Richard Heathfield
> Richard Heathfield wrote:
>> jacob navia said:
>>
> ... snip ...
>>
>>> I do not see why Mr Heathfield
>>> poses as the pope here if he posts code like this.
>>
>> Your statement about papal posing is factually incorrect. As for
>> the code, it's fine as it is. It's true that my reply doesn't
>> address the situation where argc can be 0, but so what? K&R don't
>> discuss that (rather abstruse) possibility either, and they even
>> present a program which will break if argc is 0, but I don't see
>> you accusing /them/ of impersonating the Pope.
>
> Then you also omit the fact that, from the time of Henry VIII
> until comparatively recently, one of the precepts of the English
> nation has been that the Pope has been replaced by the reigning
> monarch.
What on earth are you talking about, and why?
Golden California Girls
> It's true that my reply doesn't address
> the situation where argc can be 0,
How can I get argc to be zero?
Phil Carmody
a) Use a system which permits that.
b) Use the technique that that system provides.
Unixes that have influenced or have been influenced by POSIX
may be such systems. You will be violating a "should" in SunOS,
but only violating a "should conventionally" in BSD and Lunix.
But we're out of scope of C now.
Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Kaz Kylheku
E.g. using the various exec functions on a POSIX system.
Mark Wooding
> Golden California Girls <gldnc...@aol.com.mil> writes:
>> How can I get argc to be zero?
>
> a) Use a system which permits that.
> b) Use the technique that that system provides.
See also code I posted earlier in the thread.
> Unixes that have influenced or have been influenced by POSIX
> may be such systems. You will be violating a "should" in SunOS,
> but only violating a "should conventionally" in BSD and Lunix.
Of course, `should' means `don't have to'. If you're writing a program
which is meant to be able to cope in a potentially hostile environment
(e.g., a setuid program on Unix) then it's a bad idea to assume that
argc > 0.
> But we're out of scope of C now.
Indeed. The C points are that (a) it's theoretically possible, because
the C standard permits argc to be zero, and (b) it's /practically/
possible, because some (common!) systems can arrange for argc to be
zero.
-- [mdw]
Lew Pitcher
(gldnc...@aol.com.mil) wrote:
I have already posted some sample C code (one standard C program that is
capable of receiving an argc == 0, and a non-C-standard, POSIX-standard C
program that invokes the other program with argc == 0), and a demonstration
of same. See backthread for details.
Nate Eldredge
> Golden California Girls <gldnc...@aol.com.mil> writes:
>> Richard Heathfield wrote:
>>> It's true that my reply doesn't address
>>> the situation where argc can be 0,
>>
>> How can I get argc to be zero?
>
> a) Use a system which permits that.
> b) Use the technique that that system provides.
>
> Unixes that have influenced or have been influenced by POSIX
> may be such systems. You will be violating a "should" in SunOS,
> but only violating a "should conventionally" in BSD and Lunix.
> But we're out of scope of C now.
Incidentally, I believe that on old Linux systems, having argc == 0
would cause the program to print its shared library dependencies and
exit, rather than running main(). This was how the ldd program worked.
Mark Wooding
> Incidentally, I believe that on old Linux systems, having argc == 0
> would cause the program to print its shared library dependencies and
> exit, rather than running main(). This was how the ldd program worked.
You're right. From Linux's ldd(1) manpage:
: BUGS
: [...]
: ldd does not work with some extremely old a.out programs which
: were built before ldd support was added to the compiler releases.
: If you use ldd on one of these programs, the program will attempt
: to run with argc = 0 and the results will be unpredictable.
I'd be tempted to say that the results will be fairly predictable in
practice, but not especially desirable...
-- [mdw]
Richard Tobin
Nate Eldredge <na...@vulcan.lan> wrote:
>Incidentally, I believe that on old Linux systems, having argc == 0
>would cause the program to print its shared library dependencies and
>exit, rather than running main(). This was how the ldd program worked.
Really? In SunOS (where that style of shared library originated) it
worked by setting the environment variable LD_TRACE_LOADED_OBJECTS,
and that has worked on the Linux systems I've tried.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Lew Pitcher
(ric...@cogsci.ed.ac.uk) wrote:
> In article <8663iqtv...@vulcan.lan>,
> Nate Eldredge <na...@vulcan.lan> wrote:
>
>>Incidentally, I believe that on old Linux systems, having argc == 0
>>would cause the program to print its shared library dependencies and
>>exit, rather than running main(). This was how the ldd program worked.
>
> Really? In SunOS (where that style of shared library originated) it
> worked by setting the environment variable LD_TRACE_LOADED_OBJECTS,
> and that has worked on the Linux systems I've tried.
<semi_off_topic>
The program I posted earlier in this thread gives the expected
(programmatically defined) results when argc == 0, even though I compiled
and ran it on a Linux based system. Likewise, ldd produces the expected
list of dynamic libraries, and not program's programmatically defined argc
== 0 behaviour. So, at least on /my/ Linux system, the listing of dynamic
libraries is not governed by whether or not argc == 0.
However, when I set the LD_TRACE_LOADED_OBJECTS environment variable to any
value, all of the programs (source supplied previously) produce dll lists
exclusively, and /do not/ exhibit the expected argc == 0 programmatically
defined behaviour.
My suspicion is that the portion of the Linux C runtime library that
implements the initial function call to main() is detecting the presence or
absence of the LD_TRACE_LOADED_OBJECTS environment variable, and invoking
either main() (on it's absence or null value) or a builtin dll dumper (on
it's presence with an initial value).
In any case, without this implementation-specific environment variable,
Linux gcc-compiled standard C code seems to handle argc == 0 conditions as
per the C standard.
</semi_off_topic>
Nate Eldredge
> In article <8663iqtv...@vulcan.lan>,
> Nate Eldredge <na...@vulcan.lan> wrote:
>
>>Incidentally, I believe that on old Linux systems, having argc == 0
>>would cause the program to print its shared library dependencies and
>>exit, rather than running main(). This was how the ldd program worked.
>
> Really? In SunOS (where that style of shared library originated) it
> worked by setting the environment variable LD_TRACE_LOADED_OBJECTS,
> and that has worked on the Linux systems I've tried.
This is the a.out format we're talking about, which it appears was used
by Linux prior to version 1.2 (circa 1995). If you look at
sysdeps/unix/sysv/linux/lddlibc4.c in the glibc source, you'll see this
is what it does.
Actually, it calls
execv (filename, &argv[argc])
but of course argv[argc] is NULL. Seems they could have written it more
clearly.
It also sets the environment variable __LDD_ARGV0 to the program's name,
perhaps so that the program being run can include that in the shared
library information message (since it can't get it from argv[0]). But I
don't believe setting that variable alone was sufficient to provoke the
appropriate behavior.
Nowadays, with the ELF format, ldd works via the LD_TRACE_LOADED_OBJECTS
variable, as you describe.
Antoninus Twink
> Richard Heathfield wrote:
>> It's true that my reply doesn't address the situation where argc can
>> be 0,
So your reply is not portable. The next time you go lecturing others on
portability, let's remember this occasion when you said "Portability? I
don't give a damn."
> How can I get argc to be zero?
Here's a simple example:
#include<stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
{
if(argc)
switch(fork()) {
case -1:
perror("fork");
return 1;
case 0:
execlp(*argv, (char *) 0);
}
else
puts("argc is 0");
return 0;
}
Kenny McCormack
Antoninus Twink <nos...@nospam.invalid> wrote:
>On 3 Mar 2009 at 5:16, Golden California Girls wrote:
>> Richard Heathfield wrote:
>>> It's true that my reply doesn't address the situation where argc can
>>> be 0,
>
>So your reply is not portable. The next time you go lecturing others on
>portability, let's remember this occasion when you said "Portability? I
>don't give a damn."
>
>> How can I get argc to be zero?
>
>Here's a simple example:
(example clipped - see original if needed)
You don't even have to work that hard. In C (but not, so I am told, C++),
recursive main() is legal. So, all you have to do is have main() call
itself, passing 0 as the first parameter, and Boom! goes Mr. Heathfield's
"solution".
Kaz Kylheku
> You don't even have to work that hard. In C (but not, so I am told, C++),
> recursive main() is legal. So, all you have to do is have main() call
> itself, passing 0 as the first parameter, and Boom! goes Mr. Heathfield's
> "solution".
That's poor reasoning, because a recursive call to main is not subject to the
requirements that apply to the implementation's initial call to main.
For instance, this is a valid recursive call to main:
main(-1, NULL);
Richard Heathfield
> On 2009-03-03, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> You don't even have to work that hard. In C (but not, so I am
>> told, C++),
>> recursive main() is legal. So, all you have to do is have main()
>> call itself, passing 0 as the first parameter, and Boom! goes Mr.
>> Heathfield's "solution".
>
> That's poor reasoning,
What did you expect, given the source? From what is quoted above,
it's quite clear that Mr McC remains incapable of reading for
comprehension, let alone making intelligent responses.
If you feed trolls, don't be surprised if they get fat.
Antoninus Twink
> That's poor reasoning, because a recursive call to main is not subject to the
> requirements that apply to the implementation's initial call to main.
I don't understand what you mean.
There is no requirement that the implementation's initial call to main
set arg to a nonzero value, which is why Heathfield's "solution" is
fatally flawed.
Richard
> Kaz Kylheku said:
>
>> On 2009-03-03, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> You don't even have to work that hard. In C (but not, so I am
>>> told, C++),
>>> recursive main() is legal. So, all you have to do is have main()
>>> call itself, passing 0 as the first parameter, and Boom! goes Mr.
>>> Heathfield's "solution".
>>
>> That's poor reasoning,
>
> What did you expect, given the source? From what is quoted above,
> it's quite clear that Mr McC remains incapable of reading for
> comprehension, let alone making intelligent responses.
>
> If you feed trolls, don't be surprised if they get fat.
Strange. From your indignant self posturing and general arrogant
demeanour one could almost believe your solution was in fact portable
and reliable when, plainly, it was not.
Richard Tobin
>Nowadays, with the ELF format, ldd works via the LD_TRACE_LOADED_OBJECTS
>variable, as you describe.
No doubt Linux works (and worked) as you describe, but there is no
necessary connection between the object file format and the mechanism
used by ldd. When SunOS introduced shared libraries, it too used
a.out format, but nonetheless used LD_TRACE_LOADED_OBJECTS.
CBFalconer
> CBFalconer said:
>> Richard Heathfield wrote:
>>> jacob navia said:
>>>
>> ... snip ...
>>>
>>>> I do not see why Mr Heathfield
>>>> poses as the pope here if he posts code like this.
>>>
>>> Your statement about papal posing is factually incorrect. As for
>>> the code, it's fine as it is. It's true that my reply doesn't
>>> address the situation where argc can be 0, but so what? K&R don't
>>> discuss that (rather abstruse) possibility either, and they even
>>> present a program which will break if argc is 0, but I don't see
>>> you accusing /them/ of impersonating the Pope.
>>
>> Then you also omit the fact that, from the time of Henry VIII
>> until comparatively recently, one of the precepts of the English
>> nation has been that the Pope has been replaced by the reigning
>> monarch.
>
> What on earth are you talking about, and why?
Papal posing (you enlarged on it) and English history.
Richard Heathfield
> Richard Heathfield wrote:
>> CBFalconer said:
>>> Richard Heathfield wrote:
>>>> jacob navia said:
>>>>
>>> ... snip ...
>>>>
>>>>> I do not see why Mr Heathfield
>>>>> poses as the pope here if he posts code like this.
>>>>
>>>> Your statement about papal posing is factually incorrect. As
>>>> for the code, it's fine as it is. It's true that my reply
>>>> doesn't address the situation where argc can be 0, but so what?
>>>> K&R don't discuss that (rather abstruse) possibility either,
>>>> and they even present a program which will break if argc is 0,
>>>> but I don't see you accusing /them/ of impersonating the Pope.
>>>
>>> Then you also omit the fact that, from the time of Henry VIII
>>> until comparatively recently, one of the precepts of the English
>>> nation has been that the Pope has been replaced by the reigning
>>> monarch.
>>
>> What on earth are you talking about, and why?
>
> Papal posing (you enlarged on it) and English history.
Um, right. Okay. Whatever. I think you might find that that was a
bit of hyperbole on Jacob's part, reflected in my reply. I think
you might find, in fact, that neither of us intended for the
expression to be taken entirely literally.
CBFalconer
I gather you took mine as a serious comment. I thought you were
considerably more intelligent than that. Oh well.
Richard Heathfield
I treated it about as seriously as I treat most of your replies
nowadays - but I infer from your latest reply that you intended it
humorously. If that inference is accurate, I have to say that the
humour escapes me.
> I thought you were considerably more intelligent than that. Oh
> well.
I'm not overly concerned about your opinion of my intelligence.