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

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

Commandline parsing

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

Contents

  Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 08:34 -0700
    Re: Commandline parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-07-26 15:38 +0000
    Re: Commandline parsing scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 16:00 +0000
    Re: Commandline parsing Spiros Bousbouras <spibou@gmail.com> - 2023-07-26 16:17 +0000
    Re: Commandline parsing gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-26 16:22 +0000
      Re: Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 09:26 -0700
    Re: Commandline parsing Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-26 17:28 -0500
      Re: Commandline parsing Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-26 17:44 -0500
        Re: Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 01:46 -0700
          Re: Commandline parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 02:47 -0700
            Re: Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 03:12 -0700
      Re: Commandline parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 00:32 +0000
      Re: Commandline parsing Spiros Bousbouras <spibou@gmail.com> - 2023-07-27 16:17 +0000
    Re: Commandline parsing Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-27 04:00 -0400
      Re: Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 01:39 -0700
      Re: Commandline parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 02:47 -0700
        Re: Commandline parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 17:29 +0000
    Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 08:28 -0700
      Re: Commandline parsing scott@slp53.sl.home (Scott Lurndal) - 2023-07-31 16:32 +0000
        Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 09:43 -0700
      Re: Commandline parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-31 09:46 -0700
        Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 10:12 -0700
          Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 11:21 -0700
            Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 12:37 -0700
              Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 12:57 -0700
                Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 13:17 -0700
              Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-08-01 08:39 -0700
              Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-08-01 09:00 -0700
                Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-08-01 10:49 -0700
        Re: Commandline parsing fir <profesor.fir@gmail.com> - 2023-07-31 11:53 -0700
    Re: Commandline parsing Michael S <already5chosen@yahoo.com> - 2023-07-31 12:47 -0700
    Re: Commandline parsing Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-08-02 16:30 -0600

Page 1 of 2  [1] 2  Next page →

#171291 — Commandline parsing

Just realised that my options parser isn't publically available, which I have just remedied.

What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

[toc] | [next] | [standalone]

#171293

On Wed, 26 Jul 2023 08:34:57 -0700, Malcolm McLean wrote:

> Just realised that my options parser isn't publically available,
> which I have just remedied.
> 
> What approaches do people use towards parsing commandline
> options? Do you use getopt() ? Or do you find that real world
> programs have a simple enough set of options that it's easier 
> to write bespoke code?

For simple commandlines, I usually write my own argument
"parser" (typically a set of strcmp() calls). For more complex
commandlines, I stick with getopt().

I haven't found any commandlines yet that require lex&yacc, but
I still keep looking for them (yes, I like the challenge :-) )

-- 
Lew Pitcher
"In Skills We Trust"

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

#171294

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>Just realised that my options parser isn't publically available, which I have just remedied.
>
>What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?


getopt.  always.

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

#171295

On Wed, 26 Jul 2023 08:34:57 -0700 (PDT) Malcolm McLean
<malcolm.arthur.mclean@gmail.com> wrote:
> Just realised that my options parser isn't publically available, which I
> have just remedied.
> 
> What approaches do people use towards parsing commandline options ? Do you
> use getopt() ? Or do you find that real world programs have a simple enough
> set of options that it's easier to write bespoke code?

Custom made. Nothing fancy , never needed it.

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

#171297

In article <a631f98c-5482-4e90-9a0d-8ce49e447153n@googlegroups.com>,
Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>Just realised that my options parser isn't publically available, which
>I have just remedied.

URL?

-- 
I shot a man on Fifth Aveneue, just to see him die.

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

#171298

On Wednesday, 26 July 2023 at 17:23:11 UTC+1, Kenny McCormack wrote:
> In article <a631f98c-5482-4e90...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote: 
> >Just realised that my options parser isn't publically available, which 
> >I have just remedied.
> URL? 
> 
https://github.com/MalcolmMcLean/optionparser
> 
But I's like a discussion about what people would like to see in an options parser
rather than focusing too much on the specifics of my code in the first instance.

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

#171308

On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> Just realised that my options parser isn't publically available, which I have just remedied.
> 
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

And what do you do about Unicode on your command line ?

