Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #98817 > unrolled thread

[command line arguments] more elegant solution ??

Back to article view | Back to comp.lang.c

Contents

  [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 07:56 -0800
    Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 16:47 +0000
      Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 09:16 -0800
        Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 09:26 -0800
          Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 19:05 +0000
            Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 11:15 -0800
              Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 11:53 -0800
                Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 20:03 +0000
                  Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 12:26 -0800
                    Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 12:33 -0800
                    Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 20:33 +0000
                      Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 12:35 -0800
                        Re: [command line arguments] more elegant solution ?? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 16:06 -0500
                          Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 13:11 -0800
                            Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 13:20 -0800
                            Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 13:25 -0800
                        Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:32 +0000
                          Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 13:44 -0800
                            Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 13:47 -0800
                              Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:56 +0000
                                Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 14:04 -0800
                            Re: [command line arguments] more elegant solution ?? Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:07 +0100
                              Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 14:15 -0800
                                Re: [command line arguments] more elegant solution ?? Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:32 +0100
                                  Re: [command line arguments] more elegant solution ?? jameskuyper@verizon.net - 2016-12-11 14:42 -0800
                                    Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 14:52 -0800
                                Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 14:40 -0800
                                  Re: [command line arguments] more elegant solution ?? jameskuyper@verizon.net - 2016-12-11 14:55 -0800
                                  Re: [command line arguments] more elegant solution ?? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:44 -0500
                            Re: [command line arguments] more elegant solution ?? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:20 +0000
                              Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 15:28 -0800
                                Re: [command line arguments] more elegant solution ?? jameskuyper@verizon.net - 2016-12-11 16:28 -0800
        Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 18:57 +0000
    Re: [command line arguments] more elegant solution ?? Barry Schwarz <schwarzb@dqel.com> - 2016-12-11 10:04 -0800
      Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 11:25 -0800
    Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-11 18:29 +0000
      Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 11:25 -0800
      Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 20:30 +0000
        Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-11 23:43 +0000
          Re: [command line arguments] more elegant solution ?? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 19:02 -0500
            Re: [command line arguments] more elegant solution ?? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 19:13 -0500
              Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-12 00:55 +0000
                Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-12 01:02 +0000
                  Re: [command line arguments] more elegant solution ?? Keith Thompson <kst-u@mib.org> - 2016-12-11 19:02 -0800
                    Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-12 11:50 +0000
                      Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:46 +0000
                        Re: [command line arguments] more elegant solution ?? BartC <bc@freeuk.com> - 2016-12-12 14:43 +0000
                          Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 22:09 +0000
                      Re: [command line arguments] more elegant solution ?? Keith Thompson <kst-u@mib.org> - 2016-12-12 08:58 -0800
                Re: [command line arguments] more elegant solution ?? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 20:06 -0500
                Re: [command line arguments] more elegant solution ?? jameskuyper@verizon.net - 2016-12-11 17:37 -0800
                Re: [command line arguments] more elegant solution ?? Keith Thompson <kst-u@mib.org> - 2016-12-11 18:59 -0800
          Re: [command line arguments] more elegant solution ?? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 02:47 +0000
    Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-11 15:11 -0800
    Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-12 00:25 -0800
    Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-12 00:27 -0800
      Re: [command line arguments] more elegant solution ?? Barry Schwarz <schwarzb@dqel.com> - 2016-12-12 01:01 -0800
        Re: [command line arguments] more elegant solution ?? Dexterr <dejangru@gmail.com> - 2016-12-12 09:42 -0800
          Re: [command line arguments] more elegant solution ?? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:58 -0500
          Re: [command line arguments] more elegant solution ?? Barry Schwarz <schwarzb@dqel.com> - 2016-12-12 14:18 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#98953

On Sunday December 11 2016 19:02, in comp.lang.c, "Lew Pitcher"
<lew.pitcher@digitalfreehold.ca> wrote:

> On Sunday December 11 2016 18:43, in comp.lang.c, "BartC" <bc@freeuk.com>
> wrote:
> [snip]
>> But there is one thing that only occurs under Linux that could screw
>> things up (not here because there will be at least two other files).
>> 
>> If the 3rd parameter is *, and there happens to be one file in the
>> directory with a numeric name, such as 9177, that will then appear as a
>> valid argument. (You may have noticed a big thread in the python group
>> about this.)
> 
> Bart, as has been explained elsewhere, in more detail and in more polite
> language, your statement above is at best misleading, and at worst untrue.
> 
> Witness:
>   18:55 $ ls | wc -l
>   157
> 
> That's 157 files and directories in the current directory, including the
> source code Args.c
> 
>   18:55 $ cat Args.c
>   #include <stdio.h>
>   #include <stdlib.h>
> 
>   int main(int argc, char *argv[])
>   {
>     int argnum;
> 
>     printf("argc == %d\n",argc);
>     for (argnum = 0; argnum < argc; ++argnum)
>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
> 
>     return EXIT_SUCCESS;
>   }
> 
> 
> Simple program, wot? Just prints argc, and each given argument
> 
>   18:55 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
> 
> Compiles clean to C99 standards
> 
>   18:55 $ Args '*'
>   argc == 2
>   argv[0] -> "Args"
>   argv[1] -> "*"
> 
> Oops.... Passed * as argument, got * as argument.

And to illustrate permenant disable of globbing:
  19:08 $ bash -o noglob
We start in a -o noglob shell.
     
  19:08 $ ls | wc -l
  158

158 files and directories (now includes the previously compiled Args program,
but we will replace that with a fresh version)

  19:08 $ cat Args.c
  #include <stdio.h>
  #include <stdlib.h>

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

    printf("argc == %d\n",argc);
    for (argnum = 0; argnum < argc; ++argnum)
      printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);

    return EXIT_SUCCESS;
  }

