On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>The whole command-line concept on VMS is fundamentally flawed. Notice that
>>on *nix, the command line is not a single string, it is an array of
>>strings. This makes it easy to pass special characters that might mean
>>something to the shell, simply by bypassing the shell.
>
> Having made the Unix-to-VMS transition in the late eighties, the two things
> I really liked about DCL were the handling of wildcards and the ability to
> use [....] for recursive file paths. I would love to have those two things
> in bash.
>

Things I would like to see from bash in DCL:

Filename globbing.

Tab completion of files/directories with list of matches at each stage.

Ability to edit lines longer than the terminal width.

Easy incremental recall of commands (Ctrl-R in bash).

Synchronised permanent storage of command history across sessions. Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

Things I would like to see in bash on Linux:

Ctrl-T

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/8/2024 9:21 AM, Simon Clubley wrote:
> On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> The whole command-line concept on VMS is fundamentally flawed. Notice that
>>> on *nix, the command line is not a single string, it is an array of
>>> strings. This makes it easy to pass special characters that might mean
>>> something to the shell, simply by bypassing the shell.
>>
>> Having made the Unix-to-VMS transition in the late eighties, the two things
>> I really liked about DCL were the handling of wildcards and the ability to
>> use [....] for recursive file paths. I would love to have those two things
>> in bash.
>
> Things I would like to see from bash in DCL:
>
> Filename globbing.

Backwards compatibility will show its ugly head again.

$ define dcl$enable_globbing true

to enable?

foobar *.xyz *.abc

Foreign command expand to:

foobar 1.xyz 2.xyz 3.abc 4.abc ! 4 arguments

CLD expand to:

foobar 1.xyz,2.xyz 3.abc,4.abc ! 2 arguments

Or?

> Tab completion of files/directories with list of matches at each stage.

Would be very nice indeed and should not break anything.

> Ability to edit lines longer than the terminal width.

Ditto.

Even though I believe we usually get a long story about how DCL
and the terminal driver interacts.

> Easy incremental recall of commands (Ctrl-R in bash).
>
> Synchronised permanent storage of command history across sessions. Supports
> using multiple sessions at the same time and only writes the changes from
> that session to the history file.

I usually just write a COM file if I want to preserve my commands.

But other may like the history you propose.

Arne

On 1/8/2024 9:21 AM, Simon Clubley wrote:
> On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> The whole command-line concept on VMS is fundamentally flawed. Notice that
>>> on *nix, the command line is not a single string, it is an array of
>>> strings. This makes it easy to pass special characters that might mean
>>> something to the shell, simply by bypassing the shell.
>>
>> Having made the Unix-to-VMS transition in the late eighties, the two things
>> I really liked about DCL were the handling of wildcards and the ability to
>> use [....] for recursive file paths. I would love to have those two things
>> in bash.
>>
>
> Things I would like to see from bash in DCL:
>
> Filename globbing.

Don't have a clue what globbing is. Probably don't want to know anyway.

> Tab completion of files/directories with list of matches at each stage.

You're discussing something that might be useful on a personal workstation. Not
something very useful on a server type of system.

> Ability to edit lines longer than the terminal width.

That is a valid bitch. The explanation has been that getting into the terminal
driver is similar to a maze of twisty little passages.

> Easy incremental recall of commands (Ctrl-R in bash).

Not sure what you want Simon? Doesn't RECALL do it? Does for me.

> Synchronised permanent storage of command history across sessions. Supports
> using multiple sessions at the same time and only writes the changes from
> that session to the history file.

Ah, see above about personal workstation ...

> Things I would like to see in bash on Linux:
>
> Ctrl-T

Not a problem, don't use Linux, use VMS ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/8/2024 9:21 AM, Simon Clubley wrote:
> On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> The whole command-line concept on VMS is fundamentally flawed. Notice that
>>> on *nix, the command line is not a single string, it is an array of
>>> strings. This makes it easy to pass special characters that might mean
>>> something to the shell, simply by bypassing the shell.
>>
>> Having made the Unix-to-VMS transition in the late eighties, the two things
>> I really liked about DCL were the handling of wildcards and the ability to
>> use [....] for recursive file paths. I would love to have those two things
>> in bash.
>>
>
> Things I would like to see from bash in DCL:

