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

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

getFirstDayOfMonth()

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

Contents

  getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 03:48 +0000
    Re: getFirstDayOfMonth() gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-01 15:39 +0000
      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:12 +0100
        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 08:28 -0800
          Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:33 +0100
            Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:37 +0100
              Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 10:34 -0800
                Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 22:03 +0100
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 17:20 +0000
      Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-01 16:47 +0000
      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:56 +0100
      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 17:18 +0000
      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 20:47 +0000
        Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-01 21:38 +0000
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 21:50 +0000
            Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 09:52 -0800
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-02 00:00 +0000
            Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-02 14:46 +0000
              Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-02 16:41 +0100
              Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-02 19:59 +0000
                Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-02 22:14 +0100
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:08 +0000
                    Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:03 +0100
                Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-02 14:22 -0800
                  Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-03 15:43 +0100
                    Re: getFirstDayOfMonth() David Brown <david.brown@hesbynett.no> - 2024-03-03 18:45 +0100
                      Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-03 18:42 +0000
                        Re: getFirstDayOfMonth() David Brown <david.brown@hesbynett.no> - 2024-03-04 09:49 +0100
                      Re: getFirstDayOfMonth() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 11:31 +0000
                        Re: getFirstDayOfMonth() Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-04 14:23 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-04 17:27 +0100
                    Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 17:34 +0000
                      Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 17:40 +0000
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:11 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 18:26 +0000
                            Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-04 18:30 +0000
                              Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 19:01 +0000
                            Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:09 +0100
                              Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:06 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 02:56 +0100
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:49 +0000
                        Re: getFirstDayOfMonth() Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-03-06 20:40 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-06 20:54 +0000
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 17:26 +0000
                    Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 17:34 +0000
                      Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 10:07 -0800
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 23:47 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 16:10 -0800
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:12 +0000
                          [OT] Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:18 +0100
                            Re: [OT] Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:55 +0000
                        Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:03 +0000
                          Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-05 13:25 -0800
                    Re: getFirstDayOfMonth() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-03-04 21:21 +0000
                      Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 00:37 +0200
                        Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 11:41 +0200
                        Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 15:57 -0700
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 23:35 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:20 +0100
                Re: getFirstDayOfMonth() James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-03 04:06 -0500
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:21 +0000
                    Re: getFirstDayOfMonth() James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-04 14:42 -0500
                    Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 14:50 -0800
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:40 +0000
                        Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-05 01:27 +0000
                          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:40 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:05 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 17:39 -0800
                          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:43 +0000
                    Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 01:08 +0200
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:18 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 16:33 -0800
                Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-03 15:24 +0000
                  Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-03 20:20 +0200
                    Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-03 18:56 +0000
              Re: getFirstDayOfMonth() Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-03-03 13:17 +0000
      Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-02 02:49 +0100
        Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 09:47 -0800
          Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-04 02:26 +0100
        Re: getFirstDayOfMonth() Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-05 14:03 +1100
          Re: getFirstDayOfMonth() bart <bc@freeuk.com> - 2024-03-05 13:19 +0000
            Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-13 05:40 +0100
              Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-13 06:01 +0100
                Re: getFirstDayOfMonth() Spiros Bousbouras <spibou@gmail.com> - 2024-03-13 13:38 +0000
                  Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:47 -0700
                    Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 09:11 -0700
                Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 07:36 -0700
                  Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 19:56 -0700
      Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-02 03:44 +0000
        Re: getFirstDayOfMonth() Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-05 14:07 +1100
        Re: getFirstDayOfMonth() gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-05 13:30 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#383245

On 02.03.2024 20:59, Mike Sanders wrote:
> 
> Oh yeah. Have been wrestling with the potential
> consequences of this for a good while. I think I'm
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.

Again you have a misconception; errors on Unix systems are
regularly indicated by any value unequal to 0, not only by 1.
That way you can differentiate any possible errors or types
of errors.

> This is perhaps the only area I've ever seen where
> other OSs, like Windows, have a superior methodology
> on the issue.

(I would be astonished. But since you haven't provided any
hint on its specific "methodology" the statement is void.)

> 0/1 provides next to no nuance.

That's why on Unixes you can and typically return more than
just two values.

> But I'm no expert, just my experience.

You haven't provided any evidence or facts of experience.

Janis

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

#383315

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> You haven't provided any evidence or facts of experience.

Janis, relax. I have nothing to prove to anyone. From
your remarks it certainly looks like you don't use
WinAPI much & from that I don't infer you're unintelligent,
its simply not an area you're familiar with.