Same bog-simple program to list passed-in arguments

  19:08 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c

Same successful compile to C99 standards

  19:08 $ Args *
  argc == 2
  argv[0] -> "Args"
  argv[1] -> "*"

Passed in argument *, got argument *
This time, no need to temporarily disable globbing in the commandline.

QED

> I said "at best, misleading", because you neglect to mention that, in Unix,
> globbing (expansion of wildcard parameters into filenames) is something done
> by the shell, not by the C runtime and (usually) not by the C program. It
> can be enabled or disabled on demand.
> 
> Please don't mislead the newbies.
> 
> [snip]


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#98959

On 12/12/2016 00:13, Lew Pitcher wrote:
> On Sunday December 11 2016 19:02, in comp.lang.c, "Lew Pitcher"
> <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Sunday December 11 2016 18:43, in comp.lang.c, "BartC" <bc@freeuk.com>
>> wrote:

>>> If the 3rd parameter is *, and there happens to be one file in the
>>> directory with a numeric name, such as 9177, that will then appear as a
>>> valid argument. (You may have noticed a big thread in the python group
>>> about this.)
>>
>> Bart, as has been explained elsewhere, in more detail and in more polite
>> language, your statement above is at best misleading, and at worst untrue.
>>
>> Witness:
18:55 $ ls | wc -l
>>   157
>>
>> That's 157 files and directories in the current directory, including the
>> source code Args.c
>>
>>   18:55 $ cat Args.c
>>   #include <stdio.h>
>>   #include <stdlib.h>
>>
>>   int main(int argc, char *argv[])
>>   {
>>     int argnum;
>>
>>     printf("argc == %d\n",argc);
>>     for (argnum = 0; argnum < argc; ++argnum)
>>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
>>
>>     return EXIT_SUCCESS;
>>   }
>>
>>
>> Simple program, wot? Just prints argc, and each given argument
>>
>>   18:55 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
>>
>> Compiles clean to C99 standards
>>
>>   18:55 $ Args '*'
>>   argc == 2
>>   argv[0] -> "Args"
>>   argv[1] -> "*"
>>
>> Oops.... Passed * as argument, got * as argument.
>

I tried your program, and I got 125 arguments:

  ...$ gcc c.c -oc
  ...$ ./c
  argc == 125
  ...

(How did you fix it so that you don't have to type "./" which drives me 
up the wall?)


> And to illustrate permenant disable of globbing:
>   19:08 $ bash -o noglob
> We start in a -o noglob shell.
>
>   19:08 $ ls | wc -l
>   158
>
> 158 files and directories (now includes the previously compiled Args program,
> but we will replace that with a fresh version)
>
>   19:08 $ cat Args.c
>   #include <stdio.h>
>   #include <stdlib.h>
>
>   int main(int argc, char *argv[])
>   {
>     int argnum;
>
>     printf("argc == %d\n",argc);
>     for (argnum = 0; argnum < argc; ++argnum)
>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
>
>     return EXIT_SUCCESS;
>   }
>
> Same bog-simple program to list passed-in arguments
>
>   19:08 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
>
> Same successful compile to C99 standards
>
>   19:08 $ Args *
>   argc == 2
>   argv[0] -> "Args"
>   argv[1] -> "*"
>
> Passed in argument *, got argument *
> This time, no need to temporarily disable globbing in the commandline.

>
> QED
>
>> I said "at best, misleading", because you neglect to mention that, in Unix,
>> globbing (expansion of wildcard parameters into filenames) is something done
>> by the shell, not by the C runtime and (usually) not by the C program. It
>> can be enabled or disabled on demand.

I said it was a Linux quirk. And while it may be possible to disable it 
(you said you did it temporarily, but didn't see how, unless you mean 
what you called the 'permanent' disablement), I don't see that as an 
answer. If you disable it, then a whole load of other things that depend 
on it will stop working, such as 'ls'.

>> Please don't mislead the newbies.

I'm a newbie when it comes to Linux. I don't know how to turn off 
globbing except using 'bash -o noglob' like your example (and don't know 
how to turn it on again except by restarting the terminal), but these 
are the sort of extra instructions you don't want to give with your program.

The instructions are to run it using 'program arg1 arg2', not do X 
first, run it, then do Y. Especially for a very unlikely possibility.

 >> Bart, as has been explained elsewhere, in more detail and in more polite
 >> language, your statement above is at best misleading, and at worst 
untrue.
 >>

Is it?

At the moment, I /can/ actually run a program as:

   ../program test.netlist ???

where 'program' sees argv[1] and argv[2] as "test.netlist 123" when 
there is a single file "123" in the directory. It's not a concern for a 
student exercise, but if those parameters were critical, I would have to 
take the possibility seriously.

Your user may have neglected the need to turn off globbing. And in fact 
it is an unreasonable requirement.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#98961

On 12/12/2016 00:55, BartC wrote:
> On 12/12/2016 00:13, Lew Pitcher wrote:

>>>   18:55 $ Args '*'
>>>   argc == 2
>>>   argv[0] -> "Args"
>>>   argv[1] -> "*"
>>>
>>> Oops.... Passed * as argument, got * as argument.
>>
>
> I tried your program, and I got 125 arguments:
>
>  ...$ gcc c.c -oc
>  ...$ ./c

Oh-oh, I meant ./c *

>  argc == 125
>  ...

But hang on... I've just noticed you put quotes around the argument:

 >>>   18:55 $ Args '*'

So THAT'S why you didn't get a big list of files.

Sorry, but that's not allowed. My objection was that if someone 
accidentally types * instead of a number, it might, in some extreme 
circumstances, go wrong. (In that the program thinks the input is valid.)