Ya know Simon, JF once asked for password completion. Not all desires are
reasonable.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/8/2024 10:35 AM, Dave Froble wrote:
> On 1/8/2024 9:21 AM, Simon Clubley wrote:
>> Things I would like to see from bash in DCL:
>>
>> Filename globbing.
>
> Don't have a clue what globbing is.  Probably don't want to know anyway.

Wildcard expansion in the shell not the program.

If you have a VMS Basic program that you run with:

$ mcr []df *.bas

then your Basic program sees one argument with *.bas and can lookup
the matching files with LIB$FIND_FILE or whatever.

If Simons idea get implemented and enabled then your Basic program
would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
the wildcards instead of leaving it to the program.

It is a *nix thing.

>> Tab completion of files/directories with list of matches at each stage.
>
> You're discussing something that might be useful on a personal
> workstation.  Not something very useful on a server type of system.

I think system managers of servers could benefit as well.

Arne

On 08/01/2024 15:51, Arne Vajhøj wrote:
> On 1/8/2024 10:35 AM, Dave Froble wrote:
>> On 1/8/2024 9:21 AM, Simon Clubley wrote:
>>> Things I would like to see from bash in DCL:
>>>
>>> Filename globbing.
>>
>> Don't have a clue what globbing is.  Probably don't want to know anyway.
>
> Wildcard expansion in the shell not the program.
>
> If you have a VMS Basic program that you run with:
>
> $ mcr []df *.bas
>
> then your Basic program sees one argument with *.bas and can lookup
> the matching files with LIB$FIND_FILE or whatever.
>
> If Simons idea get implemented and enabled then your Basic program
> would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
> the wildcards instead of leaving it to the program.
>
> It is a *nix thing.
>
>>> Tab completion of files/directories with list of matches at each stage.
>>
>> You're discussing something that might be useful on a personal
>> workstation.  Not something very useful on a server type of system.
>
> I think system managers of servers could benefit as well.
>
> Arne
>

Problem there is line length limits. I have frequently had that problem
on *nix

--
Chris

On 2024-01-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/8/2024 10:35 AM, Dave Froble wrote:
>> On 1/8/2024 9:21 AM, Simon Clubley wrote:
>>> Things I would like to see from bash in DCL:
>>>
>>> Filename globbing.
>>
>> Don't have a clue what globbing is.  Probably don't want to know anyway.
>
> Wildcard expansion in the shell not the program.
>
> If you have a VMS Basic program that you run with:
>
> $ mcr []df *.bas
>
> then your Basic program sees one argument with *.bas and can lookup
> the matching files with LIB$FIND_FILE or whatever.
>
> If Simons idea get implemented and enabled then your Basic program
> would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
> the wildcards instead of leaving it to the program.
>
> It is a *nix thing.
>

It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

For David's benefit:

https://tldp.org/LDP/abs/html/globbingref.html

DCL doesn't have anything that even begins to compare with that.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/8/2024 1:25 PM, Simon Clubley wrote:
> On 2024-01-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/8/2024 10:35 AM, Dave Froble wrote:
>>> On 1/8/2024 9:21 AM, Simon Clubley wrote:
>>>> Things I would like to see from bash in DCL:
>>>>
>>>> Filename globbing.
>>>
>>> Don't have a clue what globbing is.  Probably don't want to know anyway.
>>
>> Wildcard expansion in the shell not the program.
>>
>> If you have a VMS Basic program that you run with:
>>
>> $ mcr []df *.bas
>>
>> then your Basic program sees one argument with *.bas and can lookup
>> the matching files with LIB$FIND_FILE or whatever.
>>
>> If Simons idea get implemented and enabled then your Basic program
>> would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
>> the wildcards instead of leaving it to the program.
>>
>> It is a *nix thing.
>>
>
> It also has much more powerful pattern matching than DCL offers, which
> is why I would like to see it on VMS.
>
> For David's benefit:
>
> https://tldp.org/LDP/abs/html/globbingref.html
>
> DCL doesn't have anything that even begins to compare with that.

But there are two aspects:
1) VMS *% vs the let us call it "regex like"
2) whether it happens in DCL or inside .EXE/.COM file

