On Mon, 04 Mar 2024 17:26:21 +0000, Mike Sanders wrote:

> 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

Ahhhhh..... no. (CLC has had this conversation before :-) )

The standard only guarantees that strcmp()
"returns an integer greater than, equal to, or less than zero"
but otherwise does not state what value that integer will be.

So, strcmp() could just as easily return -30 for "less than"
or +97 for "greater than".

If you want to /guarantee/ that the return value of strcmp()
is -1, 0, or +1 (for "less than", "equal to", or "greater than")
you will have to process the return value with something like

/*
** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument > 0
*/
int iSignOf(int valu)
{
return ((valu > 0) - (valu < 0));
}

as in
int ok = isignof(strcmp(foo, bar));

> Hmm, so for someone from a differing OS, things need to be considered.

Always.

HTH
--
Lew Pitcher
"In Skills We Trust"

On Mon, 4 Mar 2024 21:21:25 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

> On Mon, 04 Mar 2024 17:26:21 +0000, Mike Sanders wrote:
>
> > 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
>
> Ahhhhh..... no. (CLC has had this conversation before :-) )
>
> The standard only guarantees that strcmp()
> "returns an integer greater than, equal to, or less than zero"
> but otherwise does not state what value that integer will be.
>
> So, strcmp() could just as easily return -30 for "less than"
> or +97 for "greater than".
>
> If you want to /guarantee/ that the return value of strcmp()
> is -1, 0, or +1 (for "less than", "equal to", or "greater than")
> you will have to process the return value with something like
>
> /*
> ** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument > 0
> */
> int iSignOf(int valu)
> {
> return ((valu > 0) - (valu < 0));
> }
>

Too tricky to my liking.
I'd rather write straight-forward code and let compiler to figure out
the best sequence.

int iSignOf(int val)
{ if (val < 0)
return -1;
if (val > 0)
return +1;
return 0;
}

https://godbolt.org/z/TzsevxKeE
https://godbolt.org/z/TzsevxKeE

> as in
> int ok = isignof(strcmp(foo, bar));
>
>
> > Hmm, so for someone from a differing OS, things need to be
> > considered.
>
> Always.
>
> HTH

porkchop@invalid.foo (Mike Sanders) writes:
> 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
>
> )

Sure, you can write a script that assumes 1000 indicates success -- but
it's just as non-idiomatic on Windows as on POSIX systems. (POSIX only
supports values from 0 to 255.)

some_command
if [ $? = 100 ] ; then
echo SUCCESS
else
echo FAILURE
fi

But Windows, like POSIX, has a convention than an exit code of zero
denotes success, and non-zero denotes an error. The convention probably
isn't as hardwired into the system on Windows as it is on POSIX, but
it's there.

For example, the documentation for the C# Environment.Exit() function
says "Use 0 (zero) to indicate that the process completed
successfully.". Windows cmd (the command that runs batch files) has a
special syntax in its "if" statement that tests the value of
%errorlevel; "if errorlevel 1" is used to test if the errorlevel is 1 or
greater, i.e., denotes failure.

VMS (officially OpenVMS) uses 1 to denote success, which is why exit(0)
in a VMS C program sets the system status to 1, not 0.

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

On Mon, 4 Mar 2024 18:21:06 -0000 (UTC)
porkchop@invalid.foo (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. 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
>
> )
>

However all Microsoft-supplied utilities as well as most (all ?)
built-in commands of their shells , like 'copy' or 'move', follow Unix
conventions for exit codes.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

>> int ok = strcmp(foo, bar);
>>
>> if (!ok) then success
>>
>> ok == -1 less
>> ok == 0 same
>> ok == 1 greater
>
> Ahhhhh..... no. (CLC has had this conversation before :-) )
>
> The standard only guarantees that strcmp()
> "returns an integer greater than, equal to, or less than zero"
> but otherwise does not state what value that integer will be.
>
> So, strcmp() could just as easily return -30 for "less than"
> or +97 for "greater than".
>
> If you want to /guarantee/ that the return value of strcmp()
> is -1, 0, or +1 (for "less than", "equal to", or "greater than")
> you will have to process the return value with something like
>
> /*
> ** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument > 0
> */
> int iSignOf(int valu)
> {
> return ((valu > 0) - (valu < 0));
> }
>
> as in
> int ok = isignof(strcmp(foo, bar));
>
>
>> Hmm, so for someone from a differing OS, things need to be considered.
>
> Always.
>
> HTH

Yes sir, it does help in fact, copied to my notes. Lots of brainfood
from you all, appreciate it =)

--
:wq
Mike Sanders

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

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

Sure enough & Keith as well. Cobbled together a simple solution
just display more informative error messages as well as sticking
to zero/one. This satisfies scripting in the unix world:

[ dates -op1 -op2 file || echo no banana ]

