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

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

getFirstDayOfMonth()

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

Contents

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

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

#383359

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

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

#383425

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

Of course, on both platforms, it's up to application code to interpret 
the options passed on the command line.  There's nothing to stop a 
Windows utility from using "-x", or a *nix utility using "/X" - and a 
utility ported from one platform to the other might stick with the 
option style from the original platform.   Using "/" to indicate options 
on *nix might cause problems for anyone wanting to pass an absolute 
path, though...

-- 
Mark.

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

#383426

Mark Bourne <nntp.mbourne@spamgourmet.com> writes:
>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).

Ah, Powershell.   The COBOL of scripting languages.
>
>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).

In my experience, the '-?' is derived from the getopt(3) semantics
where it returns the option character '?' for any undefined
option flags.

Which means that

  switch (getopt(...)) {
  case '?':
      usage();
      break;
  }

handles  both -? and any undefined flags.

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

#383310

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

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

#383311

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

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

#383314

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

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

#383340

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

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

#383341

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

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

#383342

Mike Sanders <porkchop@invalid.foo> wrote:

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

Make that instead:

[ cmd ] || failure

-- 
:wq
Mike Sanders

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

#383353 — [OT] Re: getFirstDayOfMonth()

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

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

#383360 — Re: [OT] Re: getFirstDayOfMonth()

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

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

#383389

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 ]

One performance note about this.

  '[' does a PATH lookup, finding a utility
(actually a link to the 'test' utility) followed by fork(2)
and exec(2)).

  '[[' is built into the shell, so more efficient.

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

#383396

scott@slp53.sl.home (Scott Lurndal) writes:
> 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 ]
>
> One performance note about this.
>
>   '[' does a PATH lookup, finding a utility
> (actually a link to the 'test' utility) followed by fork(2)
> and exec(2)).
>
>   '[[' is built into the shell, so more efficient.

'[' is typically both a shell builtin (in bash, ksh, zsh) and an
executable (/usr/bin/[ and/or /bin/[).

'[[', in shells where it exists, is a pure builtin and not also an
executable.

In any case, there's no reason to use '[' in the above command, and in
fact it's a syntax error.  It may be a result of the common
misconception that '[' and ']' are part of the syntax of a shell 'if'
statement.  The performance of '[' doesn't matter if it's being used
incorrectly.

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

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

#383331

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"

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

#383335

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

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

#383379

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

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

#383617

Michael S <already5chosen@yahoo.com> writes:

> 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;
> }

I've seen the idiomatic form before, and my reaction to it is
more of it being overly cute than overly tricky.  That said,
it is a bit on the tricky side;  even so, I'm not sure the cure
suggested is much better than the disease.  I would simply write
a single return statement:

    return  val < 0 ? -1  :  val > 0 ? 1  : 0;

(possibly condensed to take advantage of the 0/1 result of the
"greater than" operator for non-negative operands).

I suppose some people prefer the multiple return form to the ?:
form, although I'm not sure why except perhaps as a carryover
from earlier experience.

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

#383339

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

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

#383354

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

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

#383255

On 3/2/24 14:59, Mike Sanders wrote:
...
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.

It would be, if that's what POSIX required. Instead, it uses 0 - good,
non-zero bad. Note that 0 representing successful results is mandated by
the C standard as well. EXIT_SUCCESS is another way of indicating
success, which might or might not be the same as 0. EXIT_FAILURE is the
only portable way to indicate failure as far as C itself is concerned,
but if you're willing to write POSIX-specific code, you can use a much
wider variety of values. The same is true of all of the other operating
systems I've written C code for (Windows and VMS, mostly).

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

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.

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

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

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

csiph-web