Re: Great SWT Program

On Dec 6, 10:08 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
[implied vicious insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

What are you babbling about? Regardless, even if you made the shell
treat the file as input (manually invoking the command interpreter
with redirected input? How hackish, and with the input source having
to be blind-specified, crufty too)

I suppose it /would/ be crufty

Yes, it would be. And hackish. Didn't I say that originally?

it would treat the ENTIRE file as
input rather than the one specific line of interest. If you're going
to do something like that you may as well just make a proper shell
script, copy the line into that within the editor, exit, and invoke
the shell script.

You can certainly do that if you prefer. It still seems a bit
over-elaborate and bothersome but I suppose it would get the job done.q

It's also the bare minimum. I mean, if I have a file with "foobar" on
line one and some shell command on line two, I can make the shell
invoke the command in one of three ways:

* Manually copy the shell command to a command prompt and hit enter.
Tedious but works
* Invoke a command interpreter instance with input redirected from the
file. Crufty and makes it execute "foobar" with God knows what
results, probably just an error message followed by it running the
desired shell command.
* Copy the shell command in the editor, new file, type #!/bin/sh,
enter, paste, save as foo.sh, exit, ./foo.sh and the command executes.
Cruftier, tedious, and works without as many side effects.

What I unfortunately cannot do and would be nicest is: Copy the shell
command in the editor, alt-tab to a command prompt, paste, and hit
enter. I can do this on Windoze, with only the paste being a bit
crufty as a menu has to be fiddled with instead of just hitting C-v. I
don't see this working in console-mode unix though, because the
editor's clipboard is then completely internal to the editor. Likewise
I couldn't copy a line saying "dir" in MS-DOS Edit with C-c, exit
Edit, hit C-v enter, and get a directory listing.

It isn't, because there's a system-wide clipboard. It's YOUR tools
that each have their own separate clipboard (if they have one at all)
so you can't copy-paste between them, remember?

Well, /I/ certainly can copy-paste between them

Of course you couldn't, because there IS NO SYSTEM-WIDE CLIPBOARD IN
UNIX outside of X, just as there is none in MS-DOS though there's one
in Windows.

Profanity implies insecurity

No, it implies FRUSTRATION, because you are such a COMPLETE IDIOT and
I have to say everything SIXTY THOUSAND FUCKING TIMES and you STILL
DON'T GET IT! Grrr!

[calls me a liar]

#82, and none of the nasty things that you have said or implied about
me are at all true.

And, of course, in the mean time, I have that tool at my fingertips
should I ever want it.

You really are quite the fan of creeping featurism, arencha?

I'm not. Stop putting words in my mouth. It makes you a liar. You
didn't seem to like it the last time I called you a liar, so you
should really stop with the deceptive behavior. Frankly, you're
getting to be almost as bad as emacs for that.

It really is cruel to remind you of your own rules, but you appear to
have lost an argument again.

I guess I need to remind you once again that the rule was that A NON-
RESPONSIVE REPLY is conceding a particular point. So:

Opp: A is true.
You: A is false (or you're a liar or whatever)

means A is false and

Opp: A is true.
You: I hate you.

means A is true and you hate your opponent.

The difference is that in the latter case you didn't dispute the claim
that A was true.

Same applies to me of course.

What happened last was:

You: Twisted said foobar.
Me: You're a liar and putting words in my mouth.

Implication: Twisted did not say foobar and you're a liar.

Nowhere did I concede to having said foobar, even by omission.

No. There are no command line switches involved in a straight-forward
conversion.

So it just guesses what to convert to? It can read the source file to
detect its type with a fair amount of certainty, but the only
information it may have about the destination type is the file name
extension you want to give the destination file. Certainly, if you
specified only the source file and wanted a destination file with the
same name except for the appropriately-changed extension you'd have to
specify the destination type somehow. Guessing types based solely on
file extension is unsafe anyway.

[some content-free bull*** snipped]

They a) display the functionality clearly and cleanly

And how, pray tell, would an icon "clearly and cleanly" symbolize a
conversion from GIF to PDF as opposed to a conversion from TIFF to
JPG?

Who said anything about the icon doing this? The text caption below or
to the right of the icon (depending on view settings) is what would
communicate this information.

and b) actually
provide direct access to the functionality on the spot, in much the
way the long and disorganized man pages on your side of the fence
don't.

man pages aren't used to access Unix utilities in the first place.

Exactly. You have to go to one place and use one crufty and primitive
"browser" to discover functionality and how to invoke it, and memorize
some stuff, then go someplace else and type what you memorized to
actually invoke that functionality, instead of being able to discover
functionality and immediately invoke it right then and there in the
same place.

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

It's missing, which means it will do who knows what default
conversion. Unless the default destination type happens to be pdf,
you'll likely end up with a file named "blah.pdf" but actually in jpeg
format or something like that. Unless, of course, you just get an
error message.

[implied insult deleted; mental health again? Not very creative, are
you?]

None of the nasty things that you have said or implied about me are at
all true.

[rude and condescending BS snipped] Nevertheless, the number of key
presses in the above command could be as little as 10-14

as compared to two clicks or thereabouts and zero keyboard typing.

Yay for the vaunted efficiency of text-mode unix tools.

It's amazing. Especially if you're using a laptop (or worse, a PDA) in
seat 37B with other passengers hogging both of the armrests beside you
and the one in front of you reclining an impolitely large amount, kind
of limiting your elbow room. During turbulence. Seatbelt-sign-keeps-
going-on-and-off-again level turbulence. Truly amazing.

