Re: Great SWT Program

In article <3eea3933-e65b-47ac-8ef8-2f20a9a8abb0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Nov 19, 7:21 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Four keypresses rather than two. Doesn't seem like "much more work"
to me. As for switching into command mode -- normally I *am* in
command mode.

During complex edits you'd have to flip back and forth a lot, if the
edits involved inserting new text as well as rearranging pre-existing
text. It wouldn't matter which one you were "normally" in, although
not being "normally" in the mode where it actually accepts new text
seems rather strange.

To you, I suppose it does: I seem to remember that you've said
that mostly when you're editing a file you're entering new text,
whereas I'm more apt to be making changes to existing text.

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?

So once again you know better than I do how this application
actually works .... (":" indicates that what comes next is an
'ex' command. Some of those commands do involve external files
and/or programs. Some of them don't.)

In that example "what comes next" was absolutely nothing; it was just
"n:" without any more input besides the enter keypress that submits
the command.

No, it was ":n", not "n:". (And yes, in the copy of my post delivered
to me by my news server, it was ":n". I can't be bothered to confirm
that it's the same in Google's copy; a difference seems unlikely.)

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.

Whereas trying to do it from a GUI always strikes me as unbelievably
tedious. But apparently I've been unaware of some of the capabilities
of graphical file browsers and selection dialogs. I don't suppose
you also don't know everything .... No, no, of course not.

There may be a trick or two I haven't picked up yet,

I'm inclined to think that's an accurate description of your
knowledge of your platform. As a description of your knowledge
of my platform -- not so much.

but I know the
ropes well enough to work efficiently (and to know when I need to
automate). Don't forget that having graphical tools does not render me
mysteriously incapable of using a command prompt; on rare occasions
the command prompt sees use, for instance for mass renames of
extension type. Batch files too, when something is big enough and
"regular" enough to make it possible to exploit automation and,
moreover, worthwhile to do so.

And when you do this, you have to consult documentation, and it
takes a while ....

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

Not superhuman, but experienced with my tools of choice.

No normal human being can keep all of the hairy syntax of those things
in their head 24/7 and not need to refer to anything. Can you program
a mid-sized Java program without ever referring to any of Sun's
Javadoc (or the tutorial, or Thinking in Java, or any other similar
information source)? Quick quiz: which comes first in the argument
list for System.arraycopy, the source or the destination array?

I have no idea. I don't claim extensive knowledge of the Java
API, however. Nor do I claim perfect and comprehensive knowledge
of Unix command-line tools. I do, however, know enough about them
to do many things (including use of simple regular expressions
and flow-of-control constructs -- is that what you mean by
"scripting"?) without consulting documentation.

Which in practice doesn't seem to happen very often, and if it
does one can use "xargs".

That again! What *is* it, and how is one supposed to discover that it
exists?

What is it:

http://en.wikipedia.org/wiki/Xargs

How is one supposed to discover ..... <shrug> Maybe by reading
a good tutorial on Unix CLI tools?

So before doing anything that might be difficult or inconvenient
to undo, I'll first preview it in some way (e.g., echoing the
list of selected filenames rather than applying some command
to them -- and no, that doesn't mean I have to type the whole
selection command(s) again, since my shell keeps a history of
previously-typed commands).

Still awkward compared to using visual tools. Visual tools also let
you use a search to narrow things down, and then cherry pick a subset
of the search results to do something with, in case some of the
selection criteria are AI-complete or at least ridiculously hairy.
Your tools don't let you do that save by the tedium of retyping the
names you'll be acting on, unless perhaps you can save the results to
a file, edit out some of them, and then feed the reduced list to some
other process --

I do just that on occasion.

all of this STILL more tedious and painful than using
a GUI, and all you can see when doing the manual-weeding stage is a
list of file names without any other information about the files.
Whereas I can examine their modification dates and other filesystem
metadata, preview image files, sort the search results by modification
time or other criteria, including with images by size in pixels, with
audio by length or bitrate, etc.; you could only do that by using a
primitive means of task switching and typing names from the list to
launch the files or get details about them with ls -various-hairy-
options thepath/thefilename.ext or similarly.

A lot of what you describe strikes me as relatively straightforward
to do with my tools of choice, though I strongly suspect that what
I regard as relatively straightforward here -- well, you might not
agree.

I *am* curious about how you sort search results by image size in
pixels, or audio by bitrate; I don't remember seeing that kind
of information displayed in graphical file browsers, but then I
don't use them much,

All of which also requires poking around in man pages to find which
exact -various-hairy-options to use here and there, OR a huge amount
of memorized information, far more than a Windows user needs to do the
same job equally fast or faster.

"Sunk cost" may be the phrase that applies here, at least in my case.
<shrug>

If I want to be sure I see the output, I'll either redirect it to
a file, or pipe it into a pager such as "less". For "rm", I'm apt
to do "rm -v" (for "verbose"), so I do get a list of what's being
deleted.

And if something's in that list that shouldn't be it's too late so
what good does it do?

Confirmation that things are working as intended. If I have any
doubts about the proposed deletions being what I intend, I'll either
use "rm -i" or do a dry run of the delete command first.

Of course, Windows gives you plenty of time to
recover a mistakenly-deleted file before it's *really* gone, via the
Recycle Bin. (Except if it's deleted with a "del", e.g. in a batch
file. A good reason not to make scripts actually delete things on
Windows, but rather make such a script move them to someplace where
you then select what shows up there and hit del. This gives you the
possibility of recovery if you later decide you should have kept one
of them.)

Recycle Bin versus "delete it and it's gone" -- yeah, that's a
separate argument. I can see benefits to the recycle-bin idea,
though to me it seems clutter-y .... <shrug>

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • coreutils-7.3 released [stable]
    ... been a few other interesting fixes and improvements. ... run a command like this: ... sort -m no longer segfaults when its output file is also an input file. ... destination file system with a fundamental block size of 4KiB or greater. ...
    (gnu.announce)
  • Re: FC1 Install _appeared_ to work, BUT...
    ... what sort of messages do make it to screen? ... I used to run RHL7.3, dual booting, on a Sony Vaio laptop. ... command prompt only safe-mode in windows but without the GUI). ...
    (Fedora)
  • Re: [OT] Compiler warning level
    ... > have command lines" when they enter the course. ... I started -- well, OK, unless you count the front panel switches and the ... lights on the panel could be called a GUI, they were sort of graphical ... I tend to write the makefile before typing in the start of the ...
    (comp.lang.c)
  • Re: getline caveats misuse howto
    ... populates the ERRNO builtin variable if getline fails. ... down the two-way pipe to the UNIX "sort" command. ... gawk terminates the coprocess and exits. ...
    (comp.lang.awk)
  • Re: BROWSE: order by column
    ... oHdr is now a reference to the header object ... descending sort. ... If you have a lot of columns that would be a lot of command ... Just add the code to change the sort order to a new ...
    (microsoft.public.fox.programmer.exchange)