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.

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).
>
>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.

The reason posix commands return zero for success
is because the posix (and all other shells)
check the exit status of a command and treat
non-zero values as failure.

$ grep 'sigdelset' asim.cpp
$ echo $?
1 $ grep 'sigaddset' asim.cpp
sigaddset(&signals, SIGHUP);
sigaddset(&signals, SIGABRT);
sigaddset(&signals, SIGPIPE);
sigaddset(&signals, SIGUSR1);
sigaddset(&signals, SIGUSR2);
sigaddset(&sa.sa_mask, SIGHUP);
sigaddset(&sa.sa_mask, SIGINT);
sigaddset(&sa.sa_mask, SIGQUIT);
sigaddset(&sa.sa_mask, SIGTERM);
sigaddset(&sa.sa_mask, SIGXCPU);
$ echo $?
0

if grep -q 'sigaddset' asim.cpp
then
echo "Found it!"
fi

>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.

It's not 0/1, it is 0 for success and non-zero for
failure, where the failure is indicated by the
exit value (often restricted to 8-bits due to
the legacy wait(2) system call, however the
newer (for some value of new) system call waitid(2)
supports the full 32-bit exit status).

For example, the grep command returns
0 - success
1 - No lines were matched/selected
>1 - An error occurred.

Some utilities define additional exit status values.

VMS defined '1' (SS$_NORMAL) as the success return
value from system calls and commands, which is likely
the source of that feature in windows.

I've yet to find any feature of windows that is truely
superior (rather than just different).

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.

jak <nospam@please.ty> writes:

> Kenny McCormack ha scritto:
>
>> In article <urrj5l$124o9$1@dont-email.me>,
>> Mike Sanders <porkchop@invalid.foo> wrote:
>>
>>> Just sharing what I've learned, hope some of you can adapt
>>> it for your own use.
>>>
>>> Calculates the name of the weekday (Sun, Mon, etc) for the
>>> 1st day of a given month & year...
>>>
>>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
>>
>> Here's the guts of my version of the Zeller algorithm:
>>
>> int day(d,m,y)
>> int d, m, y;
>> {
>> if (m < 3) {
>> m += 12;
>> y--;
>> }
>> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
>
> I am referring in particular to this part of the equation:
> y + y/4 - y/100 + y/400
> Shouldn't it be calculated in a floating point and then truncated only
> the final result? Because, for example, if the year is 2024, the
> floating point calculation is 2514 (2514.82) while executed between
> integer is 2515.

The short answer is No. If you try some examples I expect
you will see that using integer division always gives
correct results. Leap days always happen in integer amounts,
so integer division is the right way to calculate them.

Note: I haven't tested this particular algorithm and so
cannot vouch for its correctness. But the part that
determines an extra number of days based on what year
it is matches other algorithms that I have tested.

porkchop@invalid.foo (Mike Sanders) writes:

> Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> That must not have been for 2024, or you have a bug.
>
> Well Scott, in the code of the link posted its displaying 2022:
>
> int year = 2022;
>
>> A calendar utility comes with most linux systems. It also supports
>> ISO 8601 which starts the week on Monday instead of Sunday.
>
> Yes sir, I know that. But I want to build my own instead so I can
> learn more about it. Even if that means reiventing the wheel, at
> least I'll learn it as I wish. Hoping not to sound contrite,
> cant we all just help each other learn? Darn man.

If you want to reinvent wheels, I suggest looking for some
rather more interesting wheels.

On Sun, 03 Mar 2024 15:24:29 GMT
scott@slp53.sl.home (Scott Lurndal) 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).
> >
> >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.
>
> The reason posix commands return zero for success
> is because the posix (and all other shells)
> check the exit status of a command and treat
> non-zero values as failure.
>
> $ grep 'sigdelset' asim.cpp
> $ echo $?
> 1
> $ grep 'sigaddset' asim.cpp
> sigaddset(&signals, SIGHUP);
> sigaddset(&signals, SIGABRT);
> sigaddset(&signals, SIGPIPE);
> sigaddset(&signals, SIGUSR1);
> sigaddset(&signals, SIGUSR2);
> sigaddset(&sa.sa_mask, SIGHUP);
> sigaddset(&sa.sa_mask, SIGINT);
> sigaddset(&sa.sa_mask, SIGQUIT);
> sigaddset(&sa.sa_mask, SIGTERM);
> sigaddset(&sa.sa_mask, SIGXCPU);
> $ echo $?
> 0
>
> if grep -q 'sigaddset' asim.cpp
> then
> echo "Found it!"
> fi
>
> >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.
>
> It's not 0/1, it is 0 for success and non-zero for
> failure, where the failure is indicated by the
> exit value (often restricted to 8-bits due to
> the legacy wait(2) system call, however the
> newer (for some value of new) system call waitid(2)
> supports the full 32-bit exit status).
>
> For example, the grep command returns
> 0 - success
> 1 - No lines were matched/selected
> >1 - An error occurred.
>
> Some utilities define additional exit status values.
>
> VMS defined '1' (SS$_NORMAL) as the success return
> value from system calls and commands, which is likely
> the source of that feature in windows.
>