depending on your system. One
typical example would be
conv<tab><tab><tab><backspace><backspace><backspace>pdf<enter>

Baloney. First, there's no filename fragments in here at all. This
either complains that there's no command "convepdf" or converts some
random file, depending on whether the loose tabs do nothing or pick an
arbitrary file in the cwd for you, and assuming that the first tab
completes "convert" and inserts a space for you.

Second, that minimalist, random-file-converting example is already 14
characters, so forget any of the lower numbers in the range "10-14".

Add realistic initial filename fragments and it's more like 20-24, if
a fairly short prefix (three to five characters) is enough to uniquely
specify the file and counting having to type this prefix twice.

Then there's the elbow-room factor, the PDA-with-only-a-pointing-
device factor, and the latency factor; you don't dare go on blindly
after hitting tab to autocomplete since you need to be sure it picked
what you expected before going on, so on a low-latency connection it's
wait or risk having actually invoked a command named "conv-format-all-
fixed-disks". :) Oh, and did I mention the ease of fucking this up?
For a short time the input line is very dangerous because it is a
command that will overwrite one of your preexisting files. If enter
manages to get pressed while it's in this state, either accidentally
or because you forget to edit the second parameter ... boom!

To a touch typist, this is hardly noticable.

But twice that number (a far more realistic number of keystrokes) is
certainly noticeable.

They don't, but they also don't necessitate it by making the user go
fishing through long text files in a no-frills (hell, almost-no-user-
interface!) pager to find one little bit of crucial information in the
form of a cryptic string to memorize and then type exactly as part of
a longer command line at the prompt they return to by exiting said
pager.

You appear to be imagining how it would be to use your own mental
design of a text editor again. [remainder of insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

You are obviously extremely confused, and not following the discussion
very well at all. Unfortunately, your tiny IQ is probably beyond the
ability of present-day neuroscience to fix.

Thing is, I wasn't imagining any text editor; I was describing the
actual experience of using things like "man" and "more" to view long,
verbose documents listing various command line switches and other
usage information for stuff. Nothing there being how-to-do-a-
particular-task oriented nor sporting anything resembling a real user
interface.

Text editors, schmext editors. We can worry about those once we've
addressed the abysmal state of documentation and of documentation-
browsing on your system of choice as configured for old-skool style
use.

Amazingly, shells /do/ know how to auto-complete file names. [hyperbole
snipped]

But they also only know that the first thing on the command line is a
file name.

No.

Yes. The shell cannot be preprogrammed to know of every present shell
command, let alone every future one. I could write an "asswipe" binary
tomorrow whose first argument is a filename. Or write an "asswipe"
binary tomorrow whose first argument is always a switch, or may be
either, or is something completely different such as a device or a
display resolution or a random integer. If I type "asswipe 10<tab>"
what should the shell do? Complete it to "10_ways_to_crash_X.txt", the
only filename starting with "10" in the current directory? "1024x768",
the only plausible display resolution that begins with "10"? Bleep
because it could be any old integer? It depends on what "asswipe"
does. Which the shell doesn't know, because "asswipe" hasn't been
written yet.

Worse, what if there are already TWO "asswipe" commands out there --
same name, different authors, different jobs, different usage?

The shell could, in theory, delegate argument autocompletion to the
command, but I don't know of any OS whose shell will or even can do
so, and it certainly would break POSIX to do so since the command
binary would have to be launched before the command was fully entered
and "enter" hit, taking over input processing as soon as the command
name and a space were entered. And smoothly exit and hand over
handling of input editing back to the shell if the user backspaced
that space away. Making something like that actually work would be
nontrivial, with a million possible gotchas.

Everything after that is just a random jumble of characters
that it's up to the invoked binary to interpret.

No.

Yes. It can be a switch, a number, a filename, or just about any other
conceivable data expressed as an ascii string, or any number of such
things in sequence, albeit almost certainly tokenized by simple
whitespace separation. There are conventions, but they're not absolute
and inviolable laws. There's no way the shell can assume that any
particular part is a filename or any other particular thing without
guessing wrong very, very often. Even if it "looks like" a filename or
a path it may be a URL fragment for network use, for instance, or some
internal addressing of some sort (similar to HKEY_FOOBAR/BAZ/Quux/
(Default) and the like in the Windoze registry) in some hierarchical
application-specific database or other store.

Not can the
shell, because it has insufficient information to know what sort of
input the binary is expecting.

It will auto-complete file and path names.

But it doesn't even know what tokens ARE file or path names, aside
from that the first token on the line necessarily is one.

Balderdash! Unless maybe you have Braille key-caps on your keyboard or
something.

[cryptic non-response deleted]

It remains a problem when you keep using the mouse and therefore
repeatedly need to find your way back to the keyboard.

Not when each use of the mouse saves you 25+ keystrokes it doesn't.

Even if 25 keystrokes were necessary, a touch typist takes a
negligible amount of time to type them.

And a proficient mouse user takes an even smaller amount of time to
clickety-click.

"More capability is better" is the path to creeping featurism. That's
how you end up bloating apps up with useless features such as a tool
for calculating in a certain Mesoamerican timekeeping system. :P

[attacks my mental health again]

None of the nasty things that you have said or implied about me are at
all true.

Beware invisimodes, inconsistency, Mayan date calculations ... the
dark side are they.
.