Lynn

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

#171309

On 7/26/2023 5:28 PM, Lynn McGuire wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available, which 
>> I have just remedied.
>>
>> What approaches do people use towards parsing commandline options ? Do 
>> you use getopt() ? Or do you find that real world programs have a 
>> simple enough set of options that it's easier to write bespoke code?
> 
> And what do you do about Unicode on your command line ?
> 
> Lynn

BTW, we rolled our own command line parser that handles Unicode.

Lynn

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

#171329

On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote:
> On 7/26/2023 5:28 PM, Lynn McGuire wrote: 
> > On 7/26/2023 10:34 AM, Malcolm McLean wrote: 
> >> Just realised that my options parser isn't publically available, which 
> >> I have just remedied. 
> >> 
> >> What approaches do people use towards parsing commandline options ? Do 
> >> you use getopt() ? Or do you find that real world programs have a 
> >> simple enough set of options that it's easier to write bespoke code? 
> > 
> > And what do you do about Unicode on your command line ? 
> > 
> > Lynn
> BTW, we rolled our own command line parser that handles Unicode. 
> 
You'd need to tweak the options parser slightly because it has a concept of
single character flags (so the user types something like "tar -xvf file.tar" he's
not passing one option "xvf", but three flags). So it would have to be UTF-8
aware to accomodate Unicode flags. Long options should work tranparently.
It's maybe a worthwhile change.

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

#171332

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote:
>> On 7/26/2023 5:28 PM, Lynn McGuire wrote: 
>> > On 7/26/2023 10:34 AM, Malcolm McLean wrote: 
>> >> Just realised that my options parser isn't publically available, which 
>> >> I have just remedied. 
>> >> 
>> >> What approaches do people use towards parsing commandline options ? Do 
>> >> you use getopt() ? Or do you find that real world programs have a 
>> >> simple enough set of options that it's easier to write bespoke code? 
>> > 
>> > And what do you do about Unicode on your command line ? 
>> > 
>> > Lynn
>> BTW, we rolled our own command line parser that handles Unicode. 
>> 
> You'd need to tweak the options parser slightly because it has a
> concept of single character flags (so the user types something like
> "tar -xvf file.tar" he's not passing one option "xvf", but three
> flags). So it would have to be UTF-8 aware to accomodate Unicode
> flags. Long options should work tranparently.  It's maybe a worthwhile
> change.

I've never seen an option name that uses non-ASCII characters.  The vast
majority of option names use just letters, mostly lowercase --
sometimes digits, and hyphens or rarely underscores for long option
names.

Handling full UTF-8 for *arguments* to options is useful.  Requiring
non-ASCII characters as option names is going to make commands difficult
to type for a lot of users.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#171334

On Thursday, 27 July 2023 at 10:47:22 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> > On Wednesday, 26 July 2023 at 23:45:06 UTC+1, Lynn McGuire wrote: 
> >> On 7/26/2023 5:28 PM, Lynn McGuire wrote: 
> >> > On 7/26/2023 10:34 AM, Malcolm McLean wrote: 
> >> >> Just realised that my options parser isn't publically available, which 
> >> >> I have just remedied. 
> >> >> 
> >> >> What approaches do people use towards parsing commandline options ? Do 
> >> >> you use getopt() ? Or do you find that real world programs have a 
> >> >> simple enough set of options that it's easier to write bespoke code? 
> >> > 
> >> > And what do you do about Unicode on your command line ? 
> >> > 
> >> > Lynn 
> >> BTW, we rolled our own command line parser that handles Unicode. 
> >> 
> > You'd need to tweak the options parser slightly because it has a 
> > concept of single character flags (so the user types something like 
> > "tar -xvf file.tar" he's not passing one option "xvf", but three 
> > flags). So it would have to be UTF-8 aware to accomodate Unicode 
> > flags. Long options should work tranparently. It's maybe a worthwhile 
> > change.
> I've never seen an option name that uses non-ASCII characters. The vast 
> majority of option names use just letters, mostly lowercase -- 
> sometimes digits, and hyphens or rarely underscores for long option 
> names. 
> 
That's worth knowing.
> Handling full UTF-8 for *arguments* to options is useful. Requiring 
> non-ASCII characters as option names is going to make commands difficult 
> to type for a lot of users. 
> 
The options parser is UTF-8 naive. So a filename with high Unicode characters
would just pass through. Similarly if you provide a long option with UTF-8,
that would be parsed. However currently it also takes a list of flags. These
are teated as single characters, so if you pass UTF-8, values over 127 will
be incorrectly treated.
If you are passed UTF-16 on the comandline, you'd have to convert to UTF-8.

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

