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 ; Bob Koehler wrote: > In article , clubley@remove_me.eisner.decus.org-Earth.UFP (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 ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 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

    Bob Koehler wrote:
    > In article , clubley@remove_me.eisner.decus.org-Earth.UFP (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.
    >
    >> Tab based filename completion.

    >
    > Yep.
    >
    >> No way to search the help library. (Yes, I know that's not really a bash
    >> function, but on VMS, HELP is considered to be part of DCL.)

    >
    > With hierachical help, searching is not as often needed. I find
    > VMS HELP much easier than man -k when I need to find something and
    > don't know where it is. I keep trying to learn "info" for just
    > that reason.
    >
    >> These don't require a "replace DCL" action, but they are the things that
    >> I find _extremely_ frustrating when switching from a bash shell to a DCL
    >> session.
    >>
    >> However, providing an additional CLI/scripting environment with VMS would
    >> allow the additional types of features seen in other environments, but for
    >> now I would be happy with just the above been added to DCL.

    >
    > DCL on VAXen was pretty well hacked up. Porting it to Alpha was a
    > major piece of work. I think VMS Engineering should freeze DCL for
    > upward compatability and create a new CLI.
    >
    > And please don't base it on cryptic languages like C.
    >


    And please do not base it on cryptic languages like sh, ksh, csh, zsh, etc!

    DCL is, without a doubt, the most user friendly CLI I know of! If I
    want a "shell" I'll use Unix!!


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

    In article , VMS is Virus Free writes:
    >On 24 Sep 2008 08:36:01 -0500,
    >clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
    >
    >>In article <5UeCk.1038$MN3.360@nwrddc01.gnilink.net>, John Santos writes:
    >>>
    >>> Sure wish they would fix this (editing wide lines)!
    >>>

    >>
    >>I've filed multiple formal enhancement requests for this and other DCL
    >>deficiencies over the years.
    >>
    >>I've never even had any clarification back from anyone other than the
    >>support people who logged the requests.
    >>
    >>I personally put things like this into the "will never happen" category.
    >>
    >>I switch between Linux and VMS on a daily basis and DCL is really dated
    >>compared to the capabilities in bash. Yes, I know that there's an older
    >>version of bash available for VMS, but we are talking about the
    >>capabilities of the native CLI environment here, which for VMS is DCL.
    >>
    >>Simon.

    >
    >If you are on Windows, XLNT (http://www.advsyscon.com) is a decent DCL
    >CLI for Windows. If the VMS folks would at least do that much for
    >normal DCL on VMS, it would be a great step forward.


    No it's not!

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

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

    DCL is established. Improvements are quite possible. Guy Peleg, before
    leaving, had done a bunch of welcomed improvements. Where there is a
    will, there is a way. But looking at roadmaps, it is clear that
    intaractive use is not high on the agenda.

    What I'd rather see are improvements to DECterm.

    Notably, a DCL interface/PFkey that would cause a GUI dialogue to pop up
    with the current command in it. You could then use GUI tools to
    cut/past/insert to your hearts contents. And when done, the dialogue
    goes away and the command is executed.

    But that would require DECterm to be changed and I am not sure this is
    possible anymore. Source is probably stored in some inaccessible safe at
    the other end of the globe by now and never touched/seen by anyone. And
    it would also require "Digital" to set some new ANSI escape sequence to
    trigger this popup dialogue and incorporate that into DECterm and in DCL
    (or terminal driver). And since "Digital" doesn't exist anymore, it
    probably is impossible to add new escape sequences to the "standard".

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

    In article , "Richard B. Gilbert" writes:
    >
    > Please remember that DCL IS a Command Line Interpreter and NOT really a
    > programming language! I know it has been used to write applications but
    > it's certainly not the primary purpose. There are certainly better
    > tools available for writing most applications.
    >


    Fine, so they still need to fixup the issues I've mentioned, which are
    all CLI related, instead of scripting related.

    Besides, DCL is a application language, when the applications in question
    are system management applications.

    > If you want to write applications in your CLI, try Solaris or Linux.
    >


    As you already know, :-), I'm looking at the former and using the latter.

    > I think you would probably be happier with COBOL!


    Huh ? (I have _zero_ interest in any language that looks like COBOL).

    Simon.

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

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

    In article , "Richard B. Gilbert" writes:
    >
    > Since the available terminals generally do not support more than 132
    > characters per line, there is little point in supporting command line
    > editing for longer lines!


    I think that you have completely missed the point here. :-)

    The whole idea is that modern CLI environments _do_ edit command lines that
    are longer than the terminal width. The CLI takes care of the issues involved
    in displaying the command over multiple physical terminal lines, jumping the
    cursor between those physical lines, and reflowing text across those
    physical lines when adding/removing characters from the command line.

    This capability is a standard CLI function these days and it's omission from
    DCL, along with the other features like filename completion, makes DCL feel
    very dated.

    Simon.

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

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

    Simon Clubley wrote:
    > In article , "Richard B. Gilbert" writes:
    >> Please remember that DCL IS a Command Line Interpreter and NOT really a
    >> programming language! I know it has been used to write applications but
    >> it's certainly not the primary purpose. There are certainly better
    >> tools available for writing most applications.
    >>

    >
    > Fine, so they still need to fixup the issues I've mentioned, which are
    > all CLI related, instead of scripting related.
    >


    DCL and the terminal driver are behaving as documented. It has been
    this way since I came on board in 1984. I see no need to "fix" what
    isn't broken.

    If you REALLY need to type, and edit, command lines longer than 132
    characters, please feel free to write your own terminal driver, CLI,
    etc. I think you'll find it MUCH easier to put such things in a .COM
    file, edit that file until you get it right and then execute them from
    the file.

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

    In article , clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:
    >In article , "Richard B. Gilbert" writes:
    >>
    >> Since the available terminals generally do not support more than 132
    >> characters per line, there is little point in supporting command line
    >> editing for longer lines!

    >
    >I think that you have completely missed the point here. :-)
    >
    >The whole idea is that modern CLI environments _do_ edit command lines that
    >are longer than the terminal width. The CLI takes care of the issues involved
    >in displaying the command over multiple physical terminal lines, jumping the
    >cursor between those physical lines, and reflowing text across those
    >physical lines when adding/removing characters from the command line.
    >
    >This capability is a standard CLI function these days and it's omission from
    >DCL, along with the other features like filename completion, makes DCL feel
    >very dated.


    Hmmm... a chance to hack!

    I don't think much of this as a problem since I use DECterms and can copy
    a long line and edit it quite easily; however, I can see where this might
    be a problem for those of you still using your venerable VT100s.

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

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

    Simon Clubley wrote:
    > In article , "Richard B. Gilbert" writes:
    >> Since the available terminals generally do not support more than 132
    >> characters per line, there is little point in supporting command line
    >> editing for longer lines!

    >
    > I think that you have completely missed the point here. :-)
    >
    > The whole idea is that modern CLI environments _do_ edit command lines that
    > are longer than the terminal width. The CLI takes care of the issues involved
    > in displaying the command over multiple physical terminal lines, jumping the
    > cursor between those physical lines, and reflowing text across those
    > physical lines when adding/removing characters from the command line.
    >
    > This capability is a standard CLI function these days and it's omission from
    > DCL, along with the other features like filename completion, makes DCL feel
    > very dated.
    >
    > Simon.
    >


    Then why don't you use something more "modern"? I don't type very well
    but I still manage to use Windows, Linux, Solaris, and VMS without too
    much trouble.


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

    On Sep 25, 2:48*pm, "Richard B. Gilbert"
    wrote:
    > Simon Clubley wrote:
    > > In article , "Richard B. Gilbert" writes:
    > >> Please remember that DCL IS a Command Line Interpreter and NOT really a
    > >> programming language! *


    Exactly. It should be just interpretting my command and yet it does
    not know how to when I need a minor correction.

    >I know it has been used to write applications but
    > >> it's certainly not the primary purpose.


    Beg to differ!!

    >*There are certainly better
    > >> tools available for writing most applications.


    Who is talking applications?
    I'm being hindered by this issue using straight simple commands like
    "edit/fdl/nointeractive/analy=xx.fdl_analysis_nodex_20080808/
    output=yy.fdl_tuned yy.fdl_design while cutting and pasting half
    decent self explanatory file specs. Ditto for many a backup, link and
    pipe command.

    > DCL and the terminal driver are behaving as documented.


    And it is broken... as documented

    > *It has been this way since I came on board in 1984.


    Yes, it has been broken for ever and OpenVMS Engineering has been too
    lame to fix it while they still had the resources to do so.

    > *I see no need to "fix" what isn't broken.


    It's broken. It's badly broken. It hurts my ability to work well on
    OpenVMS. It suckz.
    Windows CMD does a better job. HPux does a better job.
    I had a 'notepad' handyn with half command lines to cut & paste from
    to glue together long commands.

    > If you REALLY need to type, and edit, command lines longer than 132
    > characters, please feel free to write your own terminal driver, CLI,


    Bollocks. (sorry, 'been in London for a week :-)

    132+ chars happens all the time. Fess'up!


    > etc. *I think you'll find it MUCH easier to put such things in a .COM
    > file, edit that file until you get it right and then execute them from
    > the file.


    No As much as like command files, temporary command files are no
    solution. IMHO.
    Any half decent 'pipe' command or perl 'one liner' bangs into this
    short sighted restriction.
    The only workaround is to cut and paste snippets of valid command line
    around the bend. Lame!

    And didn't you just yourself a couple replies earlier write it is a
    command interpreter, and "I know it has been used to write
    applications but it's certainly not the primary purpose. "
    Sticking a command into a command file just about makes it into an
    application... imho.

    fwiw,
    Hein.

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

    Hein RMS van den Heuvel wrote:
    > On Sep 25, 2:48 pm, "Richard B. Gilbert"
    > wrote:
    >> Simon Clubley wrote:
    >>> In article , "Richard B. Gilbert" writes:
    >>>> Please remember that DCL IS a Command Line Interpreter and NOT really a
    >>>> programming language!

    >
    > Exactly. It should be just interpretting my command and yet it does
    > not know how to when I need a minor correction.
    >
    >> I know it has been used to write applications but
    >>>> it's certainly not the primary purpose.

    >
    > Beg to differ!!
    >
    >> There are certainly better
    >>>> tools available for writing most applications.

    >
    > Who is talking applications?
    > I'm being hindered by this issue using straight simple commands like
    > "edit/fdl/nointeractive/analy=xx.fdl_analysis_nodex_20080808/
    > output=yy.fdl_tuned yy.fdl_design while cutting and pasting half
    > decent self explanatory file specs. Ditto for many a backup, link and
    > pipe command.
    >
    >> DCL and the terminal driver are behaving as documented.

    >
    > And it is broken... as documented
    >
    >> It has been this way since I came on board in 1984.

    >
    > Yes, it has been broken for ever and OpenVMS Engineering has been too
    > lame to fix it while they still had the resources to do so.
    >
    >> I see no need to "fix" what isn't broken.

    >
    > It's broken. It's badly broken. It hurts my ability to work well on
    > OpenVMS. It suckz.
    > Windows CMD does a better job. HPux does a better job.
    > I had a 'notepad' handyn with half command lines to cut & paste from
    > to glue together long commands.
    >
    >> If you REALLY need to type, and edit, command lines longer than 132
    >> characters, please feel free to write your own terminal driver, CLI,

    >
    > Bollocks. (sorry, 'been in London for a week :-)
    >
    > 132+ chars happens all the time. Fess'up!
    >
    >
    >> etc. I think you'll find it MUCH easier to put such things in a .COM
    >> file, edit that file until you get it right and then execute them from
    >> the file.

    >
    > No As much as like command files, temporary command files are no
    > solution. IMHO.
    > Any half decent 'pipe' command or perl 'one liner' bangs into this
    > short sighted restriction.
    > The only workaround is to cut and paste snippets of valid command line
    > around the bend. Lame!
    >
    > And didn't you just yourself a couple replies earlier write it is a
    > command interpreter, and "I know it has been used to write
    > applications but it's certainly not the primary purpose. "
    > Sticking a command into a command file just about makes it into an
    > application... imho.
    >
    > fwiw,
    > Hein.


    When I encounter (seldom) a command line longer than 132 characters I
    tend to put it in a command file. I have been using and managing VMS
    systems since 1984 without being seriously inconvenienced by the 132
    character maximum line length on most terminals. I have successfully
    resisted the temptation to use the longest possible file names.

    Perhaps I'm a hopeless reactionary but I feel no inclination to push the
    limits until something breaks.

    Putting DCL into a .COM file doesn't make it an "application" in the
    usual sense of that word. It just means that I don't have to remember
    it and retype it each time I need it.

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

    Hein wrote: -

    > Bollocks. (sorry, 'been in London for a week :-)


    Hey, steady on!

    Cheers Richard Maher

    PS. How was it? I bet it was dank, wet, and miserable - yet so alive.

    "Hein RMS van den Heuvel" wrote in message
    news:b037c2f5-033c-483d-b47f-c9c0c7d7a7a6@g17g2000prg.googlegroups.com...
    On Sep 25, 2:48 pm, "Richard B. Gilbert"
    wrote:
    > Simon Clubley wrote:
    > > In article , "Richard B.

    Gilbert" writes:
    > >> Please remember that DCL IS a Command Line Interpreter and NOT really a
    > >> programming language!


    Exactly. It should be just interpretting my command and yet it does
    not know how to when I need a minor correction.

    >I know it has been used to write applications but
    > >> it's certainly not the primary purpose.


    Beg to differ!!

    > There are certainly better
    > >> tools available for writing most applications.


    Who is talking applications?
    I'm being hindered by this issue using straight simple commands like
    "edit/fdl/nointeractive/analy=xx.fdl_analysis_nodex_20080808/
    output=yy.fdl_tuned yy.fdl_design while cutting and pasting half
    decent self explanatory file specs. Ditto for many a backup, link and
    pipe command.

    > DCL and the terminal driver are behaving as documented.


    And it is broken... as documented

    > It has been this way since I came on board in 1984.


    Yes, it has been broken for ever and OpenVMS Engineering has been too
    lame to fix it while they still had the resources to do so.

    > I see no need to "fix" what isn't broken.


    It's broken. It's badly broken. It hurts my ability to work well on
    OpenVMS. It suckz.
    Windows CMD does a better job. HPux does a better job.
    I had a 'notepad' handyn with half command lines to cut & paste from
    to glue together long commands.

    > If you REALLY need to type, and edit, command lines longer than 132
    > characters, please feel free to write your own terminal driver, CLI,


    Bollocks. (sorry, 'been in London for a week :-)

    132+ chars happens all the time. Fess'up!


    > etc. I think you'll find it MUCH easier to put such things in a .COM
    > file, edit that file until you get it right and then execute them from
    > the file.


    No As much as like command files, temporary command files are no
    solution. IMHO.
    Any half decent 'pipe' command or perl 'one liner' bangs into this
    short sighted restriction.
    The only workaround is to cut and paste snippets of valid command line
    around the bend. Lame!

    And didn't you just yourself a couple replies earlier write it is a
    command interpreter, and "I know it has been used to write
    applications but it's certainly not the primary purpose. "
    Sticking a command into a command file just about makes it into an
    application... imho.

    fwiw,
    Hein.



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

    On Sep 24, 4:47*pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article , clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:
    >

    [...]
    >
    > > No way to search the help library. (Yes, I know that's not really a bash
    > > function, but on VMS, HELP is considered to be part of DCL.)

    >
    > * *With hierachical help, searching is not as often needed. *I find
    > * *VMS HELP much easier than man -k when I need to find something and
    > * *don't know where it is. *I keep trying to learn "info" for just
    > * *that reason.


    I actually created a list file using HELP /OUT=HELP.LIS *...! and you
    can search that, but I rarely use it.
    [...]

    AEF

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

    In article , Hein RMS van den Heuvel writes:
    > On Sep 25, 2:48=A0pm, "Richard B. Gilbert"
    > wrote:
    >> Simon Clubley wrote:
    >> > In article , "Richard B. =

    > Gilbert" writes:
    >> >> Please remember that DCL IS a Command Line Interpreter and NOT really =

    > a
    >> >> programming language! =A0

    >
    > Exactly. It should be just interpretting my command and yet it does
    > not know how to when I need a minor correction.
    >
    >>I know it has been used to write applications but
    >> >> it's certainly not the primary purpose.

    >
    > Beg to differ!!
    >
    >>=A0There are certainly better
    >> >> tools available for writing most applications.

    >
    > Who is talking applications?
    > I'm being hindered by this issue using straight simple commands like
    > "edit/fdl/nointeractive/analy=3Dxx.fdl_analysis_nodex_20080808/
    > output=3Dyy.fdl_tuned yy.fdl_design while cutting and pasting half
    > decent self explanatory file specs. Ditto for many a backup, link and
    > pipe command.
    >
    >> DCL and the terminal driver are behaving as documented.

    >
    > And it is broken... as documented
    >
    >> =A0It has been this way since I came on board in 1984.

    >
    > Yes, it has been broken for ever and OpenVMS Engineering has been too
    > lame to fix it while they still had the resources to do so.


    Agreed. I'm not the least bit surprised it was never fixed. Circa
    1987, in front of a large crowd at a DECUS symposium VMS Advanced Q&A
    in Anaheim, VMS Engineering made a commitment to fix a simple bug
    in the terminal driver. A bug which I had SPRed with multiple
    followups. The fix required a simple one line patch to the driver
    (a patch which I made locally to multiple VMS versions).

    The bug remains to this day. A decade or so (believe it or not)
    after the symposium, I received a call from DEC wanting to know if
    I was satisfied with the resolution to my SPR. At that point we
    now longer used the broken feature, and DEC appeared to be happy
    that the issue had been "properly" handled.

    The whole issue wouldn't have been so bad if it hadn't been a day
    one bug in a new feature. A feature which was initially added to
    the driver for us under contract by local DEC software support,
    however I never found out if VMS Engineering added the feature
    independently or based their addition on the local support patches.


    George Cook
    WVNET

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

    On Sep 24, 4:47*pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article , clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:
    >
    > > Automatic retention of command history, including the automatic mergingof
    > > 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.

    Yeah, let me guess: security implications.

    AEF

    [...]

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

    In article <54c74bd9-a1c5-4df0-863f-8a51697371ff@m44g2000hsc.googlegroups.com>, AEF writes:
    > On Sep 24, 4:47=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
    > Koehler) wrote:
    >> In article , clubley@remove_me.eis=

    > ner.decus.org-Earth.UFP (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.

    >>
    >> =A0 =A0Command 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.

    Simon.

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

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

    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:
    >
    > > On Sep 24, 4:47=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
    > > Koehler) wrote:
    > >> In article , clubley@remove_me.eis=

    > > ner.decus.org-Earth.UFP (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.

    >
    > >> =A0 =A0Command 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) ?


    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.

    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?

    I'd also like to be able to use my FILTER command procedure to search
    for strings in the recall buffer.

    I have a command procedure called FILTER.COM with which I can SEARCH
    for strings from command output.

    Example:

    $ FILTER FELDMAN SH SYS
    %FILTER-I, SEARCHing for FELDMAN from $ SH SYS
    000000AB FELDMAN CUR 4 159861 0 00:05:43.49
    309166 662
    $

    FILTER.COM runs the command in P3 thru P8 to and directs its output to
    a temporary file called SYS$SCRATCH:REFILTER.TMP. Then it SEARCHes
    this temporary file for P2 and displays the results. The temporary
    file is left behind so that you can SEARCH it for other strings
    (assuming you want to SEARCH from the same original output, of
    course).

    OK, so what I want to do is use the FILTER procedure with the RECALL
    command.

    For example:

    $ FILTER DIRECTORY RECALL/ALL

    This would find and display all commands in the recall buffer that
    contain DIRECTORY.

    Mutliple sessions don't come into play at all.

    (I am running VMS V6.2, so please don't tell me to use PIPE and please
    don't tell me to upgrade. I have many reasons not to upgrade.)

    What does it mean "that the current command history was loaded at the
    start of the session"? How can there be a current command history for
    a session that hasn't started yet? Oh, perhaps you mean the current
    version of the file that holds all the commands entered in all
    previous sessions since the last time this history file was cleared?
    (I forgot that Unix (or at least some shells) does that.) To me,
    "current command history" means all the commands you've entered in
    your current session (hence the word "current" in "current history").
    You and I have different interpretations of "current", "history", or
    both. I didn't realize that "current history" meant commands that were
    run in the "current" session *and* past sessions. OK.

    > In bash, only the commands entered during that session get appended to the
    > command history file.


    Why would it ever be done any other way? You mean there are shells out
    there, any of which reads one of these "history files" and then
    immediately regurgitates what it just read, appending it to the same
    "history file"? Huh?

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


    What does it mean to "unset the history filename variable"? And how do
    you do that so that it recognizes security-related params on the
    command line?

    This is a VMS newsgroup. Please do not assume such deep knowledge of
    Unix-type stuff.
    >
    > Simon.
    >
    > --
    > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    > Microsoft: Bringing you 1980's technology to a 21st century world


    AEF

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

    In article <5880985a-8e44-45d2-b775-147349648c4a@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.

    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.

    >
    > What does it mean "that the current command history was loaded at the
    > start of the session"? How can there be a current command history for
    > a session that hasn't started yet? Oh, perhaps you mean the current
    > version of the file that holds all the commands entered in all
    > previous sessions since the last time this history file was cleared?
    > (I forgot that Unix (or at least some shells) does that.) To me,
    > "current command history" means all the commands you've entered in
    > your current session (hence the word "current" in "current history").
    > You and I have different interpretations of "current", "history", or
    > both. I didn't realize that "current history" meant commands that were
    > run in the "current" session *and* past sessions. OK.
    >


    That's correct. I'm using current to describe the current set of commands
    that I'm using, which will generally span more than the lifetime of a
    single session. I can have commands that I use all the time easily to hand
    within the buffer (because they are used frequently enough that they are
    never purged from the buffer) and commands from a current project are
    there waiting when I come back to it the next day.

    The size of the command history file has a configurable length, and the
    oldest commands are dropped automatically by bash when new (and recalled)
    commands are appended.

    >> In bash, only the commands entered during that session get appended to the
    >> command history file.

    >
    > Why would it ever be done any other way? You mean there are shells out
    > there, any of which reads one of these "history files" and then
    > immediately regurgitates what it just read, appending it to the same
    > "history file"? Huh?
    >


    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.

    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.

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

    >
    > What does it mean to "unset the history filename variable"? And how do
    > you do that so that it recognizes security-related params on the
    > command line?
    >


    The name of the history file to be appended to at session end is stored in
    an environment variable. If that variable is not defined, then the session's
    commands are not saved.

    unset is the name of a bash command to unset (delete) an environment
    variable. I simply issue the unset command if there's security related
    information that I've used that I don't want to be saved so that none
    of the commands from the current session get appended to the history file.

    Simon.

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

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

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

    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!

    > > What does it mean "that the current command history was loaded at the
    > > start of the session"? How can there be a current command history for
    > > a session that hasn't started yet? Oh, perhaps you mean the current
    > > version of the file that holds all the commands entered in all
    > > previous sessions since the last time this history file was cleared?
    > > (I forgot that Unix (or at least some shells) does that.) To me,
    > > "current command history" means all the commands you've entered in
    > > your current session (hence the word "current" in "current history").
    > > You and I have different interpretations of "current", "history", or
    > > both. I didn't realize that "current history" meant commands that were
    > > run in the "current" session *and* past sessions. OK.

    >
    > That's correct. I'm using current to describe the current set of commands
    > that I'm using, which will generally span more than the lifetime of a
    > single session. I can have commands that I use all the time easily to hand
    > within the buffer (because they are used frequently enough that they are
    > never purged from the buffer) and commands from a current project are
    > there waiting when I come back to it the next day.
    >
    > The size of the command history file has a configurable length, and the
    > oldest commands are dropped automatically by bash when new (and recalled)
    > commands are appended.
    >
    > >> In bash, only the commands entered during that session get appended to the
    > >> command history file.

    >
    > > Why would it ever be done any other way? You mean there are shells out
    > > there, any of which reads one of these "history files" and then
    > > immediately regurgitates what it just read, appending it to the same
    > > "history file"? Huh?

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

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

    Anyway, I never use RECALL/INPUT. In fact, I forgot that it even
    exists! I don't think I've ever wanted to read in an old RECALL
    buffer. And if I want to write a command to disk for future use, I use
    my WC program. Regardless, in this case I simply want to be able to
    use the RECALL command from within a command procedure. This has
    nothing to do with saving the RECALL buffer to be read in for another
    session. I have other purposes in mind. Besides my FILTER example, I'd
    like to have the DCL prompt contain within itself the date and time at
    which it appeared on the screen. This way I can automatically keep
    track of what happened when during a long terminal session. I can do
    this with a command procedure, but then I lose the ability to use the
    RECALL command. (No, no, no, I do *not* want a clock in the prompt; I
    have plenty of other "clocks". I want the equivalent of the MS-DOS
    command "PROMPT $D$T$G$S".)

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

    >
    > > What does it mean to "unset the history filename variable"? And how do
    > > you do that so that it recognizes security-related params on the
    > > command line?

    >
    > The name of the history file to be appended to at session end is stored in
    > an environment variable. If that variable is not defined, then the session's
    > commands are not saved.


    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.

    >
    > unset is the name of a bash command to unset (delete) an environment
    > variable. I simply issue the unset command if there's security related
    > information that I've used that I don't want to be saved so that none
    > of the commands from the current session get appended to the history file.


    Ah, that's what you meant, but not what you wrote last time.

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


    AEF

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

    In article
    , AEF
    writes:

    > (No, no, no, I do *not* want a clock in the prompt; I
    > have plenty of other "clocks". I want the equivalent of the MS-DOS
    > command "PROMPT $D$T$G$S".)


    I'm not familiar with the MS-DOS command. What does it do?


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

    On Sep 28, 9:53 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
    remove CLOTHES to reply) wrote:
    > In article
    > , AEF
    >
    > writes:
    > > (No, no, no, I do *not* want a clock in the prompt; I
    > > have plenty of other "clocks". I want the equivalent of the MS-DOS
    > > command "PROMPT $D$T$G$S".)

    >
    > I'm not familiar with the MS-DOS command. What does it do?


    It does what I said it does (which you omitted in your reply). I
    included it as an example so that we don't go through all the
    misunderstanding that happened the last time I brought this up.
    Everyone thought I wanted a clock in the prompt. NO! I want the time
    in the prompt to be THE TIME AT WHICH THE PROMPT APPEARED ON THE
    SCREEN.

    For example, I want to look at my session and see the following:

    $ SHOW TIME
    28-SEP-2008 14:12:33
    28 14:12:34> SHOW SYS/NET
    OpenVMS V6.2 on node IDS03 28-SEP-2008 14:16:05.20 Uptime 5
    12:47:48
    Pid Process Name State Pri I/O CPU Page
    flts Pages
    0000008E EVL HIB 6 144 0 00:00:00.16
    367 645 N
    00001797 SERVER_002F LEF 6 94 0 00:00:00.36
    848 332 N
    28 14:16:06> SHOW MEM/SLOT
    System Memory Resources on 28-SEP-2008 14:17:42.86

    Slot Usage (slots): Total Free Resident
    Swapped
    Process Entry Slots 70 42
    28 0
    Balance Set Slots 63 37
    26 0
    28 14:17:43> DIRECTORY/SIZE/DATE/OUT=D [*...] ! Return key pressed at
    28 14:19 !
    28 14:22:03> ! Return key pressed here at 28 14:23:32
    28 14:23:32>

    OK, here's the play-by-play:

    At 14:12:33 I ran the SHOW TIME command. It completed at 14:12:34, so
    the immediately succeeding prompt contains that time. Then a few
    minutes later I ran SHOW SYS/NET, which started at 14:16:05.20 and
    completed at 14:06:06. I can tell that by the looking at the DCL
    prompt that appears right after its output. Then a couple of minutes
    later I ran SHOW MEM/SLOT at 14:17:42.86 and the following prompt
    shows when that completed. The about 1 1/2 minutes later, I pressed
    the Return key and I can tell when that happened by looking at the
    resulting prompt.

    *** I can look at this a week later and the times would still be the
    same. These are timestamps, not clocks. ***

    Here's an actual example from an MS-DOS session:

    P:\>PROMPT $D$T$G$S

    2008-09-28 9:41:46.02>
    2008-09-28 9:41:49.49>
    2008-09-28 9:41:50.22>
    2008-09-2810:17:01.81>
    2008-09-2810:17:02.64>
    2008-09-2810:17:03.44> PROMPT $D$S$T$G$S

    2008-09-28 10:17:13.03>
    2008-09-28 10:17:17.73>
    2008-09-28 10:17:18.19>
    2008-09-28 10:17:18.67>
    2008-09-28 10:17:20.17>
    2008-09-28 10:17:20.67> TIME
    The current time is: 10:17:22.80
    Enter the new time:

    2008-09-28 10:17:23.89> DIR ASDFASDF.ASDF
    Volume in drive P is Data
    Volume Serial Number is FE2F-5ED9

    Directory of P:\

    File Not Found

    2008-09-28 10:17:30.72>
    2008-09-28 10:26:35.26>

    Notice that each prompt-time is the time at which the immediately
    preceding command completed. Where no command appears I simply pressed
    Return and the immediately succeeding prompt gives the time that the
    Return "command" completed.

    *** I can look at this a week later and the times would still be the
    same. These are timestamps, not clocks. ***

    OK, this is about as explicit as I can make it!

    AEF

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast