0

when developing Bash scripts, sometimes I'll run it in a Docker container, or on a VM to test it, but the ideal place for me to build out scripts is just on my local MacOS workstation.

When it comes to Bash scripts, this has never been a problem so far. However today I noticed that the date command behaves differently between Linux and MacOS.

Example scenario, adding days to a date object:

Linux:

root@host$ date -d "$(date) 3 days" +%Y-%m-%d
2018-04-20

MacOS:

WS:tmp user$ date -d "$(date) 3 days" +%Y-%m-%d
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

Doesn't work, so I have to reformat it:

WS:tmp user$ date -j -v +3d -f "%Y-%m-%d" $(date +%Y-%m-%d) +%Y-%m-%d`
2018-04-20

What a pain! A simple bash script and now I need a container or VM just to do some simple date manipulation.

This is making me feel like I'm shooting myself in the foot developing this way, and the whole reason I got a Mac was because it's much closer to a 'nix environment than any Windows version so I could do simple local development on it.

My question(s):

  • Is this a licensing issue? It's my understanding that date is a GNU utility, so there shouldn't be any licensing issues.
  • Because I have not yet hit this issue until today, is there a known list of common apps that behave differently?
  • Is it "bad practice" to develop some bash scripts on a Mac? I've been doing it for a while now and never hit an issue until now.

Your experience with this topic is appreciated, thank you!

  • 3
    Welcome to the wonderful world of Unix, which not only consists of Linux with a (mostly) GNU userspace but many different others like OS X, which has a BSD userspace with many subtle differences. This is an ancient problem! – Sven Apr 17 '18 at 21:34
  • You can often make the Mac CLI tools work more closely like the Linux ones you're expecting by replacing them via Homebrew. For example, it drives me nuts that OSX's tail doesn't let you do the -f after the filename, so a quick brew install tail fixes that. – ceejayoz Apr 17 '18 at 21:44
  • @ceejayoz Wow I never thought of that. I use brew for various things but never thought of doing it for these common apps. This is an appropriate solution! If you want to write an answer I'll accept it, thanks this helps a lot!!! – emmdee Apr 17 '18 at 22:14
  • @emmdee The question is locked, but I'm glad that helped. :-) – ceejayoz Apr 17 '18 at 22:15
  • 1
    @MichaelHampton Could 2018 be the Year of the Linux Desktop? Inquiring minds want to know! – ceejayoz Apr 17 '18 at 23:06
2

As you have found, different OS's will have different tools installed. If your primary focus is to develop scripts for something like Debian or CentOS, then I would highly recommend you use that environment to do so. Whether it's in a VM, Cloud hosted VPS, or Docker container is up to you.

In most cases, the behavior is the same between macOS and the various Linux distros, but not always.

Alternatively, you can use tools like brew brew to install the mainline versions of tools, rather than the macOS specific ones. This obviously has other caveats as tools that overlap those on macOS are not linked by default and you would have to override them, but it's doable (it may break things, so be careful). You can also compile them on your own as well.

I'm not aware of a list of difference between Linux and macOS. It also depends on what version of Linux you want to compare it against.

  • 1
    Thanks - I'm going to use brew as suggested. I already use it for other application installs. Sometimes it would take longer to spin up a Vagrant VM than to write the actual bash commands here so I would like to hash out some quick commands on my workstation. Hopefully that's understandable. – emmdee Apr 17 '18 at 22:35
  • 1
    Completely. I use brew to 'force install' many GNU versions of tools because they have the options I need. Also, openssl. Apple stopped using it so they just hardly update it anymore. You might have to manually tweak your PATH variable to make sure /usr/local/bin is reference first, then you might have to manually link certain tools using ln -s – Andrew Apr 17 '18 at 23:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.