zebscripts/AFK-Daily

Support WSL when checking for OSs to use date command

Closed this issue ยท 6 comments

This issue originated from #144.

WSL will be detected as a Linux OS on our script, even though the date command apparently still behaves like a Windows command. After researching a bit, making use of the uname -a command with grep seems to be a viable option to solve this issue.

I tested the date command on 3 different systems (ubuntu on WSL, ubuntu on raspberry pi 3B+, macos 11.16.2) and all of them have -d as argument for string output:

$ uname -a
Darwin LAPTOP 20.6.0 Darwin Kernel Version 20.6.0: Wed Nov 10 22:23:07 PST 2021; root:xnu-7195.141.14~1/RELEASE_X86_64 x86_64 i386 MacBookPro16,1 Darwin

$ date --help | head -n 8
Usage: date [OPTION]... [+FORMAT]
  or:  date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
Display the current time in the given FORMAT, or set the system date.

Mandatory arguments to long options are mandatory for short options too.
  -d, --date=STRING          display time described by STRING, not 'now'
$ uname -a
Linux ubuntu 5.4.0-1047-raspi #52-Ubuntu SMP PREEMPT Wed Nov 24 08:16:38 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

$ date --help | head -n 6
Usage: date [OPTION]... [+FORMAT]
  or:  date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
Display the current time in the given FORMAT, or set the system date.

Mandatory arguments to long options are mandatory for short options too.
  -d, --date=STRING          display time described by STRING, not 'now'
$ uname -a
Linux WINPC 4.4.0-18362-Microsoft #1801-Microsoft Sat Sep 11 15:28:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux

$ date --help | head -n 6
Usage: date [OPTION]... [+FORMAT]
  or:  date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
Display the current time in the given FORMAT, or set the system date.

Mandatory arguments to long options are mandatory for short options too.
  -d, --date=STRING          display time described by STRING, not 'now'

Maybe I'm missing something but I don't find -v argument on any of those systems as I see is defined in the script:

    case "$(uname -s)" in # Check OS
    Darwin | Linux)       # Mac / Linux
        d1=$(date -v "${1:-"$(date +%Y%m%d)"}" +%s)
        d2=$(date -v "${2:-"$(date +%Y%m%d)"}" +%s)
        ;;
    CYGWIN* | MINGW32* | MSYS* | MINGW*) # Windows
        d1=$(date -d "${1:-"$(date +%Y%m%d)"}" +%s)
        d2=$(date -d "${2:-"$(date +%Y%m%d)"}" +%s)
        ;;
    esac
$ uname -a
Darwin LAPTOP 19.6.0 Darwin Kernel Version 19.6.0: Sun Nov 14 19:58:51 PST 2021; root:xnu-6153.141.50~1/RELEASE_X86_64 x86_64

$ date --help
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

https://www.unix.com/man-page/osx/1/date/

 -v      Adjust (i.e., take the current date and display the result of the adjustment; not actually set the date) the second, minute, hour,
   month day, week day, month or year according to val.  If val is preceded with a plus or minus sign, the date is adjusted forwards or
   backwards according to the remaining string, otherwise the relevant part of the date is set.  The date can be adjusted as many times
   as required using these flags.  Flags are processed in the order given.

   When setting values (rather than adjusting them), seconds are in the range 0-59, minutes are in the range 0-59, hours are in the
   range 0-23, month days are in the range 1-31, week days are in the range 0-6 (Sun-Sat), months are in the range 1-12 (Jan-Dec) and
   years are in the range 80-38 or 1980-2038.

   If val is numeric, one of either y, m, w, d, H, M or S must be used to specify which part of the date is to be adjusted.

   The week day or month may be specified using a name rather than a number.	If a name is used with the plus (or minus) sign, the date
   will be put forwards (or backwards) to the next (previous) date that matches the given week day or month.	This will not adjust the
   date, if the given week day or month is the same as the current one.

   When a date is adjusted to a specific value or in units greater than hours, daylight savings time considerations are ignored.
   Adjustments in units of hours or less honor daylight saving time.	So, assuming the current date is March 26, 0:30 and that the DST
   adjustment means that the clock goes forward at 01:00 to 02:00, using -v +1H will adjust the date to March 26, 2:30.  Likewise, if
   the date is October 29, 0:30 and the DST adjustment means that the clock goes back at 02:00 to 01:00, using -v +3H will be necessary
   to reach October 29, 2:30.

   When the date is adjusted to a specific value that does not actually exist (for example March 26, 1:30 BST 2000 in the Europe/London
   timezone), the date will be silently adjusted forwards in units of one hour until it reaches a valid time.  When the date is adjusted
   to a specific value that occurs twice (for example October 29, 1:30 2000), the resulting timezone will be set so that the date
   matches the earlier of the two times.

   Adjusting the date by months is inherently ambiguous because a month is a unit of variable length depending on the current date.
   This kind of date adjustment is applied in the most intuitive way.  First of all, date tries to preserve the day of the month.  If it
   is impossible because the target month is shorter than the present one, the last day of the target month will be the result.  For
   example, using -v +1m on May 31 will adjust the date to June 30, while using the same option on January 30 will result in the date
   adjusted to the last day of February.  This approach is also believed to make the most sense for shell scripting.	Nevertheless, be
   aware that going forth and back by the same number of months may take you to a different date.

looks like date is different in BSD and GNU versions, not based on the os.
you an use the approach from here to use the correct one: https://stackoverflow.com/a/8748193

That does indeed seem like a viable solution, thank you for the link. I'd be able to use it in most cases in the repo, but I'm unsure for the ones inside convertAKFScriptTMPtoINI(). @kevingrillet, do you know the best approach for this situation?

case "$(uname -s)" in # Check OS
Darwin | Linux)       # Mac / Linux
  echo "lastCampaign=$(date -r "$(cat "$f")" +%Y%m%d)" >>./account-info/acc.ini
  ;;
CYGWIN* | MINGW32* | MSYS* | MINGW*) # Windows
  echo "lastCampaign=$(date -d "@$(cat "$f")" +%Y%m%d)" >>./account-info/acc.ini
  ;;

I think we don't care about this one XD
It's been more than 6 months since this one shot has been done ๐Ÿ˜„

And it's using -r not -v so I think it's working properly...

Alright then, thanks for the info. I'll try and take care of it today then.