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

[AEF]

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. Doesn't that
perform a Hold Screen operation?

Configure? We're talking several hundred servers! Well, maybe fewer,
but I think it's certainly over 100.

>
> >> In aggregate, this isn't much different from having what TO.COM
> >> provides, though the details do differ.
>
> > It's far less.
>
> Caveat: not having used TO.COM and having just looked at the
> description from the Freeware, writing what TO.COM is documented to
> provide looks to be a SMOP in the shell, though that SMOP within the
> margin for error caused by some fundamental differences between OpenVMS
> and whichever Unix you're using.  A Unix system doesn't typically have
> a direct analog of an OpenVMS logical name, for instance.

Well, there are the environment variables. I could use $last, or
$2back, etc., instead of the logical names in TO.COM. But I still have
to copy it to over 100 servers.

Just a proof of concept example:

new-host:transman alanfeldman$ pwd
/Users/alanfeldman/transman
new-host:transman alanfeldman$ blah=`pwd`
new-host:transman alanfeldman$ echo $blah
/Users/alanfeldman/transman
new-host:transman alanfeldman$ cd ..
new-host:~ alanfeldman$ touch $blah/woah
new-host:~ alanfeldman$ ls $blah/woah
/Users/alanfeldman/transman/woah
new-host:~ alanfeldman$
new-host:~ alanfeldman$ cp vuc.txt $blah/
new-host:~ alanfeldman$ ls $blah/vuc.txt
/Users/alanfeldman/transman/vuc.txt
new-host:~ alanfeldman$

> These differences get back to the "don't automatically try to use the
> same solution on different platforms, as that path often leads to
> frustration" discussion.  Or more succinctly, "VMS != Unix"

True.

> You can combine something like sethost with the z.z script shown above
> to get pretty close to what TO.COM provides.

I'll keep that in mind.

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.

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

Thanks for your help!

>
> --
> Pure Personal Opinion | HoffmanLabs LLC

AEF