The first one is not so hard. There will be some decisions to make
regarding syntax as [] may not be a good choice on VMS. But when
syntax is agreed then I assume that a change to SYS$SEARCH
will make LIB$FIND_FILE and F$SEARCH work.

The second could be a little tricky to implement without
breaking too much.

Arne

On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>> >> Synchronised permanent storage of command history across sessions.
>> Supports
>> using multiple sessions at the same time and only writes the changes from
>> that session to the history file.
>
> I usually just write a COM file if I want to preserve my commands.
>
> But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.

Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

[globbing]

On 2024-01-08 1:33 p.m., Arne Vajhøj wrote:
> But there are two aspects:
[...]
> 2) whether it happens in DCL or inside .EXE/.COM file
>
> [...]
>
> The second could be a little tricky to implement without
> breaking too much.

Does the pipe command glob before passing the command line arguments on?

On 1/8/2024 2:14 PM, mjos_examine wrote:
> [globbing]
> On 2024-01-08 1:33 p.m., Arne Vajhøj wrote:
>> But there are two aspects:
> [...]
>> 2) whether it happens in DCL or inside .EXE/.COM file
>>
>> [...]
>>
>> The second could be a little tricky to implement without
>> breaking too much.
>
> Does the pipe command glob before passing the command line arguments on?

No. But obviously /GLOB could be added to PIPE.

Arne

On 1/8/24 19:02, mjos_examine wrote:
> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>> >> Synchronised permanent storage of command history across sessions.
>>> Supports
>>> using multiple sessions at the same time and only writes the changes
>>> from
>>> that session to the history file.
>>
>> I usually just write a COM file if I want to preserve my commands.
>>
>> But other may like the history you propose.
>
> I have to agree that being able to up-arrow through commands done during
> my last session, whether 5 minutes, or 5 days, or 5 months later, can be
> very useful and convenient.
>
> Couple that with the sister-feature of being able to back-scroll through
> all the terminal output from the last session, and now you are really
> talking useful and convenient.
>
>
>
>

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

Not a problem now, bash, csh and perhaps others. all support command
line recall, with cmdline buffer length a terminal setup parameter.
history (aliased h), shows the whole list, with !<line number>,
selecting and running any item.

Can be a steep learning curve, and easily forgotten without use,
but so much workflow power in the unix shell...

Chris

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>Things I would like to see in bash on Linux:
>
>Ctrl-T

That IS a cool thing, I agree. I remember running BRL Unix on an 11/730,
which I think was 4.1BSD with a lot of additional stuff from the Army
Ballistics Research Lab, and one of the features was a ctrl-T to show
process status. I have no idea how it was implemented and what signal
ugliness was involved, though.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>It also has much more powerful pattern matching than DCL offers, which
>is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.

But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/8/2024 3:19 PM, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>> It also has much more powerful pattern matching than DCL offers, which
>> is why I would like to see it on VMS.
>
> regexps are built into a lot of Unix utilities at fairly low levels and
> this is incredibly powerful.
>
> But I cannot say "mv *.txt *.dat" in order to change every file extension
> in the current working directory. This is the downside.

But DCL is not bash.

I actually think it could work in DCL.

$ SET PROC/GLOB=ON
$ REN *.TXT "*.DAT"

could be interpreted as:

$ REN 1.TXT,2.TXT,3.TXT *.DAT

Arne

In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>On 1/8/24 19:02, mjos_examine wrote:
>> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>>> >> Synchronised permanent storage of command history across sessions.
>>>> Supports
>>>> using multiple sessions at the same time and only writes the changes
>>>> from
>>>> that session to the history file.
>>>
>>> I usually just write a COM file if I want to preserve my commands.
>>>
>>> But other may like the history you propose.
>>
>> I have to agree that being able to up-arrow through commands done during
>> my last session, whether 5 minutes, or 5 days, or 5 months later, can be
>> very useful and convenient.
>>
>> Couple that with the sister-feature of being able to back-scroll through
>> all the terminal output from the last session, and now you are really
>> talking useful and convenient.
>>
>>
>>
>>
>
>One of the most irritating things about working on terminal
>based systems was the lack of command line recall. To be fair
>though, early unix systems with csh or sh lacked that as well.
>Solution here was to select tcsh, which did have command line recall
>capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