What you seem to be saying is, it's OK because people just have to make 
sure they accidentally type '*' instead! That would be very considerate 
of them...


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#98974

BartC <bc@freeuk.com> writes:
[...]
> But hang on... I've just noticed you put quotes around the argument:
>
>  >>>   18:55 $ Args '*'
>
> So THAT'S why you didn't get a big list of files.

I should have read this before posting my previous followup.

> Sorry, but that's not allowed.

Sorry, but that's just too bad.

>                                My objection was that if someone 
> accidentally types * instead of a number, it might, in some extreme 
> circumstances, go wrong. (In that the program thinks the input is valid.)

Yup.  That's the way it is.

> What you seem to be saying is, it's OK because people just have to make 
> sure they accidentally type '*' instead! That would be very considerate 
> of them...

I'm not sure what point you're making, but Unix shells work the
way they work, and complaining about that isn't going to do anyone
any good.  And unlike your complaining about C, it isn't even
vaguely topical.  I'm discussing it only because it's relevant to
how to invoke C programs.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#99034

On 12/12/2016 03:02, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> But hang on... I've just noticed you put quotes around the argument:
>>
>>  >>>   18:55 $ Args '*'
>>
>> So THAT'S why you didn't get a big list of files.
>
> I should have read this before posting my previous followup.
>
>> Sorry, but that's not allowed.
>
> Sorry, but that's just too bad.
>
>>                                My objection was that if someone
>> accidentally types * instead of a number, it might, in some extreme
>> circumstances, go wrong. (In that the program thinks the input is valid.)
>
> Yup.  That's the way it is.
>
>> What you seem to be saying is, it's OK because people just have to make
>> sure they accidentally type '*' instead! That would be very considerate
>> of them...
>
> I'm not sure what point you're making,

The point is clear enough, surely?

If everyone reads the specification and types in exactly what is 
expected, then a verification program discussed in the OP is unnecessary.

But if there is the possibility that bad inputs can be given, then it 
will be possible that someone could, either inadvertently, accidentally 
or maliciously, type * - without quotes or an escape - and fool the 
program that it has to be given valid input.

Under those circumstances, you can't 'get around' the problem. Lew 
should just have said:

 > Yup.  That's the way it is.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99041

BartC <bc@freeuk.com> writes:
<snip>

> But if there is the possibility that bad inputs can be given, then it
> will be possible that someone could, either inadvertently,
> accidentally or maliciously, type * - without quotes or an escape -
> and fool the program that it has to be given valid input.
>
> Under those circumstances, you can't 'get around' the problem.

How do /you/ (or the super-safe systems you prefer) get around the
problem of people typing incorrect input either inadvertently or
maliciously?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99046

On 12/12/2016 13:46, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>
>> But if there is the possibility that bad inputs can be given, then it
>> will be possible that someone could, either inadvertently,
>> accidentally or maliciously, type * - without quotes or an escape -
>> and fool the program that it has to be given valid input.
>>
>> Under those circumstances, you can't 'get around' the problem.
>
> How do /you/ (or the super-safe systems you prefer) get around the
> problem of people typing incorrect input either inadvertently or
> maliciously?

It's a different issue. Ie. Driver error. Not like a massive schism 
suddenly appearing in the road.

You might argue that they are both driver error; in which case 
governments can save a lot of money on proper maintenance!

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#99141

BartC <bc@freeuk.com> writes:

> On 12/12/2016 13:46, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>
>>> But if there is the possibility that bad inputs can be given, then it
>>> will be possible that someone could, either inadvertently,
>>> accidentally or maliciously, type * - without quotes or an escape -
>>> and fool the program that it has to be given valid input.
>>>
>>> Under those circumstances, you can't 'get around' the problem.
>>
>> How do /you/ (or the super-safe systems you prefer) get around the
>> problem of people typing incorrect input either inadvertently or
>> maliciously?
>
> It's a different issue. Ie. Driver error. Not like a massive schism
> suddenly appearing in the road.

You can't get round it on your system either -- it's just that you think
the holes are smaller.  But you did not say that because you wanted a
politician's spin on it.  The much more modest claim, that the likely
accidents on one are more serious than the likely accidents on the other
was not enough.  On the one you don't like, "you can't get round the
problem" (as if you can on /any/ system).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99080

BartC <bc@freeuk.com> writes:
> On 12/12/2016 03:02, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
[...]
>>> What you seem to be saying is, it's OK because people just have to make
>>> sure they accidentally type '*' instead! That would be very considerate
>>> of them...
>>
>> I'm not sure what point you're making,
>
> The point is clear enough, surely?
>
> If everyone reads the specification and types in exactly what is 
> expected, then a verification program discussed in the OP is unnecessary.
>
> But if there is the possibility that bad inputs can be given, then it 
> will be possible that someone could, either inadvertently, accidentally 
> or maliciously, type * - without quotes or an escape - and fool the 
> program that it has to be given valid input.
>
> Under those circumstances, you can't 'get around' the problem. Lew 
> should just have said:
>
>  > Yup.  That's the way it is.

I agree.  Turning off file globbing in the shell before running a
program is not, in my opinion, a reasonable thing to do.  Experienced
shell users will be unwilling to do it (except perhaps in a test
script), and inexperienced shell users will likely be confused by it.
If you want to pass a literal "*" to a program, quote it.

Bottom line: Assuming file globbing is enabled, typing
    ./program *
is exactly the same as typing
    ./program file1.txt file2.dat file3.foo
