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

[Stephen Hoffman]

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.

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

Here are a few search keywords:
<http://debianlinux.net/system-management/distributed-automated-system-management.html> 

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

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

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



-- 
Pure Personal Opinion | HoffmanLabs LLC