Re: Great SWT Program

In article <bc50398a-5161-47e2-8974-097db29fc8a5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Nov 19, 6:33 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
That's because it's a WYSIWYG word processor. It doesn't HAVE a
logical structure to the document.

Styles don't exist / don't count?

Think "tag soup".

I'm imagining a bowl of liquid, with a bunch of tags such as one
finds attached to clothing .... Not what you meant? but I admit
I don't know a lot about word-processor file formats, assuming that's
what you meant.

[ snip ]

Such as emacs with AucTeX? Sorry, couldn't resist.

I said a *decent* text editor. Besides, I thought you used vi and
therefore would as soon pee on emacs and then light it on fire as ever
attempt to actually use that bloated ancient behemoth...

I guess you missed the posts in which I've said that I thought emacs
and vi users needed to put aside the religious wars of the past, as
well as the ones in which I've said positive things about emacs.

And that stuff about peeing on something one doesn't like -- maybe
it's a guy thing. <shrug>

And yet I seem to remember your saying, a while back in
comp.text.tex, that this way of working was somehow clunky or
bad -- something about not being able to easily have lshort.pdf
visible at the same time as the text being edited. I guess I'm
misremembering.

Eh -- I don't think so. It wouldn't be difficult. Not if you use a
proper, modern window system anyway.

Well, I was curious, and fortunately it wasn't too difficult
to track down the discussion .... I *was* misremembering; the
discussion was about whether it was possible to have lshort.pdf
on the screen at the same time as emacs.

That seems strange. Do you also rarely need to consult the Javadoc on
the lawyerly details of what some library call will do? Perhaps you
just don't code anything very ambitious, or go outside a very small
core set of commands much.

Could be. It could also be that, having worked with these tools
for a couple of decades, the set of things I know how to do with
them is fairly large.

Java hasn't even existed for much more than half that long, so this
claim of yours appears to be rather dubious to me.

What claim is that? I wasn't talking about Java, but about the
command-line tools I've been using for -- well, I'm not sure it's
quite the 20+ years "a couple of decades" implies, but it's close.

Huh. I use "for" loops in my current shell of choice (bash) often
enough to find the syntax straightforward:

for <loop-variable> in <list-of-items>
do
<list of loop-body-commands>
done

where <list-of-items> is typically generated using another command,
or using the shell's filename "globbing" (wildcard expansion).

Sounds like you've found yourself a shell that actually made some
attempt to make this straightforward.

I think this syntax may go back to the Bourne shell (sh).
I currently use bash, a successor with additional capabilities.
Unix shells do tend to provide features useful in scripting,
and to provide them interactively as well.

Then again, the devil is in the
details, and specifying and declaring and using the loop variable is
usually where the cruft becomes apparent IME.

In most of the Unix shells I've used, as best I can remember,
loop variables behave much like other shell variables -- usually
not declared, referenced as $<name>.

There are certainly ways in which the Unix shells I've used are
ugly, mostly in the areas of (1) quoting, and (2) working with
filenames containing spaces. I hear that Perl is better for
serious text processing, but I've never quite made the time to
learn it.

Most of what you want to
do requires launching an external command to massage some data, such
as to parse an integer out of a string, and there's never a handy and
easy to browse command reference listing all of these; instead it's
man this, man that until man <name of some binary from ls /bin> turns
out to describe something that fits the bill. This may have something
to do with the lack of a) a comprehensive how-to-oriented part of the
help; b) an index (other than ls /bin's output!); c) hyperlinks; and
d) better organized, descriptive command names.

All problems for beginners. Not so much for experienced users.

So? It kind of puts a stop to anyone new ever becoming an experienced
user, leading to a small and shrinking population of such, which
prospect I for some reason thought might bother you.

Yes, it does (bother me). It bothers me when people appear
unwilling to invest any time in learning something new to them.
There are many good sources of information on the Unix command-line
environment, some of them available on the Web at no cost.
Traditional Unix online help (man and info pages) is admittedly
not always as helpful as it might be.

It also lacks any
possible excuse in this day and age and given even a fairly lowball
assumption of what hardware capabilities can reasonably be required.
Lower than the system requirements for Windows Vista, or even XP,
that's for sure. A 386 with a few megs of RAM and a VGA card has
sufficient capabilities to do better in the help-usability department,
given that it could run fairly complex graphical things like Windows
3.1 and its applications.