with a manually typed list of the names of all the files in the
current directory.  (I'm glossing over some details.)  If that's going
to create problems, don't type that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#98962

On Sunday December 11 2016 19:55, in comp.lang.c, "BartC" <bc@freeuk.com>
wrote:

> On 12/12/2016 00:13, Lew Pitcher wrote:
>> On Sunday December 11 2016 19:02, in comp.lang.c, "Lew Pitcher"
>> <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>> On Sunday December 11 2016 18:43, in comp.lang.c, "BartC" <bc@freeuk.com>
>>> wrote:
> 
>>>> If the 3rd parameter is *, and there happens to be one file in the
>>>> directory with a numeric name, such as 9177, that will then appear as a
>>>> valid argument. (You may have noticed a big thread in the python group
>>>> about this.)
>>>
>>> Bart, as has been explained elsewhere, in more detail and in more polite
>>> language, your statement above is at best misleading, and at worst untrue.
>>>
>>> Witness:
> 18:55 $ ls | wc -l
>>>   157
>>>
>>> That's 157 files and directories in the current directory, including the
>>> source code Args.c
>>>
>>>   18:55 $ cat Args.c
>>>   #include <stdio.h>
>>>   #include <stdlib.h>
>>>
>>>   int main(int argc, char *argv[])
>>>   {
>>>     int argnum;
>>>
>>>     printf("argc == %d\n",argc);
>>>     for (argnum = 0; argnum < argc; ++argnum)
>>>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
>>>
>>>     return EXIT_SUCCESS;
>>>   }
>>>
>>>
>>> Simple program, wot? Just prints argc, and each given argument
>>>
>>>   18:55 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
>>>
>>> Compiles clean to C99 standards
>>>
>>>   18:55 $ Args '*'
>>>   argc == 2
>>>   argv[0] -> "Args"
>>>   argv[1] -> "*"
>>>
>>> Oops.... Passed * as argument, got * as argument.
>>
> 
> I tried your program, and I got 125 arguments:
> 
>   ...$ gcc c.c -oc
>   ...$ ./c
>   argc == 125
>   ...
> 
> (How did you fix it so that you don't have to type "./" which drives me
> up the wall?)
> 
> 
>> And to illustrate permenant disable of globbing:
>>   19:08 $ bash -o noglob
>> We start in a -o noglob shell.
>>
>>   19:08 $ ls | wc -l
>>   158
>>
>> 158 files and directories (now includes the previously compiled Args
>> program, but we will replace that with a fresh version)
>>
>>   19:08 $ cat Args.c
>>   #include <stdio.h>
>>   #include <stdlib.h>
>>
>>   int main(int argc, char *argv[])
>>   {
>>     int argnum;
>>
>>     printf("argc == %d\n",argc);
>>     for (argnum = 0; argnum < argc; ++argnum)
>>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
>>
>>     return EXIT_SUCCESS;
>>   }
>>
>> Same bog-simple program to list passed-in arguments
>>
>>   19:08 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
>>
>> Same successful compile to C99 standards
>>
>>   19:08 $ Args *
>>   argc == 2
>>   argv[0] -> "Args"
>>   argv[1] -> "*"
>>
>> Passed in argument *, got argument *
>> This time, no need to temporarily disable globbing in the commandline.
> 
>>
>> QED
>>
>>> I said "at best, misleading", because you neglect to mention that, in
>>> Unix, globbing (expansion of wildcard parameters into filenames) is
>>> something done by the shell, not by the C runtime and (usually) not by the
>>> C program. It can be enabled or disabled on demand.
> 
> I said it was a Linux quirk.

It's not a quirk. It is a feature.
And it's not specific to Linux; it is mandated by the Single Unix Standard and
POSIX.

> And while it may be possible to disable it 
> (you said you did it temporarily, but didn't see how,

You didn't look.

To save you from having to read the post again, you temporarily disable
globbing in a Unix shell by surrounding the argument with singlequotes.
'*' will not glob

> unless you mean 
> what you called the 'permanent' disablement),

To permanently disable globbing at the shell, you run a shell with the noglob
option.

> I don't see that as an answer. If you disable it, then a whole load of other
> things that depend on it will stop working, such as 'ls'.

Bullshit.

Take a look again. ls worked fine in the noglob shell.

>>> Please don't mislead the newbies.
> 
> I'm a newbie when it comes to Linux. I don't know how to turn off
> globbing except using 'bash -o noglob' like your example (and don't know
> how to turn it on again except by restarting the terminal),

You
  exit
the shell

> but these 
> are the sort of extra instructions you don't want to give with your program.

So what? Does every car carry a copy of the Motor Vehicle Department's rules
and regulations for the road? Does every lightbulb come with a copy of the
Electrical Code?

The operating environment isn't /your/ concern. 

> The instructions are to run it using 'program arg1 arg2', not do X
> first, run it, then do Y. Especially for a very unlikely possibility.
> 
>  >> Bart, as has been explained elsewhere, in more detail and in more polite
>  >> language, your statement above is at best misleading, and at worst
> untrue.
>  >>
> 
> Is it?
> 
> At the moment, I /can/ actually run a program as:
> 
>    ../program test.netlist ???

And, so you get globbing.
Unless you don't want globbing, in that case you either run the program in a
noglob shell or you quote the argument
    ../program test.netlist '???'

> where 'program' sees argv[1] and argv[2] as "test.netlist 123" when
> there is a single file "123" in the directory. It's not a concern for a
> student exercise, but if those parameters were critical, I would have to
> take the possibility seriously.
> 
> Your user may have neglected the need to turn off globbing. And in fact
> it is an unreasonable requirement.

Sorry, fourty years of Unix shell operations says that you are wrong.


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#98964

On Sunday, December 11, 2016 at 7:55:36 PM UTC-5, Bart wrote:
> On 12/12/2016 00:13, Lew Pitcher wrote:
> > On Sunday December 11 2016 19:02, in comp.lang.c, "Lew Pitcher"
> > <lew.pitcher@digitalfreehold.ca> wrote:
...
> I tried your program, and I got 125 arguments:
> 
>   ...$ gcc c.c -oc
>   ...$ ./c
>   argc == 125
>   ...
> 
> (How did you fix it so that you don't have to type "./" which drives me 
> up the wall?)

Add "." to your path. This can be dangerous if your current directory is one
that malware has put executable files in with names that match common system
utilities: it will execute the corresponding file, with all of the same
permissions that you yourself have, instead of the corresponding system
utility. You can reduce the danger by add "." to the end of your path, rather
than the beginning. The danger is not completely eliminated: if you
accidentally mistype the command "enchant" as "enchamt", the existence of
/usr/bin/enchant won't protect you from executing an executable malware file in
the current directory named enchampt.

...
> >> I said "at best, misleading", because you neglect to mention that, in Unix,
> >> globbing (expansion of wildcard parameters into filenames) is something done
> >> by the shell, not by the C runtime and (usually) not by the C program. It
> >> can be enabled or disabled on demand.
> 
> I said it was a Linux quirk.

No, it isn't. It's a feature of certain shells. A shell doesn't have to support
that feature. There's a lot of shells available - there might already be one
that doesn't support this feature. If not, and you can write your own if you
want. Compared to implementing a compiler, implementing a shell is relatively
easy (unless you get overambitious).

> (you said you did it temporarily, but didn't see how, unless you mean 
> what you called the 'permanent' disablement), I don't see that as an 
> answer. If you disable it, then a whole load of other things that depend 
> on it will stop working, such as 'ls'.

ls will continue to work even with file globbing turned off. If you disable
file globbing, then any ls command that doesn't involve file-globbing
characters will continue to work as before, and any ls command that uses the
characters normally used to indicate file globbing will now correctly interpret
them as ordinary characters. Consider the command

    ls *.a

Normally that would give you a complete list of all files in the current
directory whose names start with something other than a '.', and end with ".a".
With file globbing turned off, it will continue to work, but it will instead
give you a directory listing for at most one file, the one whose literal name
is "*.a" (it's entirely permissible to create such a file) or complain that
there is no such file. If that's not what you want, don't turn off file
globbing.
    
> >> Please don't mislead the newbies.
> 
> I'm a newbie when it comes to Linux. I don't know how to turn off 
> globbing except using 'bash -o noglob' like your example (and don't know 
> how to turn it on again except by restarting the terminal), but these 
> are the sort of extra instructions you don't want to give with your program.

I'm most familiar with csh, where globbing can be turned off by using 

    set noglob

and it can be turned on again by typing

    unset noglob

The set command can be placed in your .cshrc file, in which case it will be
executed at the start of your shell. In bash, use "set -o noglob", the unset
command is unchanged.

[toc] | [prev] | [next] | [standalone]

#98972

BartC <bc@freeuk.com> writes:
> On 12/12/2016 00:13, Lew Pitcher wrote:
>> On Sunday December 11 2016 19:02, in comp.lang.c, "Lew Pitcher"
>> <lew.pitcher@digitalfreehold.ca> wrote:
[...]
>>> Witness:
> 18:55 $ ls | wc -l
>>>   157
>>>
>>> That's 157 files and directories in the current directory, including the
>>> source code Args.c
>>>
>>>   18:55 $ cat Args.c
>>>   #include <stdio.h>
>>>   #include <stdlib.h>
>>>
>>>   int main(int argc, char *argv[])
>>>   {
>>>     int argnum;
>>>
>>>     printf("argc == %d\n",argc);
>>>     for (argnum = 0; argnum < argc; ++argnum)
>>>       printf("argv[%d] -> \"%s\"\n",argnum,argv[argnum]);
>>>
>>>     return EXIT_SUCCESS;
>>>   }
>>>
>>>
>>> Simple program, wot? Just prints argc, and each given argument
>>>
>>>   18:55 $ cc -o Args -mtune=native -Wall -std=c99 -pedantic Args.c
>>>
>>> Compiles clean to C99 standards
>>>
>>>   18:55 $ Args '*'
>>>   argc == 2
>>>   argv[0] -> "Args"
>>>   argv[1] -> "*"
>>>
>>> Oops.... Passed * as argument, got * as argument.
>>
> I tried your program, and I got 125 arguments:
>
>   ...$ gcc c.c -oc
>   ...$ ./c
>   argc == 125
>   ...

If you had run the program exactly as you show it, you would have gotten
no arguments (argc==1).  I'll bet you actually ran
    ./c *
The * is expanded by the shell to a list of file names; there's
nothing the program can do about it.  That's just something you
have to be aware of.  (I won't argue about whether the behavior is
a good idea.)

> (How did you fix it so that you don't have to type "./" which drives me 
> up the wall?)

You can do that by adding the current directory, ".", to $PATH -- but I
strongly suggest *not* doing that.  If you must, be sure to add it to
the end of $PATH, not the beginning.  Otherwise you run the risk of
running arbitrary commands that happen to be in the current directory.
(Imagine you're in a directory containing a script called "ls" that does
something nasty.)

I'm sorry that typing "./" drives you up the wall; my honest advice is
to get used to it.

[...]

> I said it was a Linux quirk. And while it may be possible to disable it 
> (you said you did it temporarily, but didn't see how, unless you mean 
> what you called the 'permanent' disablement), I don't see that as an 
> answer. If you disable it, then a whole load of other things that depend 
> on it will stop working, such as 'ls'.

I hadn't even realized you could disable globbing; I probably knew about
it at some po, but I've never wanted to use it.

My own approach, and the one I recommend, is simply to be aware that *
expands to a list of file names, and to quote it if I want a literal *
character.  And of course to be aware of the other expansion rules.

If you insist on disabling and reenabling globbing, if you're using bash
you can do it with these commands:

    set -o noglob   # disable globbing
    set +o noglob   # re-enable globbing

Again, I don't recommmend this (and I won't argue about the ugly
syntax).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#98971

BartC <bc@freeuk.com> writes:

> On 11/12/2016 20:30, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>
>>> (Testing the third argument is a number is the only tricky bit. You
>>> might try converting it to a number using atol, converting back to a
>>> string using sprintf, and comparing that string with argv[2].)
>>
>> That does not always work (as I am sure you know) because there may be
>> leading space,
>
> Leading spaces are unlikely in this case.

Sure.

>>  a sign, zeros etc.  The simplest "student" solution is
>> probably just
>>
>>   sscanf(argv[i], "%d", &num) == 1
>>
>> For the test you ignore num, but it's likely that a later version will
>> actually use it.  A neat use of scanf failing to match input allows you
>> test the whole string:
>>
>>   sscanf(argv[i], "%d %c", &num, &ch) == 1
>>
>> If the number is followed by anything other than white-space characters,
>> the result will be 2 not 1.
>
> I don't know all the intricacies of sscanf.

Right, but others might like to find out more, so I think examples like
this help.

> But there is one thing that only occurs under Linux that could screw
> things up (not here because there will be at least two other files).

I don't think you can know that.  (I'm sure you don't mean .  and
.. here.)

