Re: Great SWT Program

On Nov 16, 6:20 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
I've written myself a little shell script that makes it easy to
start up vim on only the files that contain specified text

That has one obvious problem: you can't launch multiple interactive
apps simultaneously in the same terminal.

Actually maybe you can, with appropriate use of the "screen" utility.
But that's one I have yet to master.

That script still won't be able to launch the vi instances in separate
terminals though. They'd all open in whichever terminal the script
itself was run in, whether that was one of the branches of a screen
session or not.

I sure would, if vi(m) were incapable of editing more than one file.
Fortunately, that's not the case. (I seem to remember that even
"real" vi had this capability, but I might be misremembering.)

Too bad it won't let you flip between them in a natural and convenient
way, or even in a way consistent with other tools you use, unlike
multiple document windows open in a proper window interface.

Of course you'd then be stuck with primitive,
awkward, and annoying pre-GUI methods of switching among open
documents...

Yeah. ":n<enter>" to go to the next file.

How primitive. Much more work than alt-tab, especially when you
consider the need to also switch into and back out of command mode.

And didn't a : indicate a command to operate on an external file, or
to launch via the shell, or something of the sort, earlier?

Uh-huh. I'd have to know more about how you did the mass selection
(all the files in a folder, or did they have some common trait
that made it easy to select en masse) and about what you mean by
"didn't have the trait in question" to propose a Unix-y solution.

I'm betting that there is none or else the only ones involve a lot of
typing and even debugging of some sort. Trying to do any sort of
complex mass file manipulation from a command line has always put me
in mind of fumbling around and bumping into furniture in the dark.

But unless there's something automation-resistant about which
files are to be selected, I'm pretty sure I could come up with
something no more complicated than what you just mentioned,
and without consulting any reference materials.

Bull -- if it involved any kind of regexp or scripting you'd need to
refer to the reference manual for the syntax and semantics of the
language involved, unless you're superhuman in some way. :P

A Unix-y approach would be to use the output of the script (if
it's a list of files) as input/argument to another program.

More awkwardness. First the other program needs to be commandline-
oriented, accept a list of files as a parameter, etc.; second the list
needs to not hit any length limits; third this will all happen
frighteningly blind, so if the list is obviously incorrect the first
thing you see is "deleting UselessFile1 ... deleting UselessFile2 ...
deleting UselessFile3 ... deleting ImportantFileIWantToKeep.txt ...
^C" Too late for ImportantFileIWantToKeep.txt of course, but at least
you stopped it before it deleted anything else it shouldn't have, hmm?
That may require sub-millisecond reflexes with a modern machine mind
you. Most likely it's either already done or at least deleted dozens
more files by the time you hit ctrl-C. If you even *see* the
incorrectly-included file's name flash by at warp speed. If the thing
even produces feedback at all. What if the prompt just goes away for a
few seconds while the drive light buzzes, then a new prompt appears?

OK, it running amok deleting things IS a worst-case scenario, but
those are important to consider when designing a system to be robust
and to provide the best possible opportunities for error recovery to
its operators. Making trucking the list to the process that deletes
stuff or whatever a manual step provides an opportunity for an
operator to notice problems before they become irreversible ones.
Direct viewing of the file contents, as with my 80-notepads example,
ensures the operator knows exactly what'll get deleted, so if the
number of files isn't outrageously large I'll tend to prefer such an
approach to anything that involves a greater degree of blindness.
Errors creep in the less double-checking, noticing stuff, etc.
opportunities the user has. This is also one objection to invisible
selections and other invisible-but-important state in editors etc.;
being able to see what you're doing enhances the ability to detect and
catch errors before they waste as much of your time, and when the
corrective steps to take are easier and fewer. In the most extreme
case, you occasionally manage to avoid catastrophic data loss that
would otherwise have happened. Violations of the principle of least
astonishment also increase the risk of catastrophic error. Typed text
appearing elsewhere than the insertion point, cut deleting more than
the visibly highlighted portion of the text, etc. come to mind as
examples of such violations that have come up in conversation here
recently.
.

Relevant Pages

  • Re: What is this component?
    ... vibration sensor of some sort, to save battery, ie when it hasn't ... moved for a certain amount of time the unit will shut off. ... touches off 2 different terminals. ...
    (sci.electronics.components)
  • Re: OT: Battery Acid
    ... For some reason vinegar comes to mind... ... Clean it off with a steel wool pad, ... acid radio battery terminals. ...
    (comp.sys.acorn.misc)
  • Re: Chip & Pin Fraud
    ... industry that the terminals were to be tamper-proof/tamper-evident. ... that in mind, most of us moved on to other, more likely threat scenarios. ... To get the PIN all it needs is an appropriately positioned camera in most cases, however hacking the terminal isn't going to be that hard - a simple duplicate keypad mechanically coupled to the real one, with extra pressure sensors, would likely not be detected and wouldn't even break the seal on the terminal. ...
    (uk.finance)
  • Re: message to self
    ... The sort that make your tongue tingle if you lick the terminals. ...
    (uk.people.support.depression)
  • Re: cooked electrickery - electrosheddi to the bridge, please.
    ... bearing in mind that the 2 terminals in the upper part of ... But keep in mind ...
    (uk.rec.sheds)