On 2019/07/12 11:51, Eli Schwartz wrote:
> ... How often do you need to re-type out a production script, that you
> feel a strong desire to optimize for ease of re-typing out rather than
> readability?
>
Never.
> I am mind-boggled that you don't grasp a very very simple programming
> need-to-do: use functions (or aliases if you really feel like it) when
> it lets you group complex tasks that need to be repeated, use variables
> when something can potentially have multiple meanings, and otherwise
> just *say what you mean*.
>
---
I know people who would insist that using variable when something can
have multiple meanings is out right wrong. If you don't know where a
program
is, or want to use the program found at a particular path, using a variable
to call the program is considered bad form by some. So depending on the
program's intended usage, I will sometimes verify I have the programs,
I need, I'll often define aliases to all the programs, like
find_cmds() {
for c in "$@"; do
type -P $c >&/dev/null || {
Pe "$0#$LINENO: Cannot find %s", "$c"
exit 1; }
alias $c=$(type -P $c);
done
}
find_cmds "du find mv rm rpm sed sort tee touch xargs"
This ensures 1) the commands are present, 2) command resolution,
by default, stays constant regardless of changes to the PATH
or current directory, 3) they are the real command and not a
function or alias. I can create exceptions for programs where
I want a function or alias.
> You keep insisting that typedef'ing bash into perl makes it easier for
> you to type.
>
Please stop LYING. You are deliberately making things up. Please
point to where I said that. Otherwise admit you are making things up as
you go along.
> should be optimizing for what
> *actually* matters, which is readability of static production code.
>
Exactly.
I find 'my'/'int'/'array'/'map' more clear than
typeset -i foo=1
typeset -a ara=()
typeset -A amap=()
declare -x foo
When I read code, I don't comprehend whether typeset is a declaration
or adding a flag, and certainly don't comprehend that 'declare -x amap' is
adding an export flag and not actually declaring or initializing anything.
If I am adding a flag, I'll use typeset, otherwise, 'int foo' is far more
comprehensible than typeset -i foo and I'll know, by seeing 'int foo' that
such a statement is where I intend to be initially defining that variable.
> Since you're not constantly typing it, it doesn't matter how many
> keystrokes you're saving, because at the end of the day, you're not
> using a single keystroke regardless of which way you do it.
>
----
If I'm not typing anything, I might be looking at it. And 'int' is
parsed
and comprehended by my brain faster than typeset -i. So I'm saving
brain cycles. People read different things at different rates. If what
they are reading is not words but special syntactical symbols, their
comprehension will be slower since I strongly doubt anyone on earth has
bash-syntax as their native
language and we parse our native language and wordset more efficiently
than special cases.
>
>>> | Various commands can be implemented via separate programs or via
>>> | bash-builtins.
>>>
>>> That's true, but what has that got to do with anything?
>>>
>>> | The bash-builtins are a form of a built-in alias for
>>> | the command in that they are both intended to have a similar function,
>>>
>>> Nonsense.
>>>
>>>
>> ----
>> So you are saying the built in 'test' isn't meant to be POSIX compliant
>> in the same way /bin/test is? For that matter, you are saying they
>> aren't intended to be a POSIX compatible, drop-in replacements for those
>> commands? If that's your position, you are wrong.
>>
>
> You just went completely, wildly offtopic. The only response I can find
> is "pink elephant".
>
---
You claim that my saying the bash-builtins are a type of alias for an
external command that it is intended to have some similar functionality
to, is
"nonsense". To that assertion, I used the fact that many or most bash
builtins that replace external counterparts are also following some
POSIX stated behavior to support my original assertion that they are
intended to be drop-in
replacements for those commands. I.e. using the design requirements for
those bash built-ins that replace external posix components, its easy to see
that your nonsensical response of 'Nonsense' was incorrect. Talking about
different methods of saying the same thing, like aliasing is about as on
topic as anything.
>
>>> The "alias" we
>>>
>> You
>>
>> They are the same.
>>
>
> No they aren't.
>
----
I can also say as I said before, they both have similarities and
differences.
If you can't see similarities you can't generalize.
> Not only is it highly understandable for someone reading that
> conversation to be confused, it's also mendaciously dishonest to use the
> word in that context. I deduce, therefore, that you *wanted* to be
> misunderstood.
>
>
>>> | however, the disk based and builtin functions often have differences,
>>> | but not usually when used within some standard, documented subset.
>>>
>>> They occasionally do, as they come from different sources, and one sometimes
>>> gets extended without the other getting the same treatment. That's
>>> unfortunate but not surprising really. This still has nothing whatever
>>> to do with aliases.
>>>
>>>
>> Doesn't it? Aliases were extended to allow usage other than at the
>> beginning
>> of a phrase, by including a space. They were extended. In a similar
>> way, paragraph formatting functions of some programs extend the
>> formatting to the next line based on a following space. It's not
>> something weird, but something
>> used for the same purpose elsewhere.
>>
>
> That's very nice, but it's also unrelated to the thing which you just
> quoted and purport to be responding to.
>
----
It's related to what you wrote about bash's alias implementation,
earlier
in the same email, where you complain about some bizarreness where a space
at the end of an object allows a continuation of the same type of object.
> Aliases, the command, allow more,
> and it is that more that is the problem, not the "let this name mean
> the same as that name" which is relatively harmless. The effects
> of the (very bizarrely defined) trailing space in the definition are
> one of those bizarre, and dangerous, extra features - it changes
> the interpretation of the following word in a way that simple name
> aliasing (English word sense) never would.
> Typedef'ing bash to be perl is a stupid programming paradigm. It's just
> as stupid as a function.
>
There you go, Lying again.
As often as you go off in left field on things like this, you are hardly in
a position to be lecturing anyone.