And specific messaging in the windows world (-d is my new debug
switch):

C:\type junk.txt

fubar/5/2024

C:\dates -op1 -op2 -d junk.txt

DEBUG: Invalid month field line 1 in file junk.txt

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

=)

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> POSIX defines 0 as a successful status "for shell commmands", in
>> the context of this discussion.
>
> Sure enough & Keith as well. Cobbled together a simple solution
> just display more informative error messages as well as sticking
> to zero/one. This satisfies scripting in the unix world:
>
> [ dates -op1 -op2 file || echo no banana ]

This is off-topic (try comp.unix.shell if you have questions), but you
should be aware that '[' on POSIX systems is actually a command, not
shell syntax. (It's typically a built-in command. This applies to most
shells, like sh, bash, ksh, but not to csh, tcsh, fish.)

"[ args... ]" is equivalent to "test ...". You'll see the [ command
used as a condition in shell if statements, which makes it easy to
assume (incorrectly) that it's part of the syntax of an if statement.
In fact a shell "if" statement uses a command as its condition, and
determines control flow based on whether the command succeeds or fails.

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

Mike Sanders <porkchop@invalid.foo> wrote:

> [ dates -op1 -op2 file || echo no banana ]

Make that instead:

[ cmd ] || failure

--
:wq
Mike Sanders

Michael S <already5chosen@yahoo.com> wrote:

> However all Microsoft-supplied utilities as well as most (all ?)
> built-in commands of their shells , like 'copy' or 'move', follow Unix
> conventions for exit codes.

Well, maybe not so much in practice as in theory, witness...

cmd /c exit -1073741510

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:
> Michael S <already5chosen@yahoo.com> wrote:
>> However all Microsoft-supplied utilities as well as most (all ?)
>> built-in commands of their shells , like 'copy' or 'move', follow Unix
>> conventions for exit codes.
>
> Well, maybe not so much in practice as in theory, witness...
>
> cmd /c exit -1073741510

I'm not sure what your point is. Of course if a command lets you
specify a particular error code, it will use that error code regardless
of any conventions. Or is your point that Windows supports a wider
range of error codes than POSIX does?

Windows follows the Unix convention of commands returning an exit status
of zero for success, non-zero for failure. I don't know why you're so
determined to fight against that point. There are differences in the
details (and better places to discuss them). Status values in the range
0..255 are likely to be reasonably portable across POSIX and Windows
systems.

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

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

> Sure, you can write a script that assumes 1000 indicates success -- but
> it's just as non-idiomatic on Windows as on POSIX systems. (POSIX only
> supports values from 0 to 255.)
>
> some_command
> if [ $? = 100 ] ; then
> echo SUCCESS
> else
> echo FAILURE
> fi
>
> But Windows, like POSIX, has a convention than an exit code of zero
> denotes success, and non-zero denotes an error. The convention probably
> isn't as hardwired into the system on Windows as it is on POSIX, but
> it's there.
>
> For example, the documentation for the C# Environment.Exit() function
> says "Use 0 (zero) to indicate that the process completed
> successfully.". Windows cmd (the command that runs batch files) has a
> special syntax in its "if" statement that tests the value of
> %errorlevel; "if errorlevel 1" is used to test if the errorlevel is 1 or
> greater, i.e., denotes failure.
>
> VMS (officially OpenVMS) uses 1 to denote success, which is why exit(0)
> in a VMS C program sets the system status to 1, not 0.

Interesting stuff. The main thing with me is to (under Windows at least)
facilitate an easier way to use my tool in an automated way.

The GetExitCodeProcess function documentation specifies that the ExitCode
is a "DWORD 32-bits integer". This means that from cmd.exe point of view
(remember, cmd.exe *is the primary interface* or shell under win):

(emphasis mine)

*****
an .exe program may return as %ERRORLEVEL% a value from -2147483648 to
2147483647
*****

So... yeah. I mean, I would rather leverage that force multiplier than not.

--
:wq
Mike Sanders

On 2024-03-05, Mike Sanders <porkchop@invalid.foo> wrote:
> Interesting stuff. The main thing with me is to (under Windows at least)
> facilitate an easier way to use my tool in an automated way.
>
> The GetExitCodeProcess function documentation specifies that the ExitCode
> is a "DWORD 32-bits integer". This means that from cmd.exe point of view
> (remember, cmd.exe *is the primary interface* or shell under win):
>
> (emphasis mine)
>
> *****
> an .exe program may return as %ERRORLEVEL% a value from -2147483648 to
> 2147483647
> *****

Your reasoning is far from air tight here.

Consider that on Unix, the exit system call takes an "int". Does that
mean that any value from INT_MIN to INT_MAX will be passed through
cleanly as a termination status?

For monitoring the status of a child process, you can use waitpid.
Again, that takes a pointer to an int.