#171316

On 2023-07-26, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available, which I have just remedied.
>> 
>> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
>
> And what do you do about Unicode on your command line ?

That's just another UTF-8 input; same as from a text stream.

$ txr -e '(put-line "日本語")'
日本語

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#171350

On Wed, 26 Jul 2023 17:28:30 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> On 7/26/2023 10:34 AM, Malcolm McLean wrote:
> > Just realised that my options parser isn't publically available, which I have just remedied.
> > 
> > What approaches do people use towards parsing commandline options ? Do
> > you use getopt() ? Or do you find that real world programs have a simple
> > enough set of options that it's easier to write bespoke code?
> 
> And what do you do about Unicode on your command line ?

Nothing. I don't have options whose name includes (non ASCII) unicode and for
arguments which are not of a specialised nature (like numbers) , handling them
as an array of octets works fine. For example , pathnames on a Unix system
are arrays of octets so you just take the command line argument and you pass
it to  fopen() .

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

#171326

On 7/26/23 11:34, Malcolm McLean wrote:
> Just realised that my options parser isn't publically available, which I have just remedied.
> 
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

​I've only written one program where i had to deal with command-line 
options, and when that happened i just used getopt().  That being said, 
were i to write any more programs like that i don't think i'd use it, in 
part because i think that the paradigm of the option is wantonly applied 
to every program without consideration for whether it's most optimal 
because it's just what everyone is used to.

-- 
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't 
have shit in Thunderbird 😩

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

#171328

On Thursday, 27 July 2023 at 09:00:26 UTC+1, Blue-Maned_Hawk wrote:
> On 7/26/23 11:34, Malcolm McLean wrote: 
> > Just realised that my options parser isn't publically available, which I have just remedied. 
> > 
> > What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?
> ​I've only written one program where i had to deal with command-line 
> options, and when that happened i just used getopt(). That being said, 
> were i to write any more programs like that i don't think i'd use it, in 
> part because i think that the paradigm of the option is wantonly applied 
> to every program without consideration for whether it's most optimal 
> because it's just what everyone is used to. 
> 
I don't write commandline programs at work. Whilst I can imagine circumstances
in which that changed, a utility would most likely be in Python. For hobby programs,
it's also rare to need many options.

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

#171333

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> On 7/26/23 11:34, Malcolm McLean wrote:
>> Just realised that my options parser isn't publically available,
>> which I have just remedied.  What approaches do people use towards
>> parsing commandline options ?  Do you use getopt() ? Or do you find
>> that real world programs have a simple enough set of options that
>> it's easier to write bespoke code?
>
> ​I've only written one program where i had to deal with command-line
> options, and when that happened i just used getopt().  That being
> said, were i to write any more programs like that i don't think i'd
> use it, in part because i think that the paradigm of the option is
> wantonly applied to every program without consideration for whether
> it's most optimal because it's just what everyone is used to.

What is your alternative to "the paradigm of the option"?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#171354

On 2023-07-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
>> On 7/26/23 11:34, Malcolm McLean wrote:
>>> Just realised that my options parser isn't publically available,
>>> which I have just remedied.  What approaches do people use towards
>>> parsing commandline options ?  Do you use getopt() ? Or do you find
>>> that real world programs have a simple enough set of options that
>>> it's easier to write bespoke code?
>>
>> ​I've only written one program where i had to deal with command-line
>> options, and when that happened i just used getopt().  That being
>> said, were i to write any more programs like that i don't think i'd
>> use it, in part because i think that the paradigm of the option is
>> wantonly applied to every program without consideration for whether
>> it's most optimal because it's just what everyone is used to.
>
> What is your alternative to "the paradigm of the option"?