tcsh, bash, zsh all had such functionality in the early 1990s,
of course, using both the csh syntax as well as the ability;
tcsh starting in the 80s. ksh (at least 93) might be
configurable to do something similar, but I can't recall now.

>Not a problem now, bash, csh and perhaps others. all support command
>line recall, with cmdline buffer length a terminal setup parameter.
>history (aliased h), shows the whole list, with !<line number>,
>selecting and running any item.
>
>Can be a steep learning curve, and easily forgotten without use,
>but so much workflow power in the unix shell...

Yup.

- Dan C.

In article <unhlca$qpj$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>It also has much more powerful pattern matching than DCL offers, which
>>is why I would like to see it on VMS.
>
>regexps are built into a lot of Unix utilities at fairly low levels and
>this is incredibly powerful.
>
>But I cannot say "mv *.txt *.dat" in order to change every file extension
>in the current working directory. This is the downside.

True, but there are things like http://mcvoy.com/lm/move.shar
that give you such functionality.

People often forget that the globbing functionality in Unix is
entirely internal to the shell (though, in fairness, there are a
couple of userspace libraries that provide essentially the same
thing), and the shell is just another userspace program, so if
one really wanted, one could always replace the shell with
something that did wildcard expansion differently. Of course,
how that would _expand_ in e.g. the `mv` case is another
matter.

- Dan C.

In article <unhl0h$3ca$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>Things I would like to see in bash on Linux:
>>
>>Ctrl-T
>
>That IS a cool thing, I agree. I remember running BRL Unix on an 11/730,
>which I think was 4.1BSD with a lot of additional stuff from the Army
>Ballistics Research Lab, and one of the features was a ctrl-T to show
>process status. I have no idea how it was implemented and what signal
>ugliness was involved, though.

BSD still supports this; SIGINFO is the signal. Of course, it
has to be caught by the program and the program has to elect to
do something intelligent with it, and many do not.

- Dan C.

On 1/8/2024 3:10 PM, chrisq wrote:
> On 1/8/24 19:02, mjos_examine wrote:
>> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>>> >> Synchronised permanent storage of command history across sessions.
>>>> Supports
>>>> using multiple sessions at the same time and only writes the changes
>>>> from
>>>> that session to the history file.
>>>
>>> I usually just write a COM file if I want to preserve my commands.
>>>
>>> But other may like the history you propose.
>>
>> I have to agree that being able to up-arrow through commands done
>> during my last session, whether 5 minutes, or 5 days, or 5 months
>> later, can be very useful and convenient.
>>
>> Couple that with the sister-feature of being able to back-scroll
>> through all the terminal output from the last session, and now you are
>> really talking useful and convenient.
>>
>>
>>
>>
>
> One of the most irritating things about working on terminal
> based systems was the lack of command line recall. To be fair
> though, early unix systems with csh or sh lacked that as well.

csh has terminal command line recall. I use it all the time.
csh is still my favorite shell.

I really thought DCL had it,too. DCL in RSTS/E V10.1L does.

> Solution here was to select tcsh, which did have command line recall
> capability, even back in the early 1990's
>
> Not a problem now, bash, csh and perhaps others. all support command
> line recall, with cmdline buffer length a terminal setup parameter.
> history (aliased h), shows the whole list, with !<line number>,
> selecting and running any item.
>
> Can be a steep learning curve, and easily forgotten without use,
> but so much workflow power in the unix shell...
>

bill

