on Questionable Features

If you have set up a CDPATH, then any command like:

cd someSlashless place

is subject to running through your CDPATH. This means having to embed the test in any function which may use cd, or pushd, or worse yet, visit every command to update the code with directory arguments to preface each with the needed dot-slash, e.g.

cd ./someSlashless place

So, for the moment (4/12/14), I'm disabling the feature from my profile.

This started with an idea on Mon, July 14, '14, raised in discussions on ittoolbox. And it crystalized after poking thru the date_vars function in my standardlib, which I must have pulled off the web. In any case, it's simply this (logged: 20140714 Mon Jul 14 13:49:09 2014)

>/If you're going to use a name, make it a function, not a constant (or VARIABLE name)./

That, in a nutshell is the variable problem. Why would you want to use a variable when a function has all the capability and none of the bad side-effects. I remember my father, when my brother and I were selling newspaper subscriptions in the '50s:

>/Tell them "You can't cut it out of television"/

implying the newspaper gave you the opportunity to clip and save an item of interest, something that stimulated your imagination.

So it is with shell functions. The difference now is simple:

>/Don't clip it, rather Link it/

Or, in the case of a function vs variable.

>/Fetch the current value/

The idea came to me in evaluating this date_vars function:

date_vars () 
{ 
    eval $(date "$@" "+DATE=%Y-%m-%d
                      YEAR=%Y
                      MONTH=%m
                      DAY=%d
                      TIME=%H:%M:%S
                      HOUR=%H
                      MINUTE=%M
                      SECOND=%S
                      datestamp=%Y-%m-%d_%H.%M.%S
                      DayOfWeek=%a
                      DayOfYear=%j
                      DayNum=%w
                      MonthAbbrev=%b");
    _MONTH=${MONTH#0};
    _DAY=${DAY#0};
    _HOUR=${HOUR#0};
    _MINUTE=${MINUTE#0};
    _SECOND=${SECOND#0};
    TODAY=$DATE;
    export DATE YEAR MONTH DAY TODAY TIME HOUR MINUTE SECOND;
    export datestamp MonthAbbrev DayOfWeek DayNum
}

What do you see here? One fourth of the variables are out-of-date as soon as you try to use them. One third in the next second, 40% within the minute half, and half within an hour. Now, most programs aren't going to hang out for an hour before consuming their info, but consider you've gone to some work to create 13 environment variables and consume a bunch of names to do so. Why not rather, instead of a variable, used as ${DATE} a function, invoked as $(DATE). Here is its definition:

DATE () { date +%Y-%m-%d; }

The behavior of this function is identical to that of the variable. It turns out, functions give you options not enjoyed by variables: options. Yes, options. All by itself, the function as given, and used within the $( ... ) syntax behave identically as the Environment variable of the same name, yet offers the possibility of added functionality, with no loss of utility in all the variable-only situations.

Modify the DATE function's definition only slightly to this: mar

DATE () { date "+%Y-%m-%d $*"; }

and it becomes a logging function, used as I have in the ppt functions:

$ DATE this is a logging message ]] ${LOGFILE}

And in passing, there is a slight side-effect which would need to be addressed in the the most most robust implementations. Notice, at the end of the date format there is a blank space. Depending on usage, this may be a problem, for example in creating file names. The extra space needs to be eliminated. Within the syntax of the shell positional expansion, there is a way to supply the space only when needed. But that's too much information (TMI) at this point.

Add "variables" to the list of questionable shell features.