Source of what feature in Windows?
Windows does not care too much about exit code, but to the level it
does care it follows the same conventions as Unix.

> I've yet to find any feature of windows that is truely
> superior (rather than just different).

How about F8 in cmd.exe shell?
Is not it non-trivially better than Crrl-r ?

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

Michael S <already5chosen@yahoo.com> writes:
>On Sun, 03 Mar 2024 15:24:29 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>

>
>> I've yet to find any feature of windows that is truely
>> superior (rather than just different).
>
>How about F8 in cmd.exe shell?
>Is not it non-trivially better than Crrl-r ?

I have no idea what F8 does in cmd.exe.

Or crrl-r.

Tim Rentsch ha scritto:
> jak <nospam@please.ty> writes:
>
>> Kenny McCormack ha scritto:
>>
>>> In article <urrj5l$124o9$1@dont-email.me>,
>>> Mike Sanders <porkchop@invalid.foo> wrote:
>>>
>>>> Just sharing what I've learned, hope some of you can adapt
>>>> it for your own use.
>>>>
>>>> Calculates the name of the weekday (Sun, Mon, etc) for the
>>>> 1st day of a given month & year...
>>>>
>>>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
>>>
>>> Here's the guts of my version of the Zeller algorithm:
>>>
>>> int day(d,m,y)
>>> int d, m, y;
>>> {
>>> if (m < 3) {
>>> m += 12;
>>> y--;
>>> }
>>> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
>>
>> I am referring in particular to this part of the equation:
>> y + y/4 - y/100 + y/400
>> Shouldn't it be calculated in a floating point and then truncated only
>> the final result? Because, for example, if the year is 2024, the
>> floating point calculation is 2514 (2514.82) while executed between
>> integer is 2515.
>
> The short answer is No. If you try some examples I expect
> you will see that using integer division always gives
> correct results. Leap days always happen in integer amounts,
> so integer division is the right way to calculate them.
>
> Note: I haven't tested this particular algorithm and so
> cannot vouch for its correctness. But the part that
> determines an extra number of days based on what year
> it is matches other algorithms that I have tested.
>

Thank you

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.

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

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]

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> 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.

Embarrassed to say I know that, but had forgotten it...

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

Can of worms there too, '-h' (or whatever) is valid file name. Under win,
we also use '/h' which certainly wont work under unix.

>> 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.

int ok = strcmp(foo, bar);

if (!ok) then success

ok == -1 less
ok == 0 same
ok == 1 greater

Hmm, so for someone from a differing OS, things need to be considered.
> Use 0 for success, 1 for unspecified errors, and other positive values
> for more specific errors.

This is not a problem under win, I've got lots of tools that use
varying %errorlevels% (unix analog '$?') all processed without
issue by %comspec% (analog '$SHELL'). No big deal.

But I'll take your word, here's where I'm at...

Usage: DATES [-OPTIONS] FILE1 [FILE2 ...]

