How do I add 2 letters to a long command at the prompt - VMS

This is a discussion on How do I add 2 letters to a long command at the prompt - VMS ; In article , AEF writes: > On Sep 28, 6:35 am, clubley@remove_me.eisner.decus.org-Earth.UFP > (Simon Clubley) wrote: >> In article , AEF writes: >> >> > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP >> > (Simon Clubley) wrote: >> >> In article ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 69

Thread: How do I add 2 letters to a long command at the prompt

  1. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article , AEF writes:
    > On Sep 28, 6:35 am, clubley@remove_me.eisner.decus.org-Earth.UFP
    > (Simon Clubley) wrote:
    >> In article <5880985a-8e44-45d2-b775-147349648...@u65g2000hsc.googlegroups.com>, AEF writes:
    >>
    >> > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
    >> > (Simon Clubley) wrote:
    >> >> In article <54c74bd9-a1c5-4df0-863f-8a5169737...@m44g2000hsc.googlegroups.com>, AEF writes:

    >>
    >> >> > I'd be quite happy with being with just being able to use RECALL/OUT
    >> >> > in a command procedure. This way I could use my FILTER command
    >> >> > procedure search for strings in the recall buffer.

    >>
    >> >> How would you handle merging the output from multiple simultaneous sessions
    >> >> (assuming that the current command history was loaded at the start of the
    >> >> session) ?

    >>
    >> > I don't need to. And what does this have to do with placing RECALL/
    >> > OUT= in a command procedure? I want to be able to write the
    >> > recall history buffer of my interactive session from a command
    >> > procedure. There is nothing merged from anywhere else; this is the
    >> > standard vendor-supplied DCL recall buffer we are talking about here.

    >>
    >> As you realised later on, I'm talking about the capabilities available in
    >> bash and not DCL.

    >
    > But I'm not using bash, I'm using DCL. I simply want to be able to use
    > the RECALL command from within a *DCL* command procedure. That's all.
    >


    I understand and I can see why we've got confused because we are thinking
    about two different things, but don't forget that I started this thread by
    talking about things that DCL was missing compared to bash so I replied
    with that as a frame of reference - I had initially assumed that your FILTER
    routine was a way of doing what I wanted to do.

    >> I hadn't realised, since we were talking about saving command history, that
    >> your FILTER routine was designed to search through command output instead.
    >>
    >> > And where is the security problem? If I can run RECALL from a DCL
    >> > prompt, how is that different -- security-wise -- from running the
    >> > same from a command procedure?

    >>
    >> The issue, when saving command history, is saving sensitive information in
    >> permanent form in a disk file between sessions.

    >
    > Yes, I know that. But what's the difference between saving sensitive
    > information when running the RECALL command at a DCL prompt compared
    > to running it from within a command procedure? In both cases, the
    > secret information is written to disk. So why is the former okay but
    > not the latter?
    >


    It's not. I'm talking about the act of writing sensitive commands to
    disk. You raised the issue of wanting to use recall/out within a command
    procedure and must have misinterpreted my responses as somehow saying that
    one way of using recall/out was ok, but the other was not.

    > And what about if the system manager types sensitive info on the
    > screen and then executes a Print Screen operation? Then, by the same
    > reasoning, the Print Screen operation should also be dropped, right?
    > In fact, again by the same reasoning, the entire RECALL command itself
    > should be dropped!
    >


    Now, now - that's the Microsoft approach - protect the users from themselves.
    :-)

    Seriously however, as with the decision to commit command history to disk,
    it's up to the user to decide how to correctly use a supplied facility.
    The whole point of this thread is to discuss facilities that are included
    as standard in shells like bash, but are not available within DCL.

    >>
    >> No, there aren't to my knowledge. I was thinking about the problems that
    >> RECALL/INPUT and RECALL/OUTPUT, as currently implemented, would have if
    >> you have multiple terminal sessions open at the same time.

    >
    > Ah, you were talking about bash and writing about DCL RECALL, as you
    > do below. OK.
    >


    Yes, that's right. I'm using bash as an example of the things that DCL is
    missing.

    >> A DCL RECALL command to load the saved history at the start of a session,
    >> followed by a command to save the history at the end of the session would
    >> have that effect unless there was some way of telling recall to only
    >> append the commands entered during that session to an existing file.

    >
    > I just tried it and it works fine: Log in, do your stuff, RECALL/
    > OUT=R.TMP, log out; log in, RECALL/INPUT=R.TMP!. But if you run RECALL/
    > OUTPUT=R.TMP followed by RECALL/INPUT=R.TMP in the *middle* of a
    > session, then yes, it does as you describe; it uses the KISS paradigm.
    >


    That's true. However, imagine having multiple terminal sessions open at
    the same time, all of which have had their command buffers loaded with
    the saved history. Now imagine that you exit each session one by one,
    with the logout command using recall/out to save the command history.

    You will end up with full multiple copies of the command history added
    to the file if you have a command procedure to write the resulting file
    to a permanent command history file. If you just write the resulting
    output from recall/output directly to the history file, then the contents
    of all sessions except the last one will be overwritten.

    As far as I can see, recall/out has no way of appending only the commands
    actually used within the current session to an existing history file.

    >
    > You didn't write that. You said that when you unset the variable, the
    > current session doesn't get written out *if* you've used secret
    > params, which means that it *does* get written out if you *didn't* use
    > secret commands. What you meant was the converse: If you are going to
    > use secret params, you unset the variable first so that *no* commands
    > in your session are written to disk. That's not the same.
    >


    Yes, I can see how someone who doesn't know bash would indeed parse my
    ambiguous statement like that.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

  2. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Sep 28, 11:56 am, clubley@remove_me.eisner.decus.org-Earth.UFP
    (Simon Clubley) wrote:
    > In article , AEF writes:
    >
    > > On Sep 28, 6:35 am, clubley@remove_me.eisner.decus.org-Earth.UFP
    > > (Simon Clubley) wrote:
    > >> In article <5880985a-8e44-45d2-b775-147349648...@u65g2000hsc.googlegroups.com>, AEF writes:

    >
    > >> > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
    > >> > (Simon Clubley) wrote:
    > >> >> In article <54c74bd9-a1c5-4df0-863f-8a5169737...@m44g2000hsc.googlegroups.com>, AEF writes:

    >
    > >> >> > I'd be quite happy with being with just being able to use RECALL/OUT
    > >> >> > in a command procedure. This way I could use my FILTER command
    > >> >> > procedure search for strings in the recall buffer.


    This is my key desire as to what DCL can't do that you say bash can.
    Once I mention this, bash becomes only indirectly relvant, even though
    this *is* relevant to the discussion as the thread evolves.

    > >> >> How would you handle merging the output from multiple simultaneous sessions
    > >> >> (assuming that the current command history was loaded at the start of the
    > >> >> session) ?

    >
    > >> > I don't need to. And what does this have to do with placing RECALL/
    > >> > OUT= in a command procedure? I want to be able to write the
    > >> > recall history buffer of my interactive session from a command
    > >> > procedure. There is nothing merged from anywhere else; this is the
    > >> > standard vendor-supplied DCL recall buffer we are talking about here.

    >
    > >> As you realised later on, I'm talking about the capabilities available in
    > >> bash and not DCL.

    >
    > > But I'm not using bash, I'm using DCL. I simply want to be able to use
    > > the RECALL command from within a *DCL* command procedure. That's all.

    >
    > I understand and I can see why we've got confused because we are thinking
    > about two different things, but don't forget that I started this thread by
    > talking about things that DCL was missing compared to bash so I replied
    > with that as a frame of reference - I had initially assumed that your FILTER
    > routine was a way of doing what I wanted to do.


    I don't know why. I brought it up as a separate desire and that I'd
    simply be happy even if I could just run (DCL's!) RECALL command from
    within a command procedure so that I could use FILTER with it. The
    "just" part means that I'm not talking about the whole shebang that
    you brought up, but just a part of it.

    Let's go to the videotape (this is a reference to a sporstcaster on a
    local New York City TV station who always says that immediately before
    they show each clip from a sports game):

    You wrote:

    "Automatic retention of command history, including the automatic
    merging of
    just the new commands from that session into the command history file.

    "Tab based filename completion.

    "Command history searching is much more elegant in bash. Hit Ctrl-R,
    type a
    few characters found anywhere in the command, which starts an
    immediate
    search through the command history, and just keep hitting Ctrl-R until
    the
    required command is found."

    My reply was the following:

    "> > Automatic retention of command history, including the automatic
    merging of
    > > just the new commands from that session into the command history file.


    " Command history retention in files has security implications.

    "I'd be quite happy with being [sic] with just being able to use
    RECALL/OUT
    in a command procedure. This way I could use my FILTER command
    procedure search [sic] for strings in the recall buffer.

    "Yeah, let me guess: security implications. "

    So as far as "history retention" is concerned, I was just saying that
    I'd be happy for VMS Engineering to just simply rewrite the RECALL
    command and/or DCL so as to allow me to run RECALL from within a
    command procedure. Then you went on and on about bash in response to
    this, which I didn't ask about and don't care about for this question
    as it is not directly relevant.

    > >> I hadn't realised, since we were talking about saving command history, that
    > >> your FILTER routine was designed to search through command output instead.

    >
    > >> > And where is the security problem? If I can run RECALL from a DCL
    > >> > prompt, how is that different -- security-wise -- from running the
    > >> > same from a command procedure?

    >
    > >> The issue, when saving command history, is saving sensitive information in
    > >> permanent form in a disk file between sessions.


    > > Yes, I know that. But what's the difference between saving sensitive
    > > information when running the RECALL command at a DCL prompt compared
    > > to running it from within a command procedure? In both cases, the
    > > secret information is written to disk. So why is the former okay but
    > > not the latter?

    >
    > It's not. I'm talking about the act of writing sensitive commands to
    > disk. You raised the issue of wanting to use recall/out within a command
    > procedure and must have misinterpreted my responses as somehow saying that
    > one way of using recall/out was ok, but the other was not.


    But DCL treats it as such! I'm simply asking why. Why the
    *difference*? Forget about bash for a minute. It's not relevant to
    this question! If you don't know the answer then please simply just
    say so. Please don't repeat "security"; I've got that part already.
    But "security" applies to *both* cases, and DCL does it in only one of
    the two cases, so you're not answering the question.

    Whenever I ask this question, (i.e. why you can't run RECALL from
    within a command procedure), people always respond with "it's a
    security issue". Fine. But how are the "security implications"
    different bewteen running RECALL from a DCL prompt and running the
    same from within a command procedure, since the resulting output is
    the same? What's the difference? The result is the same. The security
    issue is the same. So why was one case (apparently, if not certainly)
    designed to not work while the other clearly does?

    I don't know how to make this question any clearer, any more explicit,
    any more plainly, any more to the point. For the purposes of this
    question, I'm asking about DCL, not bash.

    I can, however, make the question more succinct:

    Why does the DCL command RECALL work at a prompt, but not from within
    a command procedure; even though the result, and hence the security
    issue, is the same?

    > > And what about if the system manager types sensitive info on the
    > > screen and then executes a Print Screen operation? Then, by the same
    > > reasoning, the Print Screen operation should also be dropped, right?
    > > In fact, again by the same reasoning, the entire RECALL command itself
    > > should be dropped!

    >
    > Now, now - that's the Microsoft approach - protect the users from themselves.
    > :-)


    Except that in many cases it doesn't. It should, though, protect the
    users from itself!

    > Seriously however, as with the decision to commit command history to disk,
    > it's up to the user to decide how to correctly use a supplied facility.
    > The whole point of this thread is to discuss facilities that are included
    > as standard in shells like bash, but are not available within DCL.


    And running the DCL command RECALL from within a command procedure was
    designed to not work. Even if it's not the original motivation of the
    thread, I'm brining it up as a separate question. And your issue with
    bash is similarly not the original point of the thread either but is
    brought up as a separate, though related, point. The original
    motivation was a poster wanting help with editing commands that are so
    long, they wrap. Your bringing up bash is just as "off-thread" as my
    bringing up the issue with RECALL.

    > >> No, there aren't to my knowledge. I was thinking about the problems that
    > >> RECALL/INPUT and RECALL/OUTPUT, as currently implemented, would have if
    > >> you have multiple terminal sessions open at the same time.

    >
    > > Ah, you were talking about bash and writing about DCL RECALL, as you
    > > do below. OK.

    >
    > Yes, that's right. I'm using bash as an example of the things that DCL is
    > missing.


    Fine. I'm simply asking what the motivation might be for one of those
    things that DCL can't do. While that doesn't involve bash directly, it
    *is* relevant to this discussion; just as bash doesn't directly
    involve the original poster's problem.

    You want DCL to do blah, blah, blah. . .blah and I'm just saying that
    I'd be thrilled even if only a certain PART of one of those blah's
    were made to work.

    > >> A DCL RECALL command to load the saved history at the start of a session,
    > >> followed by a command to save the history at the end of the session would
    > >> have that effect unless there was some way of telling recall to only
    > >> append the commands entered during that session to an existing file.

    >
    > > I just tried it and it works fine: Log in, do your stuff, RECALL/
    > > OUT=R.TMP, log out; log in, RECALL/INPUT=R.TMP!. But if you run RECALL/
    > > OUTPUT=R.TMP followed by RECALL/INPUT=R.TMP in the *middle* of a
    > > session, then yes, it does as you describe; it uses the KISS paradigm.

    >
    > That's true. However, imagine having multiple terminal sessions open at
    > the same time, all of which have had their command buffers loaded with
    > the saved history. Now imagine that you exit each session one by one,
    > with the logout command using recall/out to save the command history.
    >
    > You will end up with full multiple copies of the command history added
    > to the file if you have a command procedure to write the resulting file
    > to a permanent command history file. If you just write the resulting
    > output from recall/output directly to the history file, then the contents
    > of all sessions except the last one will be overwritten.
    >
    > As far as I can see, recall/out has no way of appending only the commands
    > actually used within the current session to an existing history file.


    Fine, but you already made that point in a previous post. I'm no
    asking about that.

    > > You didn't write that. You said that when you unset the variable, the
    > > current session doesn't get written out *if* you've used secret
    > > params, which means that it *does* get written out if you *didn't* use
    > > secret commands. What you meant was the converse: If you are going to
    > > use secret params, you unset the variable first so that *no* commands
    > > in your session are written to disk. That's not the same.

    >
    > Yes, I can see how someone who doesn't know bash would indeed parse my
    > ambiguous statement like that.


    It wasn't ambiguous; it was the converse of what you meant.

    >
    > Simon.
    >
    > --
    > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    > Microsoft: Bringing you 1980's technology to a 21st century world


    AEF

  3. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article <192218fb-968d-4eaf-870a-b25981e7dc46@f36g2000hsa.googlegroups.com>, AEF writes:
    > On Sep 28, 11:56 am, clubley@remove_me.eisner.decus.org-Earth.UFP
    > (Simon Clubley) wrote:
    >>
    >> I understand and I can see why we've got confused because we are thinking
    >> about two different things, but don't forget that I started this thread by
    >> talking about things that DCL was missing compared to bash so I replied
    >> with that as a frame of reference - I had initially assumed that your FILTER
    >> routine was a way of doing what I wanted to do.

    >
    > I don't know why. I brought it up as a separate desire and that I'd
    > simply be happy even if I could just run (DCL's!) RECALL command from
    > within a command procedure so that I could use FILTER with it. The
    > "just" part means that I'm not talking about the whole shebang that
    > you brought up, but just a part of it.
    >


    I misunderstood what your FILTER routine was doing.

    >>
    >> It's not. I'm talking about the act of writing sensitive commands to
    >> disk. You raised the issue of wanting to use recall/out within a command
    >> procedure and must have misinterpreted my responses as somehow saying that
    >> one way of using recall/out was ok, but the other was not.

    >
    > But DCL treats it as such! I'm simply asking why. Why the
    > *difference*? Forget about bash for a minute. It's not relevant to
    > this question! If you don't know the answer then please simply just
    > say so. Please don't repeat "security"; I've got that part already.
    > But "security" applies to *both* cases, and DCL does it in only one of
    > the two cases, so you're not answering the question.
    >


    I see the confusion now about security.

    I was responding to the suggestion made early on in the thread by someone
    else that storing command history within a file is a security risk. I
    thought you were continuing that line of enquiry.

    You on the other hand were discussing security in the context of having been
    told that recall/out can't be implemented within a command procedure
    because it's a security problem. That's an interesting comment and it would
    be interesting to know from VMS Engineering why they consider it a security
    issue.

    I can only think that they are concerned that a user could be tricked into
    running a command procedure that could capture their commands and mail them
    somewhere without the user knowing. However, I can think of far more
    dangerous things that such a command procedure could do.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

  4. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    Simon Clubley wrote:

    > You will end up with full multiple copies of the command history added
    > to the file if you have a command procedure to write the resulting file
    > to a permanent command history file



    Not if your command procedure has code such as:

    $recall/output=temp.tmp
    $append temp.tmp mycommands.dat
    $sort mycommands.dat mycommands.dat/noduplicates

    (ok, you might have to deal with cases where your file grows to be
    bigger than what VMS supports for RECALL/INPUT :-)


    But even with such a thing, an abnormal termination of your session
    would not update the stored file, it would only be updated with a
    "normal" termination that ends up calling your procedure before doing
    the logout command.

    Yes, the Unix way is more elegant. There should be some way to turn it
    off when doing a security related session if it were implemented on VMS.

  5. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article , AEF writes:
    >
    > Yes, I know that. But what's the difference between saving sensitive
    > information when running the RECALL command at a DCL prompt compared
    > to running it from within a command procedure? In both cases, the
    > secret information is written to disk. So why is the former okay but
    > not the latter?


    It makes it impossible to automate a potential security mistake.


  6. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Sep 28, 2:28*pm, clubley@remove_me.eisner.decus.org-Earth.UFP
    (Simon Clubley) wrote:
    > In article <192218fb-968d-4eaf-870a-b25981e7d...@f36g2000hsa.googlegroups..com>, AEF writes:
    >
    > > On Sep 28, 11:56 am, clubley@remove_me.eisner.decus.org-Earth.UFP
    > > (Simon Clubley) wrote:

    >
    > I misunderstood what your FILTER routine was doing.


    btw.... on systems with PERL available (not too many 6.2 systems have
    perl)
    I would use a perl 'command line' or script to extend a filter to
    regular expressions.
    For example:

    $ perl -e "$re = shift; $cmd=join q( ),@ARGV; for (qx($cmd)){print if /
    $re/i}" HE show users
    HEIN 2 1
    HENKLE 2 1
    SCHENKENBERG 1

    $ perl -e "$re = shift; $cmd=join q( ),@ARGV; for (qx($cmd)){print if /
    $re/i}" "^ HE" show users
    HEIN 2 1
    HENKLE 2 1

    or as script
    ------------------------------ filter.pl ---------------------
    $re = shift and $cmd=join q( ),@ARGV or
    die "Usage: Perl $0 [...]";
    for (qx($cmd)) {
    print if /$re/i
    }
    -----------------------------------------------------------------

    $perl filter.pl \s[HK] show users ! Look for users name starting
    with H or K ...
    HEIN 2 1
    HENKLE 2 1
    KILGALLEN 1


    > You on the other hand were discussing security in the context of having been
    > told that recall/out can't be implemented within a command procedure
    > because it's a security problem. That's an interesting comment and it would
    > be interesting to know from VMS Engineering why they consider it a security
    > issue.


    Over the decades I have been present at many an lunchtime table
    discussion
    with OpenVMS Engineering discussing this.
    The last serious attempt to resurrect this was by Guy Peleg back in
    2002.
    If I recall (sic) correctly, it was in an HP-internal OpenVMS notes
    discussion
    where Fred K was the loudest nay sayer at the time.

    The feeble security argument against this typically was that a
    malicious command
    file/program could silently grab command and scrape those for useful
    passwords and such.
    However...
    1) does that not imply a tolerance for malicious scripts gettign onto
    the box?!
    How is that acceptable? Not allowing programmed recall is like close
    the bar door after the horse has escaped!
    2) The command recall text is stored in user-mode readable DCL
    memory.
    Procedures and programs exist vor verious (older) OpenVMS versions to
    get at the recall buffers.
    Not having access to recall from a script is therefor an attempt at
    secutiry through obscurity.
    That is NOT the OpenVMS way of doing things!

    My comment from a much similar discussion within Digital (conpaq?)
    years ago...
    ================================================== =========
    Note 4925.5 RECALL/OUT=xxx from command
    procedure 5 of 6
    MIASYS::HEIN "Hein RMS van den Heuvel" 19 lines 19-
    JAN-2001 09:24
    --------------------------------------------------------------------------------

    > UNIX of course has this feature and it screws up royally if you

    have
    > more than one concurrent session. OK, a little strong but it can

    get

    Actually, IMHO Unix does *remarkably* well with concurrent
    sessions.
    I happen to do projects with a person on the other side of the
    Atlantic
    and we communicate through the command line history at times :-)

    Yes I've seen and participated in the old security discussion on
    RECALL/OUT and still feel it should be there and should have been
    there. It is just security by obfusication (sp?) which we know is
    not security. RECALL/OUT would just make it easier to hide a
    password
    scraper. Furthermore, there are plenty of customers which will
    never
    ever put a password on a comand line (many probably do not even
    know
    how to) and those are being hurt without recourse.
    Maybe a sysgen switch/variable is needed:
    ALLOW_INSECURE_DCL_RECALL_SAVE

    fwiw,
    Hein.
    -----------------------------------


    > I can only think that they are concerned that a user could be tricked into
    > running a command procedure that could capture their commands and mail them
    > somewhere without the user knowing. However, I can think of far more
    > dangerous things that such a command procedure could do.


    Exactly.

    Cheers,
    Hein.


  7. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Sep 29, 8:36*am, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article , AEF writes:
    >
    >
    >
    > > Yes, I know that. But what's the difference between saving sensitive
    > > information when running the RECALL command at a DCL prompt compared
    > > to running it from within a command procedure? In both cases, the
    > > secret information is written to disk. So why is the former okay but
    > > not the latter?

    >
    > * *It makes it impossible to automate a potential security mistake.


    There is a trade-off between functionality and risk, and in my
    situation, the functionality of being able to run RECALL in a command
    procedure would greatly, even fantastically exceed any risk. I can
    guarantee you that on my systems it would not be a problem.

    There are other things you could disable for the same reason, like
    DECnet for example.

    What do you mean by "automate"? I can see hiding it in a Trojan Horse,
    but automate?

    AEF

  8. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article <31684607-f769-4224-8c81-74cf93afaaeb@k30g2000hse.googlegroups.com>, AEF writes:
    >On Sep 29, 8:36=A0am, koeh...@eisner.nospam.encompasserve.org (Bob
    >Koehler) wrote:
    >> In article
    >..com>, AEF writes:
    >>
    >>
    >>
    >> > Yes, I know that. But what's the difference between saving sensitive
    >> > information when running the RECALL command at a DCL prompt compared
    >> > to running it from within a command procedure? In both cases, the
    >> > secret information is written to disk. So why is the former okay but
    >> > not the latter?

    >>
    >> =A0 =A0It makes it impossible to automate a potential security mistake.

    >
    >There is a trade-off between functionality and risk, and in my
    >situation, the functionality of being able to run RECALL in a command
    >procedure would greatly, even fantastically exceed any risk. I can
    >guarantee you that on my systems it would not be a problem.


    You can always write your own recall buffer dump and or recall buffer
    manipulator for use in your own DCL environment. It's not difficult.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  9. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    Simon Clubley writes:
    > AEF writes:
    >> Bob Koehler wrote:
    >>> Simon Clubley writes:
    >>>> Automatic retention of command history, including the automatic merging
    >>>> of just the new commands from that session into the command history file.
    >>>
    >>> Command history retention in files has security implications.

    >>
    >> I'd be quite happy with being with just being able to use RECALL/OUT
    >> in a command procedure. This way I could use my FILTER command
    >> procedure search for strings in the recall buffer.

    >
    > How would you handle merging the output from multiple simultaneous sessions
    > (assuming that the current command history was loaded at the start of the
    > session) ?
    >
    > In bash, only the commands entered during that session get appended to the
    > command history file. That way you can have multiple simultaneous bash
    > sessions writing to the command history file without each running copy of
    > bash dumping it's own copy of the full command history into the history
    > file.
    >
    >> Yeah, let me guess: security implications.

    >
    > The way that I handle that in bash is to unset the history filename
    > variable so that the current session doesn't get written out if I've
    > used security related parameters on the command line.


    And do you force vim to vi-only mode so that it doesn't save all the
    critical strings - not to mention voluminous edit history information -
    from your edit sessions in .viminfo?

    Imagine my surprise when, having decided to clean up all my old embedded
    password ppp stuff (clear text passwords in the 'secrets' files!), I found my
    critical password for accessing hundreds of systems at work saved away for
    anyone to see if they ever obtained physical access to my home workstation.
    At least I knew about the secrets files, so I could take steps to cleanse
    them later on, perhaps shifting to using a script to generate them on the
    fly as needed.

    Open source means radically differing degrees of developer real world
    experience. Open source means, effectively, amateurism. Very talented
    amateurs, perhaps, but don't expect them to have the slightest understanding
    of reliability, availability, and security as it applies to _your_ business.

    Security by obscurity gets a bad rap, by the way - just running the 'secrets'
    files thru rot13 before writing them would eliminate a huge percentage of
    security risks by eliminating casual users (and many 'greppers') from the
    list of likely attackers.

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu
    > Simon.
    >
    > --
    > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    > Microsoft: Bringing you 1980's technology to a 21st century world


  10. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article <00A80651.AB22D074@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
    > You can always write your own recall buffer dump and or recall buffer
    > manipulator for use in your own DCL environment. It's not difficult.


    This works:

    $ pipe recall/out=x.lis ; search x.lis sea

    Obviously, you could use @script x.lis after the semicolon if you wanted.

    And you could put the whole pipe string in a symbol, e.g.,

    $ rs:==pipe recal/out=x.lis ; sear x.lis

    Of course, using a unique file name based on process ID would be better:

    $ rs_fname:=='f$getjpi(0,"PID")'.rs_scratch
    $ rs:==pipe recal/out='rs_fname' ; sear 'rs_fname'

    Adding autocleanup:

    $ pipe rs_fname:=='f$getjpi(0,"PID")'.rs_scratch ; copy nl: &rs_fname
    $ rs:==pipe recal/out='rs_fname' ; purg 'rs_fname' ; sear 'rs_fname'

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu

    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


  11. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article <50WZu8it2neF@eisner.encompasserve.org>, cornelius@eisner.decus.org (George Cornelius) writes:
    >
    > And do you force vim to vi-only mode so that it doesn't save all the
    > critical strings - not to mention voluminous edit history information -
    > from your edit sessions in .viminfo?
    >


    I'm a emacs user and not a vim user, but yes, I make sure that applications
    don't write sensitive information into configuration files.

    If I use an application that requires information that I would rather not
    be kept in a permanent form, then the first time that I run it, I check to
    see what configuration information it actually writes out - I don't rely
    on configuration settings.

    I also tend to check every so often as well, just to make sure that nothing
    has changed.

    BTW, I also make sure that sensitive information isn't left floating around
    in debugging log files.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

  12. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    George Cornelius wrote:

    > This works:
    >
    > $ pipe recall/out=x.lis ; search x.lis sea



    Or, with a sufficiently recent version of VMS:

    recall/search sea


  13. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Oct 20, 12:21 pm, cornel...@eisner.decus.org (George Cornelius)
    wrote:
    > In article <00A80651.AB22D...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
    >
    > > You can always write your own recall buffer dump and or recall buffer
    > > manipulator for use in your own DCL environment. It's not difficult.


    Cool. Of course!

    I'm working on it.

    >
    > This works:
    >
    > $ pipe recall/out=x.lis ; search x.lis sea


    I'm running VMS V6.2, so I don't have PIPE. (Please, for those who
    haven't heard my spiel on this before: Upgrading is NOT an option. I
    have too many systems and no time for it.)

    Regardless, it doesn't work (run on DECUServe):

    $ RECALL/ALL
    1 TYPE RECA.COM
    2 DIR/SIZE=ALL X.LIS
    3 @RECA
    4 SH DEV DK
    5 SH DEV DS
    6 SH DEF
    7 ED/EDT RECA.COM
    8 ED RECA.COM
    $ TYPE RECA.COM
    $ pipe recall/out=x.lis ! ; search x.lis sea
    $ @RECA
    $ DIR/SIZE X.LIS
    %DIRECT-W-NOFILES, no files found
    $

    >
    > Obviously, you could use @script x.lis after the semicolon if you wanted.


    OK, but it doesn't work.

    >
    > And you could put the whole pipe string in a symbol, e.g.,
    >
    > $ rs:==pipe recal/out=x.lis ; sear x.lis


    OK, now *this* is obvious, but it still doesn't work.

    >
    > Of course, using a unique file name based on process ID would be better:
    >
    > $ rs_fname:=='f$getjpi(0,"PID")'.rs_scratch
    > $ rs:==pipe recal/out='rs_fname' ; sear 'rs_fname'
    >
    > Adding autocleanup:
    >
    > $ pipe rs_fname:=='f$getjpi(0,"PID")'.rs_scratch ; copy nl: &rs_fname
    > $ rs:==pipe recal/out='rs_fname' ; purg 'rs_fname' ; sear 'rs_fname'


    Nice, but the original trick doesn't work.

    The problem with all this is that something always ends up broken:

    o Running CONTINUE after ^Y (always, apparently -- so far anyway)
    o Passing params that contain quotation marks
    o The RECALL buffer

    Using INQUIRE: While this actually puts the commands into the RECALL
    buffer and allows access to them via the up-arrow, it unfortunately
    causes commands such as "RECALL n" and "RECALL/qual" to do nothing.
    More importantly, INQUIRE causes problems with params that contain
    quotation marks.

    Using READ SYS$COMMAND: This has the enormous advantage of reading the
    command string verbatim, but it only allows you to go one command back
    when you press the up-arrow and doesn't add the command to the RECALL
    buffer.

    I've starting working on the DCL code to emulate my own recall buffer.
    OK. But one cannot run CONTINUE after a control_y: the process goes
    directly back to the command file. Anyone have any ideas of how to
    take care of that?

    The Quick and Dirty Solution (QADS): Spawn a subprocess that writes
    the time to the screen every n minutes. OK, this doesn't break any of
    the above, but it offers only n-minute-resolution. And worse, it will
    clutter up the screen and occasionally interrupt command output!

    It's always something! --Roseanne Roseannadanna

    BTW, if one doesn't want to save commands in a command file by
    redirecting the output from a command procedure containing a RECALL
    command via

    $ @proc.com/OUT=proc.out ! ,

    or similar -- okay, fine. But what's wrong with running RECALL/ALL and
    RECALL from within a command procedure when the output goes to the
    terminal? I guess the answer to this is the KISS methodology.

    Thanks to all for your help and suggestions!

    AEF

    >
    > --
    > George Cornelius cornelius A T eisner D O T decus D O T org

    [...]
    > > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    [...]

  14. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article <789a494a-1fea-4a4d-881e-d9495da8a40b@v56g2000hsf.googlegroups.com>, AEF writes:
    >On Oct 20, 12:21 pm, cornel...@eisner.decus.org (George Cornelius)
    >wrote:
    >> In article <00A80651.AB22D...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
    >>
    >> > You can always write your own recall buffer dump and or recall buffer
    >> > manipulator for use in your own DCL environment. It's not difficult.

    >
    >Cool. Of course!
    >
    >I'm working on it.
    >
    >>
    >> This works:
    >>
    >> $ pipe recall/out=x.lis ; search x.lis sea

    >
    >I'm running VMS V6.2, so I don't have PIPE. (Please, for those who
    >haven't heard my spiel on this before: Upgrading is NOT an option. I
    >have too many systems and no time for it.)
    >
    >Regardless, it doesn't work (run on DECUServe):
    >
    >$ RECALL/ALL
    > 1 TYPE RECA.COM
    > 2 DIR/SIZE=ALL X.LIS
    > 3 @RECA
    > 4 SH DEV DK
    > 5 SH DEV DS
    > 6 SH DEF
    > 7 ED/EDT RECA.COM
    > 8 ED RECA.COM
    >$ TYPE RECA.COM
    >$ pipe recall/out=x.lis ! ; search x.lis sea
    >$ @RECA
    >$ DIR/SIZE X.LIS
    >%DIRECT-W-NOFILES, no files found


    Two things Alan...

    Remove the ! if you actually have that in your PIPE command.
    Secondly, the search command is looking for SEArch... I don't
    see that command in your RECALL list so obvioulsy, the X.LIS
    files would be empty.

    Try:

    $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED



    >$
    >
    >>
    >> Obviously, you could use @script x.lis after the semicolon if you wanted.

    >
    >OK, but it doesn't work.
    >
    >>
    >> And you could put the whole pipe string in a symbol, e.g.,
    >>
    >> $ rs:==pipe recal/out=x.lis ; sear x.lis

    >
    >OK, now *this* is obvious, but it still doesn't work.
    >
    >>
    >> Of course, using a unique file name based on process ID would be better:
    >>
    >> $ rs_fname:=='f$getjpi(0,"PID")'.rs_scratch
    >> $ rs:==pipe recal/out='rs_fname' ; sear 'rs_fname'
    >>
    >> Adding autocleanup:
    >>
    >> $ pipe rs_fname:=='f$getjpi(0,"PID")'.rs_scratch ; copy nl: &rs_fname
    >> $ rs:==pipe recal/out='rs_fname' ; purg 'rs_fname' ; sear 'rs_fname'

    >
    >Nice, but the original trick doesn't work.
    >
    >The problem with all this is that something always ends up broken:
    >
    >o Running CONTINUE after ^Y (always, apparently -- so far anyway)
    >o Passing params that contain quotation marks
    >o The RECALL buffer
    >
    >Using INQUIRE: While this actually puts the commands into the RECALL
    >buffer and allows access to them via the up-arrow, it unfortunately
    >causes commands such as "RECALL n" and "RECALL/qual" to do nothing.
    >More importantly, INQUIRE causes problems with params that contain
    >quotation marks.
    >
    >Using READ SYS$COMMAND: This has the enormous advantage of reading the
    >command string verbatim, but it only allows you to go one command back
    >when you press the up-arrow and doesn't add the command to the RECALL
    >buffer.
    >
    >I've starting working on the DCL code to emulate my own recall buffer.
    >OK. But one cannot run CONTINUE after a control_y: the process goes
    >directly back to the command file. Anyone have any ideas of how to
    >take care of that?
    >
    >The Quick and Dirty Solution (QADS): Spawn a subprocess that writes
    >the time to the screen every n minutes. OK, this doesn't break any of
    >the above, but it offers only n-minute-resolution. And worse, it will
    >clutter up the screen and occasionally interrupt command output!
    >
    > It's always something! --Roseanne Roseannadanna
    >
    >BTW, if one doesn't want to save commands in a command file by
    >redirecting the output from a command procedure containing a RECALL
    >command via
    >
    > $ @proc.com/OUT=proc.out ! ,
    >
    >or similar -- okay, fine. But what's wrong with running RECALL/ALL and
    >RECALL from within a command procedure when the output goes to the
    >terminal? I guess the answer to this is the KISS methodology.
    >
    >Thanks to all for your help and suggestions!
    >
    >AEF
    >
    >>
    >> --
    >> George Cornelius cornelius A T eisner D O T decus D O T org

    >[...]
    >> > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    >[...]


    Let me see if I can work up a RECALL edit for you using
    "SYMBOL" and DCL. Can you install other software on the
    system you're using? If I can whip something up using
    SYMBOL, you can use it. It could be done without SYMBOL
    but then you would need to look up varions P1 space DCL
    values manually and put them into the DCL. This will
    also depend upon what can be read from usermode. If an
    address is only SUPERVISOR read, you're SOL from DCL.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  15. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Oct 21, 3:34 pm, VAXman- @SendSpamHere.ORG wrote:
    > In article <789a494a-1fea-4a4d-881e-d9495da8a...@v56g2000hsf.googlegroups.com>, AEF writes:
    > >On Oct 20, 12:21 pm, cornel...@eisner.decus.org (George Cornelius)
    > >wrote:
    > >> In article <00A80651.AB22D...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:

    >
    > >> > You can always write your own recall buffer dump and or recall buffer
    > >> > manipulator for use in your own DCL environment. It's not difficult.

    >
    > >Cool. Of course!

    >
    > >I'm working on it.

    >
    > >> This works:

    >
    > >> $ pipe recall/out=x.lis ; search x.lis sea

    >
    > >I'm running VMS V6.2, so I don't have PIPE. (Please, for those who
    > >haven't heard my spiel on this before: Upgrading is NOT an option. I
    > >have too many systems and no time for it.)

    >
    > >Regardless, it doesn't work (run on DECUServe):

    >
    > >$ RECALL/ALL
    > > 1 TYPE RECA.COM
    > > 2 DIR/SIZE=ALL X.LIS
    > > 3 @RECA
    > > 4 SH DEV DK
    > > 5 SH DEV DS
    > > 6 SH DEF
    > > 7 ED/EDT RECA.COM
    > > 8 ED RECA.COM
    > >$ TYPE RECA.COM
    > >$ pipe recall/out=x.lis ! ; search x.lis sea
    > >$ @RECA
    > >$ DIR/SIZE X.LIS
    > >%DIRECT-W-NOFILES, no files found

    >
    > Two things Alan...
    >
    > Remove the ! if you actually have that in your PIPE command.
    > Secondly, the search command is looking for SEArch... I don't
    > see that command in your RECALL list so obvioulsy, the X.LIS
    > files would be empty.
    >
    > Try:
    >
    > $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED


    $ RECALL/ALL
    1 ED RECA.COM
    $ TYPE RECA.COM
    $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED
    $ @RECA
    %SEARCH-W-OPENIN, error opening EISNER$DRA3:
    [DECUSERVE_USER.FELDMAN]X.LIS; as in
    put
    -RMS-E-FNF, file not found
    %SEARCH-E-NOFILE, no file found
    %NONAME-E-NOMSG, Message number 08D7804A
    $

    It still doesn't work.

    [...]
    > Let me see if I can work up a RECALL edit for you using
    > "SYMBOL" and DCL. Can you install other software on the
    > system you're using? If I can whip something up using


    Perhaps. I'll have to check with the boss.

    > SYMBOL, you can use it. It could be done without SYMBOL
    > but then you would need to look up varions P1 space DCL
    > values manually and put them into the DCL. This will
    > also depend upon what can be read from usermode. If an
    > address is only SUPERVISOR read, you're SOL from DCL.


    So it won't break anything like using DCL params containing quotation
    marks, being able to CONTINUE after ^Y, and such?

    Thanks.

    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    [...]

    AEF

  16. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    In article , AEF writes:
    >On Oct 21, 3:34 pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article <789a494a-1fea-4a4d-881e-d9495da8a...@v56g2000hsf.googlegroups.com>, AEF writes:
    >> >On Oct 20, 12:21 pm, cornel...@eisner.decus.org (George Cornelius)
    >> >wrote:
    >> >> In article <00A80651.AB22D...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:

    >>
    >> >> > You can always write your own recall buffer dump and or recall buffer
    >> >> > manipulator for use in your own DCL environment. It's not difficult.

    >>
    >> >Cool. Of course!

    >>
    >> >I'm working on it.

    >>
    >> >> This works:

    >>
    >> >> $ pipe recall/out=x.lis ; search x.lis sea

    >>
    >> >I'm running VMS V6.2, so I don't have PIPE. (Please, for those who
    >> >haven't heard my spiel on this before: Upgrading is NOT an option. I
    >> >have too many systems and no time for it.)

    >>
    >> >Regardless, it doesn't work (run on DECUServe):

    >>
    >> >$ RECALL/ALL
    >> > 1 TYPE RECA.COM
    >> > 2 DIR/SIZE=ALL X.LIS
    >> > 3 @RECA
    >> > 4 SH DEV DK
    >> > 5 SH DEV DS
    >> > 6 SH DEF
    >> > 7 ED/EDT RECA.COM
    >> > 8 ED RECA.COM
    >> >$ TYPE RECA.COM
    >> >$ pipe recall/out=x.lis ! ; search x.lis sea
    >> >$ @RECA
    >> >$ DIR/SIZE X.LIS
    >> >%DIRECT-W-NOFILES, no files found

    >>
    >> Two things Alan...
    >>
    >> Remove the ! if you actually have that in your PIPE command.
    >> Secondly, the search command is looking for SEArch... I don't
    >> see that command in your RECALL list so obvioulsy, the X.LIS
    >> files would be empty.
    >>
    >> Try:
    >>
    >> $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED

    >
    >$ RECALL/ALL
    > 1 ED RECA.COM
    >$ TYPE RECA.COM
    >$ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED
    >$ @RECA
    >%SEARCH-W-OPENIN, error opening EISNER$DRA3:
    >[DECUSERVE_USER.FELDMAN]X.LIS; as in
    >put
    >-RMS-E-FNF, file not found
    >%SEARCH-E-NOFILE, no file found
    >%NONAME-E-NOMSG, Message number 08D7804A
    >$
    >
    >It still doesn't work.




    Weird:

    EISNER$ $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED
    ed login.com
    ed login.com
    EISNER$ sh def
    DISK_SUPPORT:[DECUSERVE_SUPPORT.SCHENKENBERG]

    >[...]
    >> Let me see if I can work up a RECALL edit for you using
    >> "SYMBOL" and DCL. Can you install other software on the
    >> system you're using? If I can whip something up using

    >
    >Perhaps. I'll have to check with the boss.
    >
    >> SYMBOL, you can use it. It could be done without SYMBOL
    >> but then you would need to look up varions P1 space DCL
    >> values manually and put them into the DCL. This will
    >> also depend upon what can be read from usermode. If an
    >> address is only SUPERVISOR read, you're SOL from DCL.

    >
    >So it won't break anything like using DCL params containing quotation
    >marks, being able to CONTINUE after ^Y, and such?


    Why should it? It would just read what DCL has stored EXACTLY as is
    from the command line to the RECALL buffer.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  17. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    AEF wrote:
    > I've starting working on the DCL code to emulate my own recall buffer.
    > OK. But one cannot run CONTINUE after a control_y: the process goes
    > directly back to the command file. Anyone have any ideas of how to
    > take care of that?
    >


    I wrote a small program called XREAD. It uses SMG to read the command
    line and stores its own recall buffer in a logical. It even supports
    /END_OF_FILE and /ERROR like READ. If you want I can dig up the source.

    Tim.

  18. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Oct 21, 4:45*pm, VAXman- @SendSpamHere.ORG wrote:
    > In article , AEF writes:
    >
    >
    >
    > >On Oct 21, 3:34 pm, VAXman- *@SendSpamHere.ORG wrote:
    > >> In article <789a494a-1fea-4a4d-881e-d9495da8a...@v56g2000hsf.googlegroups.com>, AEF writes:
    > >> >On Oct 20, 12:21 pm, cornel...@eisner.decus.org (George Cornelius)
    > >> >wrote:
    > >> >> In article <00A80651.AB22D...@SendSpamHere.ORG>, * VAXman- *@SendSpamHere.ORG writes:

    >
    > >> >> > You can always write your own recall buffer dump and or recall buffer
    > >> >> > manipulator for use in your own DCL environment. *It's not difficult.

    >
    > >> >Cool. Of course!

    >
    > >> >I'm working on it.

    >
    > >> >> This works:

    >
    > >> >> *$ pipe recall/out=x.lis ; search x.lis sea

    >
    > >> >I'm running VMS V6.2, so I don't have PIPE. (Please, for those who
    > >> >haven't heard my spiel on this before: Upgrading is NOT an option. I
    > >> >have too many systems and no time for it.)

    >
    > >> >Regardless, it doesn't work (run on DECUServe):

    >
    > >> >$ RECALL/ALL
    > >> > *1 TYPE RECA.COM
    > >> > *2 DIR/SIZE=ALL X.LIS
    > >> > *3 @RECA
    > >> > *4 SH DEV DK
    > >> > *5 SH DEV DS
    > >> > *6 SH DEF
    > >> > *7 ED/EDT RECA.COM
    > >> > *8 ED RECA.COM
    > >> >$ TYPE RECA.COM
    > >> >$ pipe recall/out=x.lis ! ; search x.lis sea
    > >> >$ @RECA
    > >> >$ DIR/SIZE X.LIS
    > >> >%DIRECT-W-NOFILES, no files found

    >
    > >> Two things Alan...

    >
    > >> Remove the ! if you actually have that in your PIPE command.
    > >> Secondly, the search command is looking for SEArch... I don't
    > >> see that command in your RECALL list so obvioulsy, the X.LIS
    > >> files would be empty.

    >
    > >> Try:

    >
    > >> $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED

    >
    > >$ RECALL/ALL
    > > *1 ED RECA.COM
    > >$ TYPE RECA.COM
    > >$ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED
    > >$ @RECA
    > >%SEARCH-W-OPENIN, error opening EISNER$DRA3:
    > >[DECUSERVE_USER.FELDMAN]X.LIS; as in
    > >put
    > >-RMS-E-FNF, file not found
    > >%SEARCH-E-NOFILE, no file found
    > >%NONAME-E-NOMSG, Message number 08D7804A
    > >$

    >
    > >It still doesn't work.

    >
    > Weird: *
    >
    > EISNER$ $ PIPE RECALL/OUT=X.LIS ; SEARCH X.LIS ED
    > ed login.com
    > ed login.com
    > EISNER$ sh def
    > * DISK_SUPPORT:[DECUSERVE_SUPPORT.SCHENKENBERG]


    Don't tell anyone, or they'll put me in QA! 8-)

    >
    > >[...]
    > >> Let me see if I can work up a RECALL edit for you using
    > >> "SYMBOL" and DCL. *Can you install other software on the
    > >> system you're using? *If I can whip something up using

    >
    > >Perhaps. I'll have to check with the boss.

    >
    > >> SYMBOL, you can use it. *It could be done without SYMBOL
    > >> but then you would need to look up varions P1 space DCL
    > >> values manually and put them into the DCL. *This will
    > >> also depend upon what can be read from usermode. *If an
    > >> address is only SUPERVISOR read, you're SOL from DCL.

    >
    > >So it won't break anything like using DCL params containing quotation
    > >marks, being able to CONTINUE after ^Y, and such?

    >
    > Why should it? *It would just read what DCL has stored EXACTLY as is
    > from the command line to the RECALL buffer.


    OK.

    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker * * *VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. *Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


    AEF

  19. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    On Oct 21, 10:00*pm, "Tim E. Sneddon" wrote:
    > AEF wrote:
    > > I've starting working on the DCL code to emulate my own recall buffer.
    > > OK. But one cannot run CONTINUE after a control_y: the process goes
    > > directly back to the command file. Anyone have any ideas of how to
    > > take care of that?

    >
    > I wrote a small program called XREAD. It uses SMG to read the command
    > line and stores its own recall buffer in a logical. It even supports
    > /END_OF_FILE and /ERROR like READ. If you want I can dig up the source.
    >
    > Tim.


    What language? All I have is a very old version of PASCAL.

    AEF

  20. Re: Enhancing DCL, was: Re: How do I add 2 letters to a long

    Alan,

    I copied a file to your EISNER account default. It is called:

    GET_COMMAND_LINE_RECALL.COM

    It uses SYMBOL (which is installed on EISNER) and gets the DCL
    command line recall info similar to RECALL/ALL. This procedure
    shows how easy it is to get this using DCL. You can modify the
    procedure to do what you may want in addition to its accessing
    the recall buffer.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.