Now apply that same thinking to other folks, in other
walks of life. You need to slow down with the often
wrong conclusions...

Now prove me wrong by not responding with more snark.

-- 
:wq
Mike Sanders

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

#383351

On 04.03.2024 19:08, Mike Sanders wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 
>> You haven't provided any evidence or facts of experience.
> 
> Janis, relax. I have nothing to prove to anyone. [...]

No, you don't have to. Just expect responses if you're posting
just opinions based on misconceptions. - But yes, let's relax
and close that file.

Janis

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

#383247

porkchop@invalid.foo (Mike Sanders) writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> If I may suggest:
>> 
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>> 
>> '-h'  or '-?' have traditionally been used to display
>> usage information for an utility.
>
> Yep, it will definitely be '-?' (still working to finalize things).

I wouldn't use '-?'.  The '?' character is a wildcard in most Unix
shells.  If you happen to have a file in the current directory that
matches the pattern, it will expand to the name of that file.  If you
don't, the behavior depends on the shell and settings.

    $ ls -l
    total 0
    -rw-r--r-- 1 kst kst 0 Mar  2 14:14 -h
    $ /bin/echo -?
    -h
    $

And most users of Unix-like systems won't expect '-?' to be an option;
'-h' is much more common.

> Many thanks for the link too btw.
>  
>>>Error levels returned:
>>>
>>>3  Option syntax errors
>>>2  File open-read errors
>>>1  Dates match today or matching tags
>>>0  No dates match today or no tags match
>> 
>> For commands defined by POSIX (and generally in
>> unix), an exit status of zero indicates success.
>
> Oh yeah. Have been wrestling with the potential
> consequences of this for a good while. I think I'm
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.
> This is perhaps the only area I've ever seen where
> other OSs, like Windows, have a superior methodology
> on the issue. 0/1 provides next to no nuance. But
> I'm no expert, just my experience.

The C standard, not just POSIX, defines 0 as a successful status.  If
your program is intended to work on Unix-like systems (or on Windows if
I'm not mistaken), using a status of 0 to indicate an error will cause
problems.  Conventions exist for a reason.

Use 0 for success, 1 for unspecified errors, and other positive values
for more specific errors.

> Thanks again for the links Scott, I'll read them this
> weekend.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383259

On 02.03.2024 23:22, Keith Thompson wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> If I may suggest:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>
>>> '-h'  or '-?' have traditionally been used to display
>>> usage information for an utility.
>>
>> Yep, it will definitely be '-?' (still working to finalize things).
> 
> I wouldn't use '-?'.  The '?' character is a wildcard in most Unix
> shells.  If you happen to have a file in the current directory that
> matches the pattern, it will expand to the name of that file.  If you
> don't, the behavior depends on the shell and settings.
> 
> [snip code sample]
> 
> And most users of Unix-like systems won't expect '-?' to be an option;

I cannot speak for "most users of Unix-like systems" but my personal
experience differs.

> '-h' is much more common.

The "problem" is that you may want to have -h as an option character,
especially if your program supports a lot of options and you have no
creative naming way of choosing another character. (An example from
one of my recent implementations is using -h for 'height'.[*])

The advantage of -? is that is has as non-alpha option not a mnemonic
character. (We thus used it since the 1990's even in coding standards
as our preferred standard way to interrogate usage.)

Your point that -h may be a file is nonetheless valid, of course, as
would be a file named -?. Both are rather rare though and typically
the result of an error; especially commands started from the shell
will report errors and you have to use '--' to create files like -h.
The Shell also allows to disable file globbing if that happens to
appear to be an issue and if you don't want to just quote the -? in
such (rare) corner-cases with pathological filenames.

There's functional option names with application semantics (usually
expressed with mnemonic characters, or long names) and meta options
like issuing a usage synopsis. I'd certainly like to have mnemonics
preserved for the applications!

That's why using non-alpha key-symbols is also the standard for e.g.
Ksh; its option processing builtin 'getopts' _inherently_ supports
(for all shell scripts that use this function for option processing)
the meta options -? (for usage synopsis), --?? (for a verbose usage
message), and the prefix --?? generally for other meta-formats (like
--??html or also long form alternatives like --html to create usage
information in HTML).[**]

Janis

[*] In scripts you may of course also define long option names but
for interactive use it's certainly not a preferred workaround.

