Update 12-4-16: some ideas how to be "safe" (at the bottom)

Whoops...

And here I thought I wrote all those scripts on my old Mac such that they'd be compatible with any unixish system I might use in the future...

https://unix.stackexchange.com/questions/79355/what-are-the-main-differences-between-bsd-and-gnu-linux-userland

OK, so now I've got some learnin' to do... and not because I was planning on working *on* a script, but because I was planning to *use* a script I'd written long ago... roughly... just to make a friggin' backup for a completely unrelated project, so I could actually *work* on that completely unrelated project.

And, now, I'm a bit fearful maybe a bunch of such scripts I've been using for years may have had unexpected--and more importantly unnoticed--results on my comparatively-new linux systems... (in-use for about two years now).

----------

Today's discovery: "stat" exists on both systems, but have entirely different arguments.

On my Mac, years ago, I wrote a script containing the following:

stat -t "%Y-%m-%d_%H.%M.%S,$timeArg" -f "%S$timeArg" "$file"

This outputs a path/filename-safe string indicating the (selectable) modification/creation/etc. date of a file, in a human-readable format... Yahknow,

2016-12-3_11.14.35,m

('m' indicating that I used the modification-date).

(Since, yahknow, e.g. when copying files, or worse moving files from a broken-down system to a new system, sometimes you forget to do things like preserve creation-times, or worse the different systems don't actually track the various times of the files in the same manner/at all...)

That same 'stat' line runs fine on a linux system, too... but with *ENTIRELY* different results.

Now I've a "time-string" in my backup-filename that looks like:

[input-filename] 3c83fbf27aaf3d25 255 ef53 4096 4096 59030720 4746332 1741968 15007744 13102124

where, again, it should be:

2016-12-3_11.14.35,m

'man stat' on the (now dead) OSX apparently gives the following:

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/stat.1.html

which differs somewhat dramatically from 'man stat' on the linux machine I'm using.

Alright, now I'm fearful... what other utilities have I been making use of that have different arguments? What kind of unnoticed consequences have been percolating over the years...?

------------

And, since I wrote these things already for BSD, apparently, I don't really want to *rewrite* them for linux... so, I suppose, how can I somehow safely detect which system it's running on, and reformat the calls accordingly? (And... am I going to have to worry about them changing the arguments in newer versions?)

OY! That's a LOT of work ahead to make use of tools I've already been using for years.

.........

dammit, all I wanted to do was make a backup of an existing/functional project so I could get to work on improving it!

-----------

Update 12-4-16:

I think the solution is not to use checks of which *system* I'm using, but to use checks of which *utility* I'm calling.

E.G. For 'stat' on linux there's a --version argument...

So, instead of calling 'stat' directly, maybe an intermediate script that calls 'stat' that runs something like:

statVerString="stat (GNU coreutils) 8.23"

blah=`stat --version | grep "$statVerString"`
if [ "$?" != "0" ]
then
   echo "$0 is only tested with: '$statVerString'"
   echo "Verify compatible arguments with 'stat $statArgs'"
   exit 1
fi

string=`stat $statArgs`

if [ "$?" != "0" ]
then
   echo "'stat $statArgs' failed with:"
   echo "$string"
   exit 1
fi

Then, I guess, next time I move my scripts to a new system (hey, what about something like busybox which, as I recall, has *entirely* different arguments for the sake of minimizing things) at least it'll warn me to verify the arguments will work before executing with possibly completely unnoticed consequences.

And, I suppose, it would be wise to include a detailed listing of what each argument does in the comments... since... like last time, I didn't have the option to run 'man stat' on the system it was developed on, since that system bit the dust.

And... doing this as a secondary-script e.g. "callStat.sh" would make it easy to fix one time for all my other scripts which call stat.

My biggest fear is all those scripts using 'cp' 'rm' and 'mv'... if different systems have different arguments, am I 'bouts to essentially 'rm -rf /'?

so... "callRm.sh" I guess is coming up soon.

Oh... and the fun-bit... apparently linux-stat doesn't have the same time-output-format options as bsd-stat... so that probably means I'll have to use something like 'sed' to rearrange the data-output. So now I'll need "callSed.sh" as well? WEEEE!

Note, I used blah=`...` rather than ... >/dev/null... I mean, if one can't rely on utilities of the same name to have the same arguments, how could one possibly rely on all systems to have a /dev/null? (cygwin?)

ah heck... I might as well just never learn a specific machine's arguments, and instead just always copy these scripts over, first-thing, then have 'em remap the arguments I'm comfortable with to those on whichever system I'm using... WEEE! I already have mmv, mcp, and mrm for similar reasons. mstat, mrsync, meverything! WEEE!!!

Maybe if I were more-mobile in the computing-realm, I'd do something like throw all these in a combo memory-stick/password-key. (Isn't that kinda what smart-cards were supposed to do?)