> If the 3rd parameter is *, and there happens to be one file in the
> directory with a numeric name, such as 9177, that will then appear as
> a valid argument. (You may have noticed a big thread in the python
> group about this.)

If the third argument to the program is *, then that won't be seen as a
number, but if the user types * in that position then they might get a
number as the third argument.  In a way it's worse than that because, on
the other hand, they might /not/ get one -- you just can't say without
knowing the user's configuration.

> Even here, it's hard to completely rule out someone typing something
> with * or ? as the second argument, and ending up with input that
> passes the test, depending on some random pattern of filenames.

Agreed, but it's hard to rule out someone typing 24 when they mean 420
too.  And don't forget they might want to type something like $(tail -1
numbers) there too.  It's impossible to know what's meant and what
isn't.

> However the OP mustn't worry about this... (it's just a Linux quirk).

No I think the OP should be very concerned about it -- the chances are
it is a significant gap in the OP's knowledge.  Only by learning a good
shell will the OP become truly productive.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#98940

On Sunday, December 11, 2016 at 4:56:39 PM UTC+1, Dexterr wrote:
> Hi there. I have some questions about C programming concepts and solutions to ask you. 
> Yes, I am doing exercise for one very important exam in C programming. It is very important for 
> me to pass this exam. Thats true. My English is poor to describe how important that is.
> I desperately need a help to finish my example.
> 
> - NO I don’t want and I DON’t expect that someone do it for me.
> - I will do it, but I need some help in sense of directions how to solve some problems 
> - when I say “directions”, I mean I have some ideas and solutions but I am not sure are they good 
> - sometimes I find solutions but I don’t understand 100% why it works
> - my exam example is cool and I like it and I love it and I am happy to work on it
> 
> On the other side, I need and I want and I will understand some concepts in C programming
> and how it works. I am not satisfy to pass exam without understanding some issues. Yes, I have
> a lot of books, video tutorials and so on, but I need some live person with C programming experience
> to ask some questions and I will appreciate it a lot. On the other side, some newbies they read this will also learn something I hope so.
> 
> ———
> 
> - > This is one small par of my exam exercise. I need to write a code to start a program with 
>       three arguments from a command line. This arguments must be
> 
>   < (1)name of the program>  <(2)name of the input file> <(3) some number, some integer>
> 
> 
>  (1) - the name of the program is [./test]
> 
>  (2) - input file is netlist file [test.netlist]
> 
>  (3) - integer number is some number for omega [123]
> 
> The task is to print out “error” if someone type number of arguments != 3 
> or if he or she type the wrong name of the input file i.e. [my.netlist] instead [test.netlist]
> 
> - My questions:
> 
> 1. Do you find some more elegant solution then I did it ?
> 
> 2. If you ignore “if - condition” in main file and you type just [./test] the compiler
>     return “Segmentation fault: 11”
> 
>     In the function “check input arguments” with this two “if condition” the compiler 
>     return “segmentation fault” if you type only - ./test
>     that is the reason why I put in the main function one more “if condition” and now it
>     works but I am not sure is it good solution.
> 
>    *** If the user type a wrong arguments or more or less arguments the program must
>         - return 1
>         - and print out - [ERR] usage: /test.netlist omega
> 
>     What are you suggestions ?
> 
>    Thanks a lot guys. ;)
> ———
> 
>  - >> This is my solution:
> 
> ------
> 
>  #include <stdio.h>
>  #include <string.h>
>  #include <stdlib.h>
> 
> int checkInputArguments(char *argument[], int arg_counter);
> 
> const char *str = “test.netlist";
> i
> 
> int main(int argc, char *argv[])
> {
>   if(argc == 1)
>   {
>     printf("ERR] usage: /test.netlist omega\\n\n");
>     return 1;
>   }
>   
>  checkInputArguments(argv, argc);
>  
>   return 0;
> }
> 
> int checkInputArguments(char *argument[], int arg_counter)
> {
>   if(strcmp(str, argument[1]) != 0) 
>   {
>    printf("[ERR] usage: /test.netlist omega\\n\n");
>    return 1; 
>   }
>   else if(arg_counter != 3)
>   {
>     printf("[ERR] usage: /test.netlist omega\\n\n");
>     return 1;
>   }
>   return 0;
> }