[**] That's also why I think that [without evidence] we cannot assume
"most users of Unix-like systems" to be a reliable qualification. It
seems to be a common standard.

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

#383263

On 03/03/2024 15:43, Janis Papanagnou wrote:
> On 02.03.2024 23:22, Keith Thompson wrote:
>> porkchop@invalid.foo (Mike Sanders) writes:
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> If I may suggest:
>>>>
>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>>
>>>> '-h'  or '-?' have traditionally been used to display
>>>> usage information for an utility.
>>>
>>> Yep, it will definitely be '-?' (still working to finalize things).
>>
>> I wouldn't use '-?'.  The '?' character is a wildcard in most Unix
>> shells.  If you happen to have a file in the current directory that
>> matches the pattern, it will expand to the name of that file.  If you
>> don't, the behavior depends on the shell and settings.
>>
>> [snip code sample]
>>
>> And most users of Unix-like systems won't expect '-?' to be an option;
> 
> I cannot speak for "most users of Unix-like systems" but my personal
> experience differs.
> 

Try "cmd -h" and "cmd -?" for a selection of programs on your *nix 
system.  You'll find that "-h" will almost invariably give you a brief 
help message.  "-?" will also work for some programs, but not many - and 
typically "-h" will work too for these programs.

"-?" is common in the DOS/Windows world, and for programs that come from 
there, while "-h" is vastly more common in the *nix world.  (And of 
course, "--help" works too, as single-letter options usually also have a 
full word version.)

>> '-h' is much more common.
> 
> The "problem" is that you may want to have -h as an option character,
> especially if your program supports a lot of options and you have no
> creative naming way of choosing another character. (An example from
> one of my recent implementations is using -h for 'height'.[*])

Having "-h" as an option for something other than "--help" would be insane.

> 
> The advantage of -? is that is has as non-alpha option not a mnemonic
> character. (We thus used it since the 1990's even in coding standards
> as our preferred standard way to interrogate usage.)
> 
> Your point that -h may be a file is nonetheless valid, of course, as
> would be a file named -?. 

File names that match "-?" would be any file name that starts with "-", 
and is followed by a single character.  So "-x" would match just as well 
as "-?".  I don't think it is likely to have such filenames, but it is 
perhaps not /quite/ as unlikely as "-?".

> Both are rather rare though and typically
> the result of an error; especially commands started from the shell
> will report errors and you have to use '--' to create files like -h.

There are a variety of ways of doing it.  The easiest way would be to 
use "./-x" (or "./-h", or whatever).

> The Shell also allows to disable file globbing if that happens to
> appear to be an issue and if you don't want to just quote the -? in
> such (rare) corner-cases with pathological filenames.

That would be an extraordinary effort to work around poor choices of 
options in a program.

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

#383270

On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote:
> On 03/03/2024 15:43, Janis Papanagnou wrote:
>> On 02.03.2024 23:22, Keith Thompson wrote:
>>> porkchop@invalid.foo (Mike Sanders) writes:
>>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> If I may suggest:
>>>>>
>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>>>
>>>>> '-h'  or '-?' have traditionally been used to display
>>>>> usage information for an utility.
>>>>
>>>> Yep, it will definitely be '-?' (still working to finalize things).
>>>
>>> I wouldn't use '-?'.  The '?' character is a wildcard in most Unix
>>> shells.  If you happen to have a file in the current directory that
>>> matches the pattern, it will expand to the name of that file.  If you
>>> don't, the behavior depends on the shell and settings.
>>>
>>> [snip code sample]
>>>
>>> And most users of Unix-like systems won't expect '-?' to be an option;
>> 
>> I cannot speak for "most users of Unix-like systems" but my personal
>> experience differs.
>> 
>
> Try "cmd -h" and "cmd -?" for a selection of programs on your *nix 
> system.  You'll find that "-h" will almost invariably give you a brief 
> help message.

Mostly because it's an unrecognized option.

E.g. gnu grep:

$ grep -z
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
!2!
$ grep -h
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
!2!

-h isn't special in this data point.

There is no convention in POSIX or traditional Unix that -h means
help.

The lack of a -h convention is one of the reasons why GNU invented the
--help option. Plus the problem of the letters having inconsistent
meanings is also addressed with long option synonyms.

The GNU Coding Standards document contains a summary of the long
options used by GNU programs. The idea is that if you're introducing a
new option, it's a good idea to look here to see if other programs
already have something with similar semantics, and then use that
name.