On 1/8/2024 4:14 PM, Dan Cross wrote:
> In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>> On 1/8/24 19:02, mjos_examine wrote:
>>> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>>>>>> Synchronised permanent storage of command history across sessions.
>>>>> Supports
>>>>> using multiple sessions at the same time and only writes the changes
>>>>> from
>>>>> that session to the history file.
>>>>
>>>> I usually just write a COM file if I want to preserve my commands.
>>>>
>>>> But other may like the history you propose.
>>>
>>> I have to agree that being able to up-arrow through commands done during
>>> my last session, whether 5 minutes, or 5 days, or 5 months later, can be
>>> very useful and convenient.
>>>
>>> Couple that with the sister-feature of being able to back-scroll through
>>> all the terminal output from the last session, and now you are really
>>> talking useful and convenient.
>>>
>>>
>>>
>>>
>>
>> One of the most irritating things about working on terminal
>> based systems was the lack of command line recall. To be fair
>> though, early unix systems with csh or sh lacked that as well.
>> Solution here was to select tcsh, which did have command line recall
>> capability, even back in the early 1990's
>
> `csh` certainly had command history, though not "recall" in the
> sense of using an arror key or ^P or something to bring a
> previously executed back back to the prompt for editing. Korn's
> shell had similar functionality, and various people hacked it
> into `sh` at different times.

I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

bill

On 2024-01-08 3:35 p.m., Arne Vajhøj wrote:
> On 1/8/2024 3:19 PM, Scott Dorsey wrote:
>> Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>> It also has much more powerful pattern matching than DCL offers, which
>>> is why I would like to see it on VMS.
>>
>> regexps are built into a lot of Unix utilities at fairly low levels and
>> this is incredibly powerful.
>>
>> But I cannot say "mv *.txt *.dat" in order to change every file extension
>> in the current working directory.  This is the downside.
>
> But DCL is not bash.
>
> I actually think it could work in DCL.
>
> $ SET PROC/GLOB=ON
> $ REN *.TXT "*.DAT"
>
> could be interpreted as:
>
> $ REN 1.TXT,2.TXT,3.TXT *.DAT

In the "spitballing" department, and wanting solutions that don't "break
too much", are the two things outlined below possible today?

$ VMSGLOB -command "[a-c]*" -symbol foo
$! my_ported_unix_program expects globbing to be done already
$ my_ported_unix_program 'foo'

VMSGLOB could carry out glob-style filename expansion in the same manner
as globbing does on UNIX, and store the result (via -symbol arg) in the
symbol specified, possibly with each resulting file name enclosed in
quotations ( if -quoted arg included maybe?).

If you wanted to use the glob results in DCL:

$ VMSGLOB -command "[a-c]*" -symbol foo -delim "|"
$ NUM = 0
$ LOOP:
$ MYFILE = F$ELEMENT(NUM,"|", foo)
$ IF MYFILE .EQS. "|" THEN GOTO DONELOOP
$ DIRECTORY 'MYFILE'
$ NUM = NUM +1
$ GOTO LOOP
$ DONELOOP:

I think that might already be possible today, if you had the VMSGLOB
foreign command to look after the -command arg, -symbol arg, -delim arg,
-quoted.

On a similar note, since DCL already respects the DECK and EOD commands,
example:
$ CREATE FILE.LIS
$ DECK
File data
File data
$ EOD
there could be a VMSBASH foreign command, where you could utilize the
DECK command, like so:
$ VMSBASH
$ DECK
if ! test -f /path/to/file; then
echo "File does not exist."
fi
$ EOD

You could (in theory) place any arbitrary bash script, for
interpretation and execution by a VMSBASH foreign command that expects
to operate in that way, between $DECK and $EOD.

The command preceding the DECK command could function somewhat like the
niche of #!/bin/bash on UNIX for specifying the desired interpreter for
the arbitrary syntax that is between $DECK and $EOD.

In article <l037lbF2supU10@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 1/8/2024 4:14 PM, Dan Cross wrote:
>> In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>>> On 1/8/24 19:02, mjos_examine wrote:
>>>> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>>>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>>>>>>> Synchronised permanent storage of command history across sessions.
>>>>>> Supports
>>>>>> using multiple sessions at the same time and only writes the changes
>>>>>> from
>>>>>> that session to the history file.
>>>>>
>>>>> I usually just write a COM file if I want to preserve my commands.
>>>>>
>>>>> But other may like the history you propose.
>>>>
>>>> I have to agree that being able to up-arrow through commands done during
>>>> my last session, whether 5 minutes, or 5 days, or 5 months later, can be
>>>> very useful and convenient.
>>>>
>>>> Couple that with the sister-feature of being able to back-scroll through
>>>> all the terminal output from the last session, and now you are really
>>>> talking useful and convenient.
>>>>
>>>>
>>>>
>>>>
>>>
>>> One of the most irritating things about working on terminal
>>> based systems was the lack of command line recall. To be fair
>>> though, early unix systems with csh or sh lacked that as well.
>>> Solution here was to select tcsh, which did have command line recall
>>> capability, even back in the early 1990's
>>
>> `csh` certainly had command history, though not "recall" in the
>> sense of using an arror key or ^P or something to bring a
>> previously executed back back to the prompt for editing. Korn's
>> shell had similar functionality, and various people hacked it
>> into `sh` at different times.
>
>I use the arrow keys all the time in csh. Been doing that
>since at least the SunOS days. Don't remember if Ultrix
>even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.