I suppose it might be nice if someone capable of reinventing Unix
online help were willing to invest the time and effort to do so.
Apparently that isn't happening. <shrug>

rear; very easy to do in Java with
String.lastIndexOf('/'), .substring(foo), and the + operator, by
contrast.

Ah, a challenge .... In bash, something like this maybe:

for f in <directory>/*;
do
b=`basename $f`
d=`dirname $f`
n=`echo $b | sed s/^......//`
mv $d/$b $d/$n
done

Five minutes, no perusing of man pages required. Would a beginner
be able to do that? Probably not.

The punch line seems to be "n='echo $b | sed s/^......//'", which
appears to begin with piping something into something else and end
with line noise. The output expected by a naive user therefore being
"NO CARRIER". :P

Quite. My little on-the-fly bit of shell scripting would probably be
unobvious to a naive user. So what? (In case you're curious, the
line in question removes the first six characters from the filename,
previously extracted from the full pathname with "basename". As
I said in another post, knowing a bit about regular expressions is
sometimes useful.)

(I could nitpick about the fact that you misquoted backquotes as
single quotes, but -- nah.)

In any case, that it's no easier to rig this to work in unix than it
is in Windows is unsurprising to me. Is it actually harder? I'm not
sure, although how the documentation would lead a non-expert user to
construct that "sed" argument or even to the notion of using "sed" in
the first place, I don't know. I suspect the non-expert would run
aground on the shoals of shoddy and insufficient documentation,
particularly the lack of a overview documentation with how-to and
commands-by-purpose sort of information. With ls /bin and man foo one
essentially has a white pages directory for a large town's population
but no corresponding yellow pages listing its businesses by category;

Do you know about "apropos" (a.k.a. "man -k")? Admittedly it's not
perfect, but it's sometimes useful in finding out what command would
help with a particular function. (It lists all commands whose
short descriptions match a given string -- e.g., "apropos rename"
to get a list of commands that might have something to do with
renaming things. Yes, "mv" does show up.)

with the meaningless names many of the commands have because they
favored conciseness and something vaguely resembling wit over clarity
of communication, we note that furthermore, some of the town's
businesses have white pages entries that give no hint as to what sort
of business they're in. So to find the town's plumbers requires paging
through the whole white pages looking for plumbing business entries,
and even then you compile a list that may be incomplete. Contrast with
Windows-style help that provides the equivalent of the yellow pages,
so the full list is in there under "P" for "plumbers". :P

[ snip ]

Or it could be that I'm just more apt to remember *how* I said
something than *where* I said it.

If this is true at all,

Again with the implications that I'm lying.

it's very unusual. There's also the matter of
scrolling degrading much more gracefully when the user's knowledge is
imprecise than search does.

Not my experience. Apparently yours. I wonder which is more common.
<shrug>

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

Relevant Pages

  • Re: Allowed return codes from SYSTEM call in ifort/linux.
    ... In that case I think there is a documentation ... "The result is the exit status of the shell command", ... order 8 bits in Fortran, ...
    (comp.lang.fortran)
  • Re: using quotes in exec( ) or escapeshellcmd( )
    ... > Please note that * is a special char in most Unix shells. ... command to run hinges on being able to send "*" to the command shell. ...
    (comp.lang.php)
  • Re: osh ???
    ... > without documentation for the shell. ... well the man command is disabled as well as cp and many others:)))) to ... enble it you must complete the registration e.g. pay 1 dollar or for me 5 ... is there a sort of "shell account provider HowTo" or something? ...
    (comp.unix.shell)
  • Why newbies dont RTFM...
    ... Even though I've used Linux before, I've never had to do any ... BASH BUILTIN COMMANDS ... last command exited within ... unless the shell is not exeâ ...
    (comp.os.linux.misc)
  • Re: Great SWT Program
    ... None of the nasty things that you have said or implied about me are at ... treat the file as input (manually invoking the command interpreter ... script, copy the line into that within the editor, exit, and invoke ... the shell script. ...
    (comp.lang.java.programmer)