https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table

> Having "-h" as an option for something other than "--help" would be insane.

du -h           # human-readable sizes

df -h           # human-readable sizes

ls -h           # human-readhable sizes

free -h         # human-readhable sizes

ps -h           # suppress (h)eader.

grep -h         # suppress prefixing of filenames when multiple files saerched.

rsync -h        # human-readable sizes

Some of these are in POSIX.

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

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

#383296

On 03/03/2024 19:42, Kaz Kylheku wrote:
> On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote:

> https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
> 
>> Having "-h" as an option for something other than "--help" would be insane.
> 
> du -h           # human-readable sizes
> 
> df -h           # human-readable sizes
> 
> ls -h           # human-readhable sizes
> 
> free -h         # human-readhable sizes
> 
> ps -h           # suppress (h)eader.
> 
> grep -h         # suppress prefixing of filenames when multiple files saerched.
> 
> rsync -h        # human-readable sizes
> 
> Some of these are in POSIX.
> 

You are, of course, entirely correct.  Sorry for my complete lack of 
thought there.

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

#383297

On 03/03/2024 17:45, David Brown wrote:
> 
> 
> Having "-h" as an option for something other than "--help" would be insane.
> 

And Baby X resource compiler by yours truly. Write out a C source file, 
but of course there's also an option for a header. And did I just go and 
do that? And I can't remember, and I have to check, and, no, I knew 
about that, and it is "-header" and that only. But it's just so easily 
done.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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

#383302

On 04/03/2024 11:31, Malcolm McLean wrote:
> On 03/03/2024 17:45, David Brown wrote:
>>
>>
>> Having "-h" as an option for something other than "--help" would be 
>> insane.
>>
> 
> And Baby X resource compiler by yours truly. Write out a C source file, 
> but of course there's also an option for a header. And did I just go and 
> do that? And I can't remember, and I have to check, and, no, I knew 
> about that, and it is "-header" and that only. But it's just so easily 
> done.
> 

Why do you specify -e twice?  And why so many options to specify a 
header file?

[Okay, I'm joking.  And, yes, I know it's not funny]

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

#383306

On 03.03.2024 18:45, David Brown wrote:
> On 03/03/2024 15:43, Janis Papanagnou wrote:
>>
>> The "problem" is that you may want to have -h as an option character,
>> especially if your program supports a lot of options and you have no
>> creative naming way of choosing another character. (An example from
>> one of my recent implementations is using -h for 'height'.[*])
> 
> Having "-h" as an option for something other than "--help" would be insane.

A strong wording that is completely ignoring the existing tools
and the (very sensible, and certainly not "insane"!) rationale
that I - sadly, unsuccessfully, despite being so obvious - tried
to make clear.

Janis

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

#383312

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> The "problem" is that you may want to have -h as an option character,
> especially if your program supports a lot of options and you have no
> creative naming way of choosing another character. (An example from
> one of my recent implementations is using -h for 'height'.[*])

This is my rationale as well: All of the switches have a more/or less
mnemonic feel -X (eXport), -H (Holiday), -C (Calendar), -M (Manual).

I thought it made good sense at least. 

-- 
:wq
Mike Sanders

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

#383313

porkchop@invalid.foo (Mike Sanders) writes:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> The "problem" is that you may want to have -h as an option character,
>> especially if your program supports a lot of options and you have no
>> creative naming way of choosing another character. (An example from
>> one of my recent implementations is using -h for 'height'.[*])
>
>This is my rationale as well: All of the switches have a more/or less
>mnemonic feel -X (eXport), -H (Holiday), -C (Calendar), -M (Manual).
>
>I thought it made good sense at least. 

As someone who started using unix in an environment where there
was only one case, I find I prefer lower-case option
flags, simply because they're easier to type.

(In the old days, to type upper-case characters on a teletype
required prefixing each upper-case character with a backslash
character - and the terminal driver would display uppercase
with the prefix).

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

#383316

Scott Lurndal <scott@slp53.sl.home> wrote:

> As someone who started using unix in an environment where there
> was only one case, I find I prefer lower-case option
> flags, simply because they're easier to type.
> 
> (In the old days, to type upper-case characters on a teletype
> required prefixing each upper-case character with a backslash
> character - and the terminal driver would display uppercase
> with the prefix).

Wow, chuckle, really made you work hard for the results!

-- 
:wq
Mike Sanders

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

#383318