That int is not simply an exit code. It can indicate whether the
process terminated successfully or abnormally (due to a fatal signal),
and if abnormally, which signal. There are portable C macros for
obtaining this information, like WIFEXITED and whatnot.

In the Microsoft exit code case, the docuumentation says:

This function returns immediately. If the process has not terminated
and the function succeeds, the status returned is STILL_ACTIVE (a
macro for STATUS_PENDING (minwinbase.h)). If the process has
terminated and the function succeeds, the status returned is one of
the following values:

- The exit value specified in the ExitProcess or TerminateProcess
function.

- The return value from the main or WinMain function of the process.

- The exception value for an unhandled exception that caused the
process to terminate.

So while you could use any value in the DWORD range, some of the values would
be confused for STILL_ACTIVE, STATUS_PENDING, or might look like the
code of an unhandled exception (I'm guessing 0xCxxxxxxx? Or are therere
others). If you don't want to know what all those are, and don't require
a vast range of exit statuses, your best bet is probably to stick to
small, nonnegative integers.

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

porkchop@invalid.foo (Mike Sanders) writes:
[...]
> Interesting stuff. The main thing with me is to (under Windows at least)
> facilitate an easier way to use my tool in an automated way.
>
> The GetExitCodeProcess function documentation specifies that the ExitCode
> is a "DWORD 32-bits integer". This means that from cmd.exe point of view
> (remember, cmd.exe *is the primary interface* or shell under win):
>
> (emphasis mine)
>
> *****
> an .exe program may return as %ERRORLEVEL% a value from -2147483648 to
> 2147483647
> *****
>
> So... yeah. I mean, I would rather leverage that force multiplier than not.

Why?

Sure, assuming %ERRORLEVEL% can really take on any integer value from
-2147483648 to +2147483647 (I don't know whether it can), you can write
Windows-specific code that takes full advantage of that range.

Do you really have a requirement to use that full range? Do you have
several billion distinct error conditions that you want to report? Or
are you using %ERRORLEVEL% as some kind of counter? You've only shown
us 4 distinct error conditions for the tool we were discussing.

On POSIX, "$?" is restricted to the range 0 to 255. Do you really need
more than 256 distinct status codes? (The most I've seen in any common
command is less than 100, for curl, and that's a rather extreme
outlier.)

If you don't care about portability to non-Windows systems, that's fine,
but then there are better places to discuss your requirements.

The C standard doesn't guarantee more than 0, EXIT_SUCCESS (which is
usually equal to 0), and EXIT_FAILURE.

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

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

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

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

On 05.03.2024 01:12, Mike Sanders wrote:
> Mike Sanders <porkchop@invalid.foo> wrote:
>
>> [ dates -op1 -op2 file || echo no banana ]

ITYM:

dates -op1 -op2 file || echo no banana

>
> Make that instead:
>
> [ cmd ] || failure

This makes little sense. Either write

cmd || failure

(with cmd and failure being commands), or write

[ test-cond ] || failure

with the '[' being another form of the 'test' command

test test-cond || failure

and test-cond being any valid test condition.

There's also other applications possible, like, say,

[ -n "$(cmd)" ] || failure

that somewhat resembles your cmd expression above.

Janis

On 04.03.2024 22:21, Lew Pitcher wrote:
>
> If you want to /guarantee/ that the return value of strcmp()
> is -1, 0, or +1 (for "less than", "equal to", or "greater than")
> you will have to process the return value with something like
>
> /*
> ** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument > 0
> */
> int iSignOf(int valu)
> {
> return ((valu > 0) - (valu < 0));
> }

Neat!

Janis

Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> Your reasoning is far from air tight here.

Hey-hey Kaz! But I've got a simple way...

> For monitoring the status of a child process, you can use waitpid.
> Again, that takes a pointer to an int.

For threaded stuff & children I'm actually not sure. Was under the
impression that the parent's return value was defacto, YMMV.

> So while you could use any value in the DWORD range, some of the values would
> be confused for STILL_ACTIVE, STATUS_PENDING, or might look like the
> code of an unhandled exception (I'm guessing 0xCxxxxxxx? Or are therere
> others). If you don't want to know what all those are, and don't require
> a vast range of exit statuses, your best bet is probably to stick to
> small, nonnegative integers.

Here's the way I'm handling it (the error code debate), because the app
I'm working is a subsystem exe (console only in this case as you know),
I don't have WinMain(), & a confounded message pump (so never need to
filter WM_CLOSE, WM_DESTROY, etc) no manifest, no packed icons (multiple
icons are required now - ugh) & all the rest, just plain-jane main() &
am happily (mercifully?) insulated from several layers of abstraction.
That & limiting myself to a range, likely the real secret sauce...

class 3 errors: 300x
class 2 errors: 200x
class 1 errors: 100x

