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

[AEF]

On Feb 3, 3:31 pm, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
wrote:
> On 2013-02-03 19:11:22 +0000, AEF said:

>
> > On Feb 3, 7:29 am, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
> > wrote:
> >> On 2013-02-03 05:38:26 +0000, AEF said:
>
> >>> I tried to write a script once that changed directory. It didn't work.
> >>> Why? Because it forked itself to oblivion. I was told to try it with a
> >>> period and a space in front it.
>
> >> The leading dot-and-space syntax is shell shorthand for the shell's
> >> source command.  This command causes the script to run in the current
> >> process environment, and not in its own shell.
>
> > So I found out.
>
> >> In VMS terms, you created a subprocess, issued a SET DEFAULT or
> >> possibly defined some symbols or some process logical names, and got
> >> nothing back when the subprocess exited; no changed default, no symbols
> >> and no logical names.   This is analogous to the difference between the
> >> SPAWN @mumble command and the @mumble command in DCL.
>
> > Yep, I figured that.
>
> >> Here's a sequence that creates a script that uses cd to change the
> >> default directory of the current process.
>
> >> $ cat z.z
> >> #!/bin/bash
> >> cd ~/foo
> >> $ chmod o+x z.z
> >> $ alias foo=.\ ~/z.z
> >> $ foo
>
> >> This sequence is similar to setting up a DCL foreign command for a
> >> procedure, though with the added detail of making the script
> >> executable.   In this case, this is also very close to the DCL command:
>
> >> $ FOO :== SET DEFAULT yourloginroot:[foo]
>
> > Cool!
>
> >> You could also use
>
> >> $ alias foo=source\ ~/z.z
>
> >> in the above script, to make what's going on a little more verbose.
>
> >> Yes, I do believe I've mentioned bash is cryptic.
>
> > Agreed.
>
> >> The sethost script <http://labs.hoffmanlabs.com/node/1831> that I'd
> >> mentioned in a recent post is an example of using a script to shorten
> >> up common commands, too.
>
> >>> Fine, but something else broke. I
> >>> figured I should try it another time. And even if I write such a
> >>> thing, I have to copy it to hundreds of servers running various
> >>> versions of Solaris and Red Hat.
>
> >>> I've been using the ^R trick lately, so that helps. Still a far cry
> >>> from TO.COM.
>
> >> ^S and ^R fall out of what readline provides.  There are a number of
> >> other features used for rummaging the history.  On BSD, see the
> >> editline stuff.  Also set vim or emacs or nano or whatever you'd prefer
> >> as your editor, and cause the shell to use the same control sequences
> >> as your editor.  And you'll probably want to configure and use command
> >> completion, too.
>
> > Hmmm. Didn't know about ^S. I'll have to check it out.
>
> man bash and search or grep for readline / editline for details.

OK. Later.

>
> > Doesn't that perform a Hold Screen operation?
>
> On your terminal, with serial communications.  In other environments,
> ^S and ^Q are available and used.
>
> > Configure? We're talking several hundred servers! Well, maybe fewer,
> > but I think it's certainly over 100.
>
> Sites running hundreds or thousands of servers — some sites running
> even five or ten servers — utilize tools to manage these deployments.
> To push out files and commands, and to provide package and maintain and
> customize installation environments, and to handle updates.

Not worth it for one program.

>
> Here are a few search keywords:
> <http://debianlinux.net/system-management/distributed-automated-system...>
>
> <http://alternativeto.net/software/puppet/>
>
> > Well, there are the environment variables. I could use $last, or
> > $2back, etc., instead of the logical names in TO.COM.
>
> Environment variables aren't a direct match to logical names.
> Similarities, yes, but there also are substantive differences, too.

Close enough for this. I just need to be able to use the variable as
part of a path.

Seems to me that at the most basic level, logical names are
environment variables, in a sense anyway. Now, they have a much richer
structure, with the different tables of varying scope, the various
access modes, search lists, and what not. Their chief use is in
device- and file-specs, of course. But they're also used in MAIL, for
queues, for storing data, and more. So it's just a matter of what's
translating them in what context. There's the automatic translation
when part of a generalized file-spec, and automatic translation in
certain other contexts. That's all different from environment
variables in Unix. But I don't need all that for this. I just need the
ability to have something I can use in a path.

>
> > I can't believe that no one in the Unix or Linux or Gnu or whatever
> > world hasn't written something like TO.COM for Unix/Linux, or the bash
> > shell in particular.
>
> So go write it?

Well, I tried once when first starting out in Unix, and decided to
wait until I learned more about scripting.

> >> Or switch the script to a bash script (or switch the shebang to invoke
> >> python, perl, php, ruby, scala or whatever, and use the alias and the
> >> script to translate that CSV or XML or whatever-format-file you're
> >> using the VT to cause the MicroVAX to boot VMS to invoke that DCL
> >> procedure to mung that text.  Or dispense with the command-line stuff
> >> entirely, and allow the boss to cut-n-paste the input data into a text
> >> box on some web server, and process it there.  Or get rid of the whole
> >> chain of tools and get rid of the spreadsheet, and move the tool
> >> owership, bug tracking and related details into the same database, and
> >> all with a web UI and possibly with local clients for Android and iOS
> >> devices.
>
> > You lost me on this. It looks like you're going back to my problems
> > with the Application Owner Table and getting a VMS boot to not put the
> > VT into No Auto Wrap mode.
>
> Weren't you processing spreadsheet data using DCL on those MicroVAX
> boxes?  Doesn't removing that requirement also get rid of the issue
> with the VT terminals?   Removing need for the DCL, removes the need
> for VMS, which retires the MicroVAX boxes, which means no need of
> dealing with VT terminals and the foibles of wrapping.

Yes.

Yes, but I rarely use the VT terminals now. Back when I had as many as
38 to 40 MicroVAXes online, I had a lot more boots to do for various
reasons. That's when I needed this problem solved. There were some
messages where all the characters past column 80 would get written to
column 80, thereby destroying each other. I wanted to see those
messages. Now it's quite rare that I do a boot, so it's not a big deal
anymore. I don't recall why I even mentioned it, but I'm not going to
re-read the thread to find out.

Right now it's easier to leave things as they are. I have loads of
other stuff to do. But thanks for your suggestions, anyway. I'll keep
them in mind for future endeavors.

>
> --
> Pure Personal Opinion | HoffmanLabs LLC

AEF