porkchop@invalid.foo (Mike Sanders) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> As someone who started using unix in an environment where there
>> was only one case, I find I prefer lower-case option
>> flags, simply because they're easier to type.
>> 
>> (In the old days, to type upper-case characters on a teletype
>> required prefixing each upper-case character with a backslash
>> character - and the terminal driver would display uppercase
>> with the prefix).
>
>Wow, chuckle, really made you work hard for the results!

It does explain why CamelCase never gained traction in Unix.

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

#383319

On 2024-03-04, Scott Lurndal <scott@slp53.sl.home> wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>>Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> As someone who started using unix in an environment where there
>>> was only one case, I find I prefer lower-case option
>>> flags, simply because they're easier to type.
>>> 
>>> (In the old days, to type upper-case characters on a teletype
>>> required prefixing each upper-case character with a backslash
>>> character - and the terminal driver would display uppercase
>>> with the prefix).
>>
>>Wow, chuckle, really made you work hard for the results!
>
> It does explain why CamelCase never gained traction in Unix.

How did it come about in XWindow? Anyone know?

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

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

#383321

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-03-04, Scott Lurndal <scott@slp53.sl.home> wrote:
>> porkchop@invalid.foo (Mike Sanders) writes:
>>>Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> As someone who started using unix in an environment where there
>>>> was only one case, I find I prefer lower-case option
>>>> flags, simply because they're easier to type.
>>>> 
>>>> (In the old days, to type upper-case characters on a teletype
>>>> required prefixing each upper-case character with a backslash
>>>> character - and the terminal driver would display uppercase
>>>> with the prefix).
>>>
>>>Wow, chuckle, really made you work hard for the results!
>>
>> It does explain why CamelCase never gained traction in Unix.
>
>How did it come about in XWindow? Anyone know?

X Windows came from MIT, not AT&T, and long after the
Teletype had reached obsolescence.   They apparently didn't
mind the extra hassles typing identifiers with mixed case.

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

#383352

On 04.03.2024 19:26, Scott Lurndal wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> As someone who started using unix in an environment where there
>>> was only one case, I find I prefer lower-case option
>>> flags, simply because they're easier to type.
>>>
>>> (In the old days, to type upper-case characters on a teletype
>>> required prefixing each upper-case character with a backslash
>>> character - and the terminal driver would display uppercase
>>> with the prefix).
>>
>> Wow, chuckle, really made you work hard for the results!
> 
> It does explain why CamelCase never gained traction in Unix.

You mean in Unix commands, or in the Unix source code, or in
application source code developed for Unix. - I can just say
that for the latter we used camel-case. For the Unix sources
it's probably just a natural evolution to stay with the
convention used as it started. - But how does is come then
that there's CPP identifiers typically in all caps...?
(We're speculating.)

Janis

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

#383391

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 04.03.2024 19:26, Scott Lurndal wrote:
>> porkchop@invalid.foo (Mike Sanders) writes:
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> As someone who started using unix in an environment where there
>>>> was only one case, I find I prefer lower-case option
>>>> flags, simply because they're easier to type.
>>>>
>>>> (In the old days, to type upper-case characters on a teletype
>>>> required prefixing each upper-case character with a backslash
>>>> character - and the terminal driver would display uppercase
>>>> with the prefix).
>>>
>>> Wow, chuckle, really made you work hard for the results!
>> 
>> It does explain why CamelCase never gained traction in Unix.
>
>You mean in Unix commands, or in the Unix source code, 

Yes, much of which was written on a teletype originally.

I've seen plenty of camelcase in application code.

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

#383350

On 04.03.2024 18:34, Mike Sanders wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 
>> The "problem" is that you may want to have -h as an option character,
>> especially if your program supports a lot of options and you have no
>> creative naming way of choosing another character. (An example from
>> one of my recent implementations is using -h for 'height'.[*])
> 
> This is my rationale as well: All of the switches have a more/or less
> mnemonic feel -X (eXport), -H (Holiday), -C (Calendar), -M (Manual).
> 
> I thought it made good sense at least. 

Yes, of course it does. Most software developers obviously try
to choose memorable mnemonics. (Imagine we'd have -o1 -o2 -o3
..., or -a -b -c ..., as option interface design rules.)

I wonder, though, my you've chosen letters in caps; I'd avoided
the additional <shift> key press. (First I thought it might be
some Windows/DOS restriction or so.)

Janis

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web