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
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 assume the two versions end up being equivalent.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
[...]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
I'm certainly irritated about the OP's final
return (f % 7) - 1;
returning values from -1 to 5. And then using these indexes
to address a C array. (Looks wrong to me, but I'm anyway
not interested in second hand copies of generally available
algorithms; there's little value.)
Yes, that's a bug in the original code. The program only tests for
August 2024, but the algorithm fails for June 2024, which starts on
Saturday.
One fix is to change
return (f % 7) - 1;
to:
return (f + 6) % 7;
which works correctly at least for all months of 2024.
Yes. Though I'd have done the correction on the previous line.
int f = d + ... - 1;
return f % 7;
To me that would be clearer.
Janis
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 assume the two versions end up being equivalent.
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 >insensitive we are (especially, if "we" are USA Americans) to assume that
our way is the only way? A matter of hours, I suspect.
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;
}
Yes, that's a bug in the original code. The program only tests for
August 2024, but the algorithm fails for June 2024, which starts on
Saturday.
One fix is to change
return (f % 7) - 1;
to:
return (f + 6) % 7;
which works correctly at least for all months of 2024.
Negative index values can be valid. For example, foo[-1] can be valid,
but only if foo is a pointer to an array element other than the first
one, not if foo is an array object.
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 assume the two versions end up being equivalent.
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 insensitive we are (especially, if "we" are USA Americans) to assume that
our way is the only way? A matter of hours, I suspect.
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;
}
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2024 17:33, Janis Papanagnou wrote:
Yes. Though I'd have done the correction on the previous line.
int f = d + ... - 1;
return f % 7;
To me that would be clearer.
Or completely removing the 'd' and the '-1' since 'd' is actually
a (non-const declared) constant and equals to 1.
(Gee! Why do I mind, anyway.)
I think the point of defining 'd' is to allow for computing the day of
the week for days of the month other than the first. The code as
presented suggests a lot of opportunities for generalization (such as handling months other than August 2024). The local variable 'd' could
be replaced by a parameter 'int mday'.
That must not have been for 2024, or you have a bug.
A calendar utility comes with most linux systems. It also supports
ISO 8601 which starts the week on Monday instead of Sunday.
Kenny McCormack <gazelle@shell.xmission.com> wrote:
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've put this right to work too Kenny...
Prints calander for the given year with every 2 months adjacent
https://busybox.neocities.org/notes/adjacent-calendars.txt
Example...
Jan Feb
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
1 1 2 3 4 5
2 3 4 5 6 7 8 6 7 8 9 10 11 12
9 10 11 12 13 14 15 13 14 15 16 17 18 19
16 17 18 19 20 21 22 20 21 22 23 24 25 26
23 24 25 26 27 28 29 27 28
30 31
https://en.wikipedia.org/wiki/ISO_8601
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 assume the two versions end up being equivalent.
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 insensitive we are (especially, if "we" are USA Americans) to assume that
our way is the only way? A matter of hours, I suspect.
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
Scott Lurndal <scott@slp53.sl.home> wrote:
https://en.wikipedia.org/wiki/ISO_8601
Have partial ISO8601 compliance now (when using option: -D=2):
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)
-D=NUM Format dates as: 1 mm/dd/yyyy, 2 yyyy/mm/dd
-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)
-H Include holidays (see manual for list)
-W Include weekday abbreviations
-F Include attribute flags (see manual for details)
-C Display calendar for current year
-M Display embedded user manual
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
porkchop@invalid.foo (Mike Sanders) writes:
Usage: DATES [-OPTIONS] FILE1 [FILE2 ...]
[...]
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.
[...]
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.
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.
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.
porkchop@invalid.foo (Mike Sanders) writes:
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.
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;
'-h' is much more common.
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.
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.
1 - An error occurred.
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.
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.
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.
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.
Having "-h" as an option for something other than "--help" would be insane.
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 ?
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.
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.
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.
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.
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.
The C standard, not just POSIX, defines 0 as a successful status.
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.
And most users of Unix-like systems won't expect '-?' to be an option;
'-h' is much more common.
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.
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'.[*])
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.
You haven't provided any evidence or facts of experience.
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).
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.
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!
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?
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.
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.
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
)
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
POSIX defines 0 as a successful status "for shell commmands", in
the context of this discussion.
I refer you to Ralph Waldo Emerson's quote about consistency :-).
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
[ dates -op1 -op2 file || echo no banana ]
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.
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
*****
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.
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. [...]
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.
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));
}
Your reasoning is far from air tight here.
For monitoring the status of a child process, you can use waitpid.
Again, that takes a pointer to an int.
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.
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.
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.)
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
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....
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.
Pissing on new code using old-style C in 5... 4... 3....
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.
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 ]
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,
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.
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 Papanagnou wrote:
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.)
From what I've seen, usage help for Windows commands typically shows
options in uppercase, although they tend to be interpreted
case-insensitively (just as file names are on Windows). Windows
utilities also typically use "/" rather than "-" to indicate options (at >least before PowerShell). So "-x" for a *nix utility would more
typically be "/X" for a Windows utility (but typing "/x" would also work).
It's also quite common for Windows utilities to use "/?" rather than
"/H" to get usage help, which might be where the "-?" idea came from
(which I think I saw somewhere earlier in this thread).
bart ha scritto:
For most practical purposes and for the lifetimes of most of the 8
billion people on the planet, leap years do come every four years.
That's the case for years 1901 to 2099.
What exactly do you expect those news readers that reach a massive
audience to do, get into those details of being divisible or not by
100 or 400? Maybe they should also mention odd years like 1752 where
there was a calendar reform for even more exceptions to the rule.
Half the audience probably barely know what a leap year is.
You are right, but this usenet is followed by people, professionals and computer enthusiasts. I would like to try to make a statistics but I
think at least 70% read somewhere how to determine if a year is a leap.
I, example, discovered this by writing my first management program in
Rmcobol almost 40 years ago.
For most practical purposes and for the lifetimes of most of the 8
billion people on the planet, leap years do come every four years.
That's the case for years 1901 to 2099.
What exactly do you expect those news readers that reach a massive
audience to do, get into those details of being divisible or not by 100
or 400? Maybe they should also mention odd years like 1752 where there
was a calendar reform for even more exceptions to the rule.
Half the audience probably barely know what a leap year is.
On Mon, 4 Mar 2024 21:21:25 -0000 (UTC)[...]
Lew Pitcher <lew.pitcher@digitalfreehold.ca> 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));
}
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;
}
jak <nospam@please.ty> writes:
So, someone follows the ISO convention and others Julian but I
read somewhere that the ISO convention had to be followed in the
computer scope.
Where did you read that? ISO has no police force. [...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 465 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 36:35:39 |
| Calls: | 9,400 |
| Files: | 13,569 |
| Messages: | 6,098,443 |