One is environment variables.

Imagine the dd utility, with its keyword parameters:

  dd if=this of=that count=42

If dd were converted to look up in the environment instead of the comand
line, then (in POSIX shell syntax), it could be invoked like this:

  if=this of=that count=42 dd

It gets cumbersome to run such a program with fork and exec, because
there isn't any API for doing an exec with an environment array that
augments the current environment, rather than replacing it.  Only if the
program (and its children, if any) never need any environment variables
other than the ones in its API, execv can be used.

Also, if a program needs other environment variables, then the problem
is that the argument ones are mixed up with the others; you don't have
nice "get me all my keyword arguments" access without naming all of
them. It's impossible to diagnose typos. If an argument is misspelled,
it disappears into the environment; the program has no way of knowing it
was one of the argument-like variables specified for that call.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#171474

środa, 26 lipca 2023 o 17:35:05 UTC+2 Malcolm McLean napisał(a):
> Just realised that my options parser isn't publically available, which I have just remedied. 
> 
> What approaches do people use towards parsing commandline options ? Do you use getopt() ? Or do you find that real world programs have a simple enough set of options that it's easier to write bespoke code?

i may not understand about what this topic is but in org-asm for comandline i use something most trivial 


void ConsumeCommandlineOption(char* option)
{
    if( strcmp ( option, "-noconsole" )==0)  show_console = 0;  else
     if( strcmp ( option, "-console" )==0)   show_console = 1;  else
      if( strcmp ( option, "-nolog" )==0)    show_verbose_console_info = 0;  else
       if( strcmp ( option, "-log" )==0)    show_verbose_console_info = 1;   else
         printf("\n ++++ option %s not reckognized and ignored ", option);

}
  char* input_file_name = "input.asm";
  char* output_file_name = "asm-result.exe";

int ConsumeCommandlineOptions(int argc, char* argv[])
{
  if(argc==1 ) {  PrintNoArgumentsInfo(); return 'stop';  }
  if(argc>=2)  { input_file_name = argv[1];  }
  if(argc>=3)  { output_file_name = argv[2];  }
  if(argc>=4)  {  for(int i=3; i<argc;i++)  ConsumeCommandlineOption(argv[i]);   }

  return 'ok';
}

its hovever dirty written and maybe i will revrite it..puting elses on right side is todays tiem invention (never seen this and today get idea to put it on right first time ;c ) using strcomp im not sure its okay as afair its a bit raw function, also this %s im not sure if its safe

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

#171475

fir <profesor.fir@gmail.com> writes:
>=C5=9Broda, 26 lipca 2023 o=C2=A017:35:05 UTC+2 Malcolm McLean napisa=C5=82=
>(a):
>> Just realised that my options parser isn't publically available, which I =
>have just remedied.=20
>>=20
>> What approaches do people use towards parsing commandline options ? Do yo=
>u use getopt() ? Or do you find that real world programs have a simple enou=
>gh set of options that it's easier to write bespoke code?
>
>i may not understand about what this topic is but in org-asm for comandline=
> i use something most trivial=20

You may wish to familiarize yourself with this:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

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

#171476

poniedziałek, 31 lipca 2023 o 18:33:10 UTC+2 Scott Lurndal napisał(a):
> fir <profes...@gmail.com> writes: 
> >=C5=9Broda, 26 lipca 2023 o=C2=A017:35:05 UTC+2 Malcolm McLean napisa=C5=82= 
> >(a): 
> >> Just realised that my options parser isn't publically available, which I = 
> >have just remedied.=20 
> >>=20 
> >> What approaches do people use towards parsing commandline options ? Do yo= 
> >u use getopt() ? Or do you find that real world programs have a simple enou=
> >gh set of options that it's easier to write bespoke code? 
> >
> >i may not understand about what this topic is but in org-asm for comandline= 
> > i use something most trivial=20 
> 
> You may wish to familiarize yourself with this: 
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

okay, though not now..right now the trivial syntax i use is okay to me

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web