Thanks Mr Robert. I know for the "ternary operator" but it gives us only two posibilities, when is true do this otherwise do other solution. Later I mention, I will have more checking for errors and be in situation to send return 2, return 3 ... and so on.

This is my solution for this part of exercise. 

--

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

#define FILENAME "test.netlist"

int checkInputArguments(char *argument[], int arg_counter);
void printErrorMessage(void);
int checkErrorFunction(int err_checker);

int error;

int main(int argc, char *argv[])
{
  error = checkInputArguments(argv, argc);
  checkErrorFunction(error);  
  return 0;
}

int checkInputArguments(char *argument[], int arg_counter)
{
  if(arg_counter == 1)
  {
    printErrorMessage();
  } 
  else if(strcmp(FILENAME, argument[1]) != 0) 
  {
    printErrorMessage();
  }
  else if(arg_counter != 3)
  {
    printErrorMessage();
  }
  // Checking does the 3rd argument is one integer or not
  else if(isdigit(*argument[2]) == 0)
  {
    printErrorMessage();
  }
  return 0;
}

void printErrorMessage()
{
  fprintf(stderr, "[ERR] usage: ./test netlist omega\n");
}

int checkErrorFunction(int err_checker)
{
  switch(err_checker)
  {
    case 1:
       return 1;
  }
  return 0;
}