Ultrix had csh.

- Dan C.

In article <unhrqa$6f4$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <l037lbF2supU10@mid.individual.net>,
>bill <bill.gunshannon@gmail.com> wrote:
>>On 1/8/2024 4:14 PM, Dan Cross wrote:
>>> In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>>>> On 1/8/24 19:02, mjos_examine wrote:
>>>>> On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
>>>>>>> On 2024-01-08 9:21 a.m., Simon Clubley wrote:
>>>>>>>>> Synchronised permanent storage of command history across sessions.
>>>>>>> Supports
>>>>>>> using multiple sessions at the same time and only writes the changes
>>>>>>> from
>>>>>>> that session to the history file.
>>>>>>
>>>>>> I usually just write a COM file if I want to preserve my commands.
>>>>>>
>>>>>> But other may like the history you propose.
>>>>>
>>>>> I have to agree that being able to up-arrow through commands done during
>>>>> my last session, whether 5 minutes, or 5 days, or 5 months later, can be
>>>>> very useful and convenient.
>>>>>
>>>>> Couple that with the sister-feature of being able to back-scroll through
>>>>> all the terminal output from the last session, and now you are really
>>>>> talking useful and convenient.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> One of the most irritating things about working on terminal
>>>> based systems was the lack of command line recall. To be fair
>>>> though, early unix systems with csh or sh lacked that as well.
>>>> Solution here was to select tcsh, which did have command line recall
>>>> capability, even back in the early 1990's
>>>
>>> `csh` certainly had command history, though not "recall" in the
>>> sense of using an arror key or ^P or something to bring a
>>> previously executed back back to the prompt for editing. Korn's
>>> shell had similar functionality, and various people hacked it
>>> into `sh` at different times.
>>
>>I use the arrow keys all the time in csh. Been doing that
>>since at least the SunOS days. Don't remember if Ultrix
>>even had csh. Guess I should check.
>
>Unlikely. Tcsh, sure, but not /bin/csh.
>
>Ultrix had csh.

It did, but I installed tcsh off some net repository because it was so
much better.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Mon, 08 Jan 2024 20:19:22 +0000, Scott Dorsey wrote:

> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>It also has much more powerful pattern matching than DCL offers, which
>>is why I would like to see it on VMS.
>
> regexps are built into a lot of Unix utilities at fairly low levels and
> this is incredibly powerful.
>
> But I cannot say "mv *.txt *.dat" in order to change every file
> extension in the current working directory. This is the downside.
> --scott

Agreed. But there is a commonly available utility for that.

In article <unhuo7$2dg$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>In article <unhrqa$6f4$1@reader1.panix.com>,
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>In article <l037lbF2supU10@mid.individual.net>,
>>bill <bill.gunshannon@gmail.com> wrote:
>>>[snip]
>>>I use the arrow keys all the time in csh. Been doing that
>>>since at least the SunOS days. Don't remember if Ultrix
>>>even had csh. Guess I should check.
>>
>>Unlikely. Tcsh, sure, but not /bin/csh.
>>
>>Ultrix had csh.
>
>It did, but I installed tcsh off some net repository because it was so
>much better.

Yeah. Tcsh was more or less requisite on a BSD-ish system for a
long while. At least for interactive use; "program with Bourne,
type with Joy" was a motto back in those days.

I stuck with tcsh for a long while until I started working at
Google. Then, network effects made me switch to Bash. These
days, it's mostly zsh everywhere.

- Dan C.