[Dclug] useful bash shell function

Michael Henry lug-user at drmikehenry.com
Sat Oct 9 09:15:46 EDT 2010


On 10/07/2010 06:56 PM, James Ewing Cottrell 3rd wrote:
> It seems like your mark function does 3 things:
>
> mark name                  is roughly equivalent to: name=$PWD
> mark name relative/path    is roughly equivalent to: name=$PWD/
> mark name /absolute/path   is exactly equivalent to: name=/absolute/path
>
> Indeed, the first two are useful[...]

> But the third case is a loser, because you are typing out both
> name and /absolute/path anyway, and the space is just as long
> as the '=', so why are we bothering with "mark "? Just Do The
> Assignment.

Why not allow the third case to work?  Uniformity of interface
is a valuable thing.  Why should you have to use a different
syntax just because the path you're trying to remember happens
to be absolute?  Once a command is familiar, I find it often
flies out of my fingers and is sitting there at the prompt,
waiting for me to figure out what arguments to give it.  Also,
as Bruce pointed out, people are often faster at typing English
instead of punctuation, so a raw count-of-characters does not
tell the whole efficiency story.

Additionally, I can see some possible generalizations to the
marking concept that make the 'variable=/absolute/path' option
distinctly inferior.  As one example, Bruce already mentioned
his persistent marks capability.  I would like to see this
script, though I wouldn't blame Bruce for deciding against
putting it on display to avoid the risk of being told it's a
"loser".  Other possible features might include:

- Marking a group of paths (mark name *.c *.h)
- Keeping track of marks to support:
  - Listing all marks
  - Clearing all marks

Regardless of the merit of the features I've mentioned, having a
common interface for "marks" makes extensions easier.  If you
bypass this interface and do the assignment manually, you no
longer have a "mark", you just have an environment variable.

> So, I won't try and tell you what is Useful To You, but I am
> free to analyze What Is Generally Useful.

It's only my opinion, but I'd like to make a point about tone.
You have a great many valuable ideas to contribute, but they at
times come bundled in an unnecessarily prickly package.  I'd
respectfully like you to consider whether there might not be a
better way to communicate these ideas.  For example, consider
this sequence:

- "the third case is a loser"
- "Just Do The Assignment"
- (much later) "if you add other stuff... the third case might
  be better justified"

Your insight is essentially that it's less typing to assign the
variable directly.  But consider that:

- Less typing isn't the only possible criterion of merit (e.g.,
  it might take less time to type more characters)
- You recognize that the mark feature might be extended to do
  more than just a variable assignment, reversing the winner of
  the "less typing" criterion

The point doesn't seem (to me, anyway) to merit words like
"loser" or to use phrasing like "Just Do The Assignment" (which
can come across in a bossy tone) or "might be better justified"
(are you really unwilling to say it's justified, or at least an
unqualified "better justified", given an extension to the
mark functionality?).

Wouldn't it be preferable to convey the idea more positively (or
at least more neutrally), to make your message more likely to be
well received?

I believe that it's worth going to some extra effort to keep our
community a friendlier place.  I'd like us to be free to
critique ideas and suggest improvements.  I learn a great deal
on this list from reading just such commentary.  But I'd also
like people to be willing to post their ideas in the first
place, without fear of feeling attacked for sharing them.

I offer the above thoughts for your consideration.  I'm hopeful
they come across as the well-intended suggestions for
improvement I've aimed to write.

Respectfully,
Michael Henry



More information about the Dclug mailing list