[toc] | [prev] | [next] | [standalone]

#99002

On Sunday, December 11, 2016 at 4:56:39 PM UTC+1, Dexterr wrote:

Hi there. I have found for me most elegant solution.

Explanation:

(1) program MUST start towards instructions from given in exercise:

 <name of program>  <name of text file> <unsigned integer number or zero>

 ./test test.netlist 456

 (2) in main function() - ternary operator for "return 1" or "return 0" is not the best solution while during further code writing I will have more return values for some other errors (return 2, return 3, ... return 5). Ternary operator gives as only 2 posibilities.

This is the best version I have till now.

--

//-----------------------------------------------------------------------------
// cl_arg_final.c 
//
// finalno rijesenje za ./ass netlist omega - command line arguments
//
// Authors: DI Dr. Dejan Grubesic
//-----------------------------------------------------------------------------
//

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

#define FILENAME "test.netlist"

int checkInputArguments(char *argument[], int arg_counter);
int printErrorMessage(void);


int main(int argc, char *argv[])
{
  checkInputArguments(argv, argc);
    
  return 0;
}

int checkInputArguments(char *argument[], int arg_counter)
{
  if(arg_counter == 1)
  {
    printErrorMessage();
  } 
  else if(strcmp(FILENAME, argument[1]) != 0) 
  {
    printErrorMessage();
  }
  else if(arg_counter != 3)
  {
    printErrorMessage();
  }
  // Checking does the 3rd argument is unsigned integer or not
  else if(isdigit(*argument[2]) == 0)
  {
    printErrorMessage();
  }
  return 0;
}

int printErrorMessage()
{
  fprintf(stderr, "[ERR] usage: ./ass netlist omega\n");
  return 1;
}

[toc] | [prev] | [next] | [standalone]

#99003

Hi there. I have found for me most elegant solution. 

Explanation: 

(1) program MUST start towards instructions from given in exercise: 

 <name of program>  <name of text file> <unsigned integer number or zero> 

 ./test test.netlist 456 

 (2) in main function() - ternary operator for "return 1" or "return 0" is not the best solution while during further code writing I will have more return values for some other errors (return 2, return 3, ... return 5). Ternary operator gives as only 2 posibilities. 

This is the best version I have till now.

---

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

#define FILENAME "test.netlist"

int checkInputArguments(char *argument[], int arg_counter);
int printErrorMessage(void);


int main(int argc, char *argv[])
{
  checkInputArguments(argv, argc);
    
  return 0;
}

int checkInputArguments(char *argument[], int arg_counter)
{
  if(arg_counter == 1)
  {
    printErrorMessage();
  } 
  else if(strcmp(FILENAME, argument[1]) != 0) 
  {
    printErrorMessage();
  }
  else if(arg_counter != 3)
  {
    printErrorMessage();
  }
  // Checking does the 3rd argument is unsigned integer or not
  else if(isdigit(*argument[2]) == 0)
  {
    printErrorMessage();
  }
  return 0;
}

int printErrorMessage()
{
  fprintf(stderr, "[ERR] usage: ./ass netlist omega\n");
  return 1;
}

[toc] | [prev] | [next] | [standalone]

#99012

On Mon, 12 Dec 2016 00:27:35 -0800 (PST), Dexterr <dejangru@gmail.com>
wrote:

>Hi there. I have found for me most elegant solution. 

We have different definitions of elegant.

>Explanation: 
>
>(1) program MUST start towards instructions from given in exercise: 
>
> <name of program>  <name of text file> <unsigned integer number or zero> 

The program fails to properly test the second command line argument.

> ./test test.netlist 456 
>
> (2) in main function() - ternary operator for "return 1" or "return 0" is not the best solution while during further code writing I will have more return values for some other errors (return 2, return 3, ... return 5). Ternary operator gives as only 2 posibilities. 

As written, your program always returns 0 and never returns 1.

