[Info-vax] Long uptime cut short by Hurricane Sandy

[Bill Gunshannon]

In article <6a28aa9f-b23c-4aec-a419-18932d0455ef at n2g2000yqg.googlegroups.com>,
	AEF <spamsink2001 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
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.

>                                                  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.


>> 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".

>> > 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?
Can you read Arabic?  Now there is cryptic.  But for some reason the
Arabs didn't seem to think so.

>                                                                 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.  :-)

>                                                       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!! :-)

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.

> Some man pages are loaded with incomprehensible stuff. 

Like?

>                                                         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?

>            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.

> 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.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>