So 3 cheers for subsystem exes' small & quick. but hey, I'm getting close
rankling the other guys so I'll let it be.

Saw your page too at: https://www.kylheku.com/~kaz/

You're a very creative guy, keep on keepin' on =)

--
:wq
Mike Sanders

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

> Why?
>
> Sure, assuming %ERRORLEVEL% can really take on any integer value from
> -2147483648 to +2147483647 (I don't know whether it can), you can write
> Windows-specific code that takes full advantage of that range.
>
> Do you really have a requirement to use that full range? Do you have
> several billion distinct error conditions that you want to report? Or
> are you using %ERRORLEVEL% as some kind of counter? You've only shown
> us 4 distinct error conditions for the tool we were discussing.
>
> On POSIX, "$?" is restricted to the range 0 to 255. Do you really need
> more than 256 distinct status codes? (The most I've seen in any common
> command is less than 100, for curl, and that's a rather extreme
> outlier.)
>
> If you don't care about portability to non-Windows systems, that's fine,
> but then there are better places to discuss your requirements.
>
> The C standard doesn't guarantee more than 0, EXIT_SUCCESS (which is
> usually equal to 0), and EXIT_FAILURE.

Its no big deal Keith =) I'll let it ride, but earnest thanks for all
your help.

--
:wq
Mike Sanders

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

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

Considering also --gnu-style, might remove some ambiguities
here & there.

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

Honestly just habit... the options are all case-insensitive
in the app across all platforms. Still very much, a work in
progress. I learn, I try new things, I mess up & try again =)

--
:wq
Mike Sanders

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

>> [ cmd ] || failure
>
> This makes little sense. Either write
>
> cmd || failure
>
> (with cmd and failure being commands), or write
>
> [ test-cond ] || failure
>
> with the '[' being another form of the 'test' command
>
> test test-cond || failure
>
> and test-cond being any valid test condition.
>
> There's also other applications possible, like, say,
>
> [ -n "$(cmd)" ] || failure
>
> that somewhat resembles your cmd expression above.
>
> Janis

Another post for my notes (about dozen or more of yours now).

Thanks.

--
:wq
Mike Sanders

On Tue, 5 Mar 2024 00:37:23 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Mon, 4 Mar 2024 21:21:25 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
> > On Mon, 04 Mar 2024 17:26:21 +0000, Mike Sanders wrote:
> >
> > > 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
> >
> > Ahhhhh..... no. (CLC has had this conversation before :-) )
> >
> > The standard only guarantees that strcmp()
> > "returns an integer greater than, equal to, or less than zero"
> > but otherwise does not state what value that integer will be.
> >
> > So, strcmp() could just as easily return -30 for "less than"
> > or +97 for "greater than".
> >
> > If you want to /guarantee/ that the return value of strcmp()
> > is -1, 0, or +1 (for "less than", "equal to", or "greater than")
> > you will have to process the return value with something like
> >
> > /*
> > ** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument
> > > 0 */
> > int iSignOf(int valu)
> > {
> > return ((valu > 0) - (valu < 0));
> > }
> >
>
> Too tricky to my liking.
> I'd rather write straight-forward code and let compiler to figure out
> the best sequence.
>
> int iSignOf(int val)
> {
> if (val < 0)
> return -1;
> if (val > 0)
> return +1;
> return 0;
> }
>
> https://godbolt.org/z/TzsevxKeE
> https://godbolt.org/z/TzsevxKeE
>
>

I posted the same link twice by mistake. Meant this
https://godbolt.org/z/4rcfqrje7

Groovy hepcat Kaz Kylheku was jivin' in comp.lang.c on Sat, 2 Mar 2024
02:44 pm. It's a cool scene! Dig it.

> On 2024-03-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> int day(d,m,y)
>> int d, m, y;
>> {
> [...]
>> BTW, how long do you think it will be until this thread gets hijacked
>> into a long, acrimonious debate about what the definition of the
>> first day of the month is and how various cultures define it
>> differently, and how
>
> Pissing on new code using old-style C in 5... 4... 3....

I'm surprised noone's mentioned this until now.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Groovy hepcat jak was jivin' in comp.lang.c on Sat, 2 Mar 2024 12:49 pm.
It's a cool scene! Dig it.

> 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;
>
> Hi,
> 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.

No. The "+ y/4 - y/100 + y/400" part is adding a day for each leap
year. You see, a leap year is divisible by 4, but is not divisible by
100, but is divisible by 400. So, it's adding the number of years
divisible by 4, subtracting those divisible by 100 and adding those
divisible by 400 to determine the number of leap days up to the given
date.
So often in the last week or two I've heard people (who ought to know
better) on news programs on telly say that a leap year comes every 4
years, and I want to beat them about the head with a humorous object of
some kind until they get this right! A leap year does NOT come EVERY 4
years.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!