>This is the best version I have till now.
>
>---
>
>#include <stdio.h>
>#include <string.h>
>#include <stdlib.h>
>#include <ctype.h>
>
>#define FILENAME "test.netlist"
>
>int checkInputArguments(char *argument[], int arg_counter);
>int printErrorMessage(void);
>
>
>int main(int argc, char *argv[])
>{
>  checkInputArguments(argv, argc);
>    
>  return 0;
>}
>
>int checkInputArguments(char *argument[], int arg_counter)
>{
>  if(arg_counter == 1)

If you would reorder tests 2 and 3, his test would be completely
unnecessary.  

>  {
>    printErrorMessage();
>  } 
>  else if(strcmp(FILENAME, argument[1]) != 0) 
>  {
>    printErrorMessage();
>  }
>  else if(arg_counter != 3)
>  {
>    printErrorMessage();
>  }
>  // Checking does the 3rd argument is unsigned integer or not
>  else if(isdigit(*argument[2]) == 0)

This test will fail to print an error message when the second argument
to the program is 5B and this is obviously not a valid value for an
unsigned int.

>  {
>    printErrorMessage();
>  }
>  return 0;

What is the point of having this function return a value if it always
returns the same value.

>}
>
>int printErrorMessage()

Why is this function defined to return a value?
>{
>  fprintf(stderr, "[ERR] usage: ./ass netlist omega\n");
>  return 1;
>}
>

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#99094

On Monday, December 12, 2016 at 10:01:41 AM UTC+1, Barry Schwarz wrote:
> On Mon, 12 Dec 2016 00:27:35 -0800 (PST), Dexterr <dejangru@gmail.com>
> wrote:
> 

> 
> We have different definitions of elegant.
> 
 -> If you have please tell me, because English is not my mother language and
      I am a newbie, so when I find some better solution then my first code I have
      no idea how to call  it. For experience programmer in C, my code is probably 
     stupid but what can I do. I can't be programmer as Kernighan Ritchie over night.
> >
> >
> >
> > <name of program>  <name of text file> <unsigned integer number or zero> 
> 
> The program fails to properly test the second command line argument.
> 
> > ./test test.netlist 456 

 -> It is imposible. I have testet all posibilities. It works perfekt!!!
    - first argument - name of program - "test" or whatever
    - second argument - name of file - "test.netlist"
    - third argument - unsigned integer - 456 or something similar

    -> IT WORKS on my computer. I can't explain why don't work for you. 
         I belive you that don't work on your machine but don't know the reason.
       
> >

> As written, your program always returns 0 and never returns 1.

  - > I have no answer on this. I am confused. If you type i.e. "./test test.netlist" or 
       "./test test.netlist usa" or similar it will be an error message, that means that
       program return 1. 
      

> 
> -- 
> Remove del for email

[toc] | [prev] | [next] | [standalone]

#99108

On 12/12/2016 12:42 PM, Dexterr wrote:
> On Monday, December 12, 2016 at 10:01:41 AM UTC+1, Barry Schwarz wrote:
>> On Mon, 12 Dec 2016 00:27:35 -0800 (PST), Dexterr <dejangru@gmail.com>
>> wrote:
>>
>
>>
>> We have different definitions of elegant.
>>
>  -> If you have please tell me, because English is not my mother language and
>       I am a newbie, so when I find some better solution then my first code I have
>       no idea how to call  it. For experience programmer in C, my code is probably
>      stupid but what can I do. I can't be programmer as Kernighan Ritchie over night.
>>>
>>>
>>>
>>> <name of program>  <name of text file> <unsigned integer number or zero>
>>
>> The program fails to properly test the second command line argument.
>>
>>> ./test test.netlist 456
  >
>  -> It is imposible. I have testet all posibilities. It works perfekt!!!
>     - first argument - name of program - "test" or whatever
>     - second argument - name of file - "test.netlist"
>     - third argument - unsigned integer - 456 or something similar
>
>     -> IT WORKS on my computer. I can't explain why don't work for you.
>          I belive you that don't work on your machine but don't know the reason.

Should the command

     ./test test.netlist 4notanumber

produce an error message? Does it produce an error message?

>> As written, your program always returns 0 and never returns 1.
>
>   - > I have no answer on this. I am confused. If you type i.e. "./test test.netlist" or
>        "./test test.netlist usa" or similar it will be an error message, that means that
>        program return 1.

No, the fact that you got that message indicates only that the program 
executed the corresponding print statement. It gives no direct 
indication about anything else. Examining your code, it's clear that 
printErrorMessage() always returns a 1. But printErrorMessage() is NOT 
your entire program, it's just one sub-routine. The value of 1 that 
printErrorMessage() returns is routinely ignored during every single 
function call. checkInputArguments() always returns 0, and that values 
is also always ignored. main() always returns 0, and that value is not 
ignored: it guarantees that your program will always have a successfull 
exit status, even if your program was unsuccessful. Is that what you want?

Are you using a unix-like system? If so, issue the following commands:

     ./test test.netlist
     echo Exit Status = $status

Tell us what exit status it reports.
There's a complication here, due to what the actual meaning of $status 
is; but I'm not going to bother explaining that complication to someone 
who apparently still needs to understand how return statements work - it 
would just confuse you. I mention this only to forestall comments by 
others who are aware of that complication.

[toc] | [prev] | [next] | [standalone]

#99143

On Mon, 12 Dec 2016 09:42:05 -0800 (PST), Dexterr <dejangru@gmail.com>
wrote:

>On Monday, December 12, 2016 at 10:01:41 AM UTC+1, Barry Schwarz wrote:
>> On Mon, 12 Dec 2016 00:27:35 -0800 (PST), Dexterr <dejangru@gmail.com>
>> wrote:
>> 
>
>> 
>> We have different definitions of elegant.
>> 
> -> If you have please tell me, because English is not my mother language and
>      I am a newbie, so when I find some better solution then my first code I have
>      no idea how to call  it. For experience programmer in C, my code is probably 
>     stupid but what can I do. I can't be programmer as Kernighan Ritchie over night.

In my mind a program cannot be elegant if it includes unnecessary
code.  It cannot be elegant if it fails to perform a required
function.  You program satisfies both of these conditions.

-- 
Remove del for email

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web