[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: date should become tolerant to superfluous and contradicting options
From: |
L A Walsh |
Subject: |
Re: date should become tolerant to superfluous and contradicting options |
Date: |
Thu, 21 Jan 2021 22:53:33 -0800 |
User-agent: |
Thunderbird 2.0.0.24 (Windows/20100228) |
On 2021/01/21 07:15, Adalbert Hanßen wrote:
e.g. to/etc/bash.bashrc. However once this is done, calling
date -Iminutes
yields an error because the date format is stated twice. It would be
possible to unalias the alias by calling
\date -Iminutes
if one wants to let date deliver a shorter and less accurate date and
time, but this would have to be done also in every script using date on
that computer.
Only those script that want to override local aliases.
If the script needs minutes only, then 'command date...' would work
as well, I believe what you have. I don't see the problem.
If all scripts want to ensure they get minutes, then they
probably should either specify the overrides, specify a new alias
for date, or unalias date at the beginning of those scripts that
"care", with changes to the alias lasting the rest of the
script (+ in any children).
Other bash commands solve this problem by letting only the last option
prevail, if there are any contradictions because a given option
contradicts an earlier given one.
There is one more topic which I find no reference where it has been
addressed before: How can a script programmer guarantee that all options
of all commands he wants to use in his script really use the default
options he is thinking about without risking any deviations by aliases?
Would it be an option to start a new bash in order to guarantee that?
Put 'command' before things that are a command or
'function' (I think) before things that are a function,
or, if aliases are on, then 'shopt -u expand_aliases' which
would turn them off for the duration of the script (+children),
though turning off aliases won't prevent functions overriding
commands. Actually, also, just be sure to specify the full
pathname to the executable -- that will also override alias
and function definitions.
What I tend to do (as I use aliases and functions in my shell
scripts and wouldn't want to turn them off), when I remember and
want to make sure needed files are around, is I try to setup
a function at the beginning of my scripts that, at least does
alias cmd=$(type -P cmd), but slightly better to verify scripts
fail early when lacking the utils they need. In one such script,
I use a mkalias func for external "helper" cmnds I'll need. You
could trim this down ... you could have extra params
in a bash hash or map array / command and run with your own
aliases in your script.
mkalias () {
my cmd="${1:?}" # my = alias to declare
my path=$(type -P $cmd)
# die STATUS = err-func to print msg+exit w/status
[[ $path ]] || die ENOENT "$cmd not found in path"
if ((ifc_Debug)); then
printf "alias %s=%s\n" "$cmd" "$path"
fi
alias "$cmd=$path"
}
Cheers!