-A=NUM Number of days in advance to look ahead (366 max)
-P=NUM Number of days in the past to look back (366 max)
-S=NUM Separate date fields using: 1 Slash, 2 Dash, 3 Dot
-X=NUM Export results as: 1 TXT, 2 CSV, 3 SQL, 4 HTML
-T=TAG Filter results for 'TAG' (16 characters max)
-I Use ISO8601 dates: yyyy/mm/dd (default is mm/dd/yyyy)
-W Include weekday abbreviations
-H Include holidays (see manual for list)
-F Include attribute flags (see manual for details)
-C Display calendar for current year
-D Debugging enabled
-M Display embedded user manual

Error levels returned:

0 Success
1 Error

'debugger' is a simple printf macro that among other things,
confirms my returns:

dates -a=30 -d -t="bank note" file

DEBUG: Exit 1

I'm getting there, in fact real close.

Thanks Keith.

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> 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.
>
>Embarrassed to say I know that, but had forgotten it...
>
>> And most users of Unix-like systems won't expect '-?' to be an option;
>> '-h' is much more common.
>
>Can of worms there too, '-h' (or whatever) is valid file name. Under win,
>we also use '/h' which certainly wont work under unix.

No, there is no chance of '-h' being interpreted as a filename.

The issue is that _iff_ there is a two character filename in
the current working directory where the first character of
the filename is the hypen character, the shell may substitute that
for '-?' when parsing the command line. E.g if you had a file
called '-F' in the current working directory, the shell may
change '-?' (if not quoted) into '-F'.

Pesonally, I find this highly unlikely in real world. However,
there are cases where this could be a security issue.

> The C standard, not just POSIX, defines 0 as a successful status.

POSIX defines 0 as a successful status "for shell commmands", in
the context of this discussion.

Unix defines 0 as a successful status for system calls handled
by the kernel. A non-zero status is accompanied by an updated
errno (thread-specific when threaded) value.

strcmp(3) is neither a command nor a kernel call, it's a
library function and the return value is well documented.

I refer you to Ralph Waldo Emerson's quote about consistency :-).

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

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).

scott@slp53.sl.home (Scott Lurndal) writes:
> porkchop@invalid.foo (Mike Sanders) writes:
[...]
>> The C standard, not just POSIX, defines 0 as a successful status.
>
> POSIX defines 0 as a successful status "for shell commmands", in
> the context of this discussion.
>
> Unix defines 0 as a successful status for system calls handled
> by the kernel. A non-zero status is accompanied by an updated
> errno (thread-specific when threaded) value.

The C standard defines 0 as an argument to exit() or as a return value
from main() as a successful status. System calls are a separate issue
(but they happen to follow a similar convention for similar reasons.)

[...]

--
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 */

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

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

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> The lack of nuance is apparently the result of your being unaware of the
> fact that 1 is not the only permitted error return.
>
> Keep in mind that the make utility and shells designed for Unix-like
> systems (as well as many other programs targeting such systems) expect 0
> for success, and may produce unexpected results if you violate that
> convention.

Not at all, what the shell accepts as success under unix, is not the
same under windows. The convention is OS specific, everyone here tends
to think only in terms of POSIX & $SHELL & yet, there are other worlds
out there...

:: comment

@echo off & cls

if %errorlevel% EQU 1000 (

echo successful as defined by my needs not yours

)

--
:wq
Mike Sanders

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.

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

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.

On 3/4/24 13:21, Mike Sanders wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> The lack of nuance is apparently the result of your being unaware of the
>> fact that 1 is not the only permitted error return.
>>
>> Keep in mind that the make utility and shells designed for Unix-like
>> systems (as well as many other programs targeting such systems) expect 0
>> for success, and may produce unexpected results if you violate that
>> convention.
>
> Not at all, what the shell accepts as success under unix, is not the
> same under windows.

I was talking about the problems you would have with ignoring that
convention on Unix-like systems, which I'm very familiar with, I had no
intention of giving advice relevant to other operating systems. The need
to do different things on different operating systems is part of the
reason why the EXIT_SUCCESS and EXIT_FAILURE macros exist, but that only
scratches the surface of what needs to be done for portability.
If your program needs to be portable to POSIX systems, it needs to have
a mode that returns 0 on success, regardless of what it does on any
other operating system.