[Info-vax] Long uptime cut short by Hurricane Sandy
AEF
spamsink2001 at yahoo.com
Fri Feb 1 22:58:38 EST 2013
On Jan 31, 10:22 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> In article <6a28aa9f-b23c-4aec-a419-18932d045... at n2g2000yqg.googlegroups.com>,
> AEF <spamsink2... at yahoo.com> writes:
>
> > On Jan 31, 5:03 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> >> In article <keenff$te... at iltempo.update.uu.se>,
> >> Johnny Billquist <b... at softjar.se> writes:
>
> >> > On 2013-01-31 20:22, Bill Gunshannon wrote:
> >> >> In article <keeb7i$e1... at dont-email.me>,
> >> >> Stephen Hoffman <seaoh... at hoffmanlabs.invalid> writes:
> >> >>> On 2013-01-31 17:38:45 +0000, VAXman- @SendSpamHere.ORG said:
>
> >> >>>> $ filename =
> >> >>>> filenameprefix+"_"+F$fao("!19AS",F$cvtime(,"COMPARISON"))-"-"-"-"-"
> >> >>>> "-":"-":"+".dmp"
>
> >> >>> Yeah. Or add the prefix and the underscore into the f$fao, as that
> >> >>> avoids clobbering caracters in the prefix.
>
> >> >> And tell me how the above is not cryptic? Just what is the difference
> >> >> between the first dash and the second? Or the third? And would anyone
> >> >> normal determine that? :-)
>
> >> > Maybe it would be more obvious with some appropriately placed spaces...
>
> >> > $ filename = filenameprefix + "_" +
> >> > F$fao("!19AS",F$cvtime(,"COMPARISON")) - "-" - "-" - "-" - ":" - ":" +
> >> > ".dmp"
>
> >> Nope. Still looks as clear as mud. Now, I am certain that experienced
> > C'mon, it _is_ an improvement.
>
> For someone who already knows what it means, maybe.
>
> > Not enough, or not enough for you,
> > perhaps, but an improvement nonetheless. Is it really that hard to
> > guess that the isolated dashes are minus signs?
>
> In something with only alpha characters and no numbers what would make me
> think they are minus signs as opposed to dashes? I have seen the plus
Have you ever written a formula in Fortran?
A = B - C
The dash above is a minus sign. Now don't tell me that this is a
surprise to you! Even without Fortran, dashes are used to represent
minus signs in mathematical formulas.
> sign used to do concatenation of strings in other languages, but I have
> never before seen a minus sign used to signify removing a character.
Really? This is the first time you've seen a DCL command like this?
And I have never seen % characters converting letters to time
components. I have seen them screw up Postscript printouts when
doubled, as in certain VMS outputs where you get like 11 of them in a
row. PITA!
>
> > Admittedly it's hard
> > for me to judge, being I already know the answer.
>
> My point exactly. This makes perfect sense to you. Unix scripts make
> perfect sense to me (and other Unix people). One mans clarity is another
> mans cryptic.
Well, that cuts both ways. Then it means you can't say anything about
anything be cryptic, either.
>
> >> VMS DCL Programmers understand that completely buit tell me which one,
> >> the Unix example Hoff posted or this one is more likely to be deciphered
> >> by someone who doesn't know either OS. The Unix example has symbols
> >> that can at least be intuitively determined (a Y probovly means Year and
> >> an H Hour and their location removes the ambiguiyty ot the M and m.)
> > Well, to keep the riff raff out! If you haven't learned the OS well
> > enough to read this type of code, maybe you shouldn't be messing with
> > it in the first place! (^_^)
>
> That is funnier to me than you can even imagine. It's the same attitude
> I used to hear spouted about why Unix was so "cryptic".
Some cliches always work. Like watching a character in a movie put the
car in Reverse, look back, step on the gas, and we, the audience, get
to laugh out loud watching the car lurch forward!
> >> > Ie, remove three dashes and two colons, and then add something at the
> >> > end. (Ignoring what's going on at the beginning.)
>
> >> Yeah, all those dashes and double quotes lined up like that, that's
> >> real intuitve.
>
> >> > As the for F$FAO and F$CVTIME functions, you obviously need to read the
> >> > documentation to know exactly what they produce.
>
> >> And if people actually took the time to read Unix documentation they
> >> would find out it's not at all cryptic. There is a logic to all of
> >> it (well, except maybe awk, the name, not the function.)
> > Well, if it's not cryptic, why do you have to read the manual?
>
> Everything is cryptic until you learn it. Or were you born with infinite
> knowledge already present in your brain? Ever been to an Arab country?
Well, I seem to remember you bragging about your daughter at the age
of 6 or 8 taking to a Unix prompt as if she were born with Unix
commands in her mind.
I have never been to an Arab country.
> Can you read Arabic? Now there is cryptic. But for some reason the
> Arabs didn't seem to think so.
No, but I can read Arabic numerals. And so can almost any literate
person anywhere in the world.
>
> > If you
> > read the manual about DCL symbol manipulations, VAXMAN's command is
> > not cryptic, either -- well, if you add clarifying spaces, anyway.
>
> If I had spent as much time poring over VMS manuals as I have over Unix
> manuals I am sure it would be perfectly clear. But, that's the point.
> Neither is inherently "cryptic". They just appear that way to the un-
> initiated.
>
> > Reading Unix documentation is no fun. The man pages are formatted with
> > proportional spacing of fixed-width characters so as to make the right
> > margin straight. That makes it ugly and hard to read.
>
> Once again, matter of opinion. I don;t even notice things like margins
> when I read as they add nothing to the meaning of the text and I am not
> a professor grading them on their semantics. I will admit that I used
> to do a lot of writting where I tried to keep the left and right wargins
> as straight as possible. :-)
I noticed how hard it was to read, first. I was wondering for quite a
while why the man pages were so difficult on the eyes. Now I know. And
so did the business world learn back in the early days of word
processing.
> > The business
> > world ruled it out long ago. Ragged edge is the way to go with fixed-
> > width font.
>
> OK. And I am rather certain you could find a book on Unix that met
> your marginal expectations (pun intended!! :-)
LOL, a little.
>
> Just out of curiosity, I just looked at a couple of manpages on a
> FreeBSD system and none of them exhibited this straight-right-margin
> of which you speak.
Hey, sometimes good things happen.
>
> > Some man pages are loaded with incomprehensible stuff.
>
> Like?
I'll give some examples later. I rarely use them. Instead I usually
struggle searching the Web, hoping for some clear words of
enlightenment, and for the right variant.
Actually, the one I posted is a pretty good example. All I wanted to
do is see what cool features the 'cd' command might have. Instead I
get a list of all sorts of things of no interest.
>
> > And it's
> > sometimes hard just to find the one thing you need. It's fine as a
> > reference if you already know the command and just need a quick
> > reminder.
>
> Never heard of "man -k" or the apropos command?
I've never seen a system where that was set up. I guess it's too
difficult for the manufacturer to do, so they leave it as an exercise
for the reader. Maybe they should force me to have to set up those %
characters to translate letters to time components, too.
> > And things vary from brand to brand.
> > Many commands don't even have man pages!
> > Here's what 'man cd' produces on the Mac:
> > BUILTIN(1) BSD General Commands Manual
> > BUILTIN(1)
> > NAME
> > builtin, !, %, ., :, @, {, }, alias, alloc, bg, bind, bindkey,
> > break,
> > breaksw, builtins, case, cd, chdir, command, complete, continue,
> > default,
> > dirs, do, done, echo, echotc, elif, else, end, endif, endsw,
> > esac, eval,
> > exec, exit, export, false, fc, fg, filetest, fi, for, foreach,
> > getopts,
> > glob, goto, hash, hashstat, history, hup, if, jobid, jobs, kill,
> > limit,
> > local, log, login, logout, ls-F, nice, nohup, notify, onintr,
> > popd,
> > printenv, pushd, pwd, read, readonly, rehash, repeat, return,
> > sched, set,
> > setenv, settc, setty, setvar, shift, source, stop, suspend,
> > switch,
> > telltc, test, then, time, times, trap, true, type, ulimit, umask,
> > unalias, uncomplete, unhash, unlimit, unset, unsetenv, until,
> > wait,
> > where, which, while -- shell built-in commands
> > SYNOPSIS
> > builtin [-options] [args ...]
> > DESCRIPTION
> > Shell builtin commands are commands that can be executed within
> > the run-
> > ning shell's process. Note that, in the case of csh(1) builtin
> > commands,
> > the command is executed in a subshell if it occurs as any
> > component of a
> > pipeline except the last.
> > followed by more useless stuff, at least for the cd command.
>
> That's because you seem to have been expecting "cd" to be a command
> all by itself like "ls" or "man" and it is in fact merely a builtin
> of the shell. If you actually read the page it would have explained
> that cd only exists as a builtin and that there is no equivalent
> external command. That would logically tell you :-) that you need
> to look at the man page for your particular shell to see what the
> syntax and options for the builtins are. There certainly isn't going
> to be a man page for something that is not a Unix command.
That's a lot of trouble to go to for such a command, excuse me, built-
in. And nowhere does this man page tell you the name of the shell!
Talk about cryptic!!! (The shell that produces this command is bash,
not csh.)
DESCRIPTION
Shell builtin commands are commands that can be executed within
the run-
ning shell's process. Note that, in the case of csh(1) builtin
com-
mands, the command is executed in a subshell if it occurs as any
compo-
nent of a pipeline except the last.
If a command specified to the shell contains a slash ``/'', the
shell
will not execute a builtin command, even if the last component of
the
specified command matches the name of a builtin command. Thus,
while
specifying ``echo'' causes a builtin command to be executed under
shells
that support the echo builtin command, specifying ``/bin/echo''
or
``./echo'' does not.
While some builtin commands may exist in more than one shell,
their
operation may be different under each shell which supports them.
Below
is a table which lists shell builtin commands, the standard
shells that
support them and whether they exist as standalone utilities.
DESCRIPTION
Shell builtin commands are commands that can be executed within
the run-
ning shell's process. Note that, in the case of csh(1)
builtin com-
mands, the command is executed in a subshell if it occurs as any
compo-
nent of a pipeline except the last.
If a command specified to the shell contains a slash ``/'',
the shell
will not execute a builtin command, even if the last component
of the
specified command matches the name of a builtin command.
Thus, while
specifying ``echo'' causes a builtin command to be executed under
shells
that support the echo builtin command, specifying ``/bin/
echo'' or
``./echo'' does not.
While some builtin commands may exist in more than one
shell, their
operation may be different under each shell which supports
them. Below
is a table which lists shell builtin commands, the standard
shells that
support them and whether they exist as standalone utilities.
Well, this is a bit of a cheat. The Mac produces ragged right margins,
perhaps evidence that the Unix folk finally realize their mistake. So
I justified the right margin myself manually. Maybe they're equally
readable to you, but not to me, and I'm sure not to many others. I
should really find some right-justified man page and shrink all the
spaces to single spaces. Maybe later.
> > It's amazing I ever stumbled upon the 'cd -' command, which useful for
> > going to your previous working directory. I certainly wouldn't have
> > found it here!
>
> But, it is on the man page for "csh" which is the shell I use. Interestingly
> enough, I didn't now that and, obviously, have never used it in over 30
> years of doing Unix. Now that's obscure. But then, there are pages of
> stuff vi does that I have never used, too.
I must have seen someone else do this. Or maybe I made a big typo!
Note that my TO.COM -- available for free at fine freeware sights
everywhere -- is far superior. Okay, not really fair, as VMS gives you
SET DEFAULT, which I think finally after 2 or 3 decades has its two
primary bugs fixed. One could test on EISNER, I suppose.
On a related note, I recently saw a developer type
cd --
I thought: wow, a way to go 2 levels up! Alas, some brief testing on
my part showed that it was just the equivalent of
cd
in which case, what's the point?
Lots of stuff in vi is not necessary. If you spend hours a day in vi,
then it might be worth learning. Thankfully, with vim, you can finally
cut, copy, and paste without counting lines, or doing tricks with
search strings. And the rest is easily done with a small subset of the
vi command set.
>
> bill
>
> --
> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
> billg... at cs.scranton.edu | and a sheep voting on what's for dinner.
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h>
AEF
I'm voting for filet mignon.
More information about the Info-vax
mailing list