It would be nice to be able to see the output from a DIRECTORY command
optionally sorted by one of largest size, smallest size, oldest date,
newest date, etc.

Likewise, it would be nice to be able to optionally specify the sort
order in which filenames are returned by f$search().

Does anyone agree ?

Simon.

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

On 1/25/2022 2:09 PM, Simon Clubley wrote:
> It would be nice to be able to see the output from a DIRECTORY command
> optionally sorted by one of largest size, smallest size, oldest date,
> newest date, etc.
>
> Likewise, it would be nice to be able to optionally specify the sort
> order in which filenames are returned by f$search().
>
> Does anyone agree ?
>
> Simon.
>

Already wrote it, in Basic. Want a copy?

--
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/25/2022 2:09 PM, Simon Clubley wrote:
> It would be nice to be able to see the output from a DIRECTORY command
> optionally sorted by one of largest size, smallest size, oldest date,
> newest date, etc.

It could be useful occasionally.

But I suspect that it could be some work for VSI to have DIRECTORY
read all and sort instead of just processing one by one.

I would call it a "nice to have" feature not a "must have" feature.

> Likewise, it would be nice to be able to optionally specify the sort
> order in which filenames are returned by f$search().

If you are scripting then just use something else than DCL
that can do what you want.

Python is a rather obvious choice for something like that.

Arne

On 1/25/2022 3:50 PM, Dave Froble wrote:
> On 1/25/2022 2:09 PM, Simon Clubley wrote:
>> It would be nice to be able to see the output from a DIRECTORY command
>> optionally sorted by one of largest size, smallest size, oldest date,
>> newest date, etc.
>>
>> Likewise, it would be nice to be able to optionally specify the sort
>> order in which filenames are returned by f$search().
>>
>> Does anyone agree ?
>
> Already wrote it, in Basic.  Want a copy?

Python code:

from os import listdir, stat
from sys import argv, exit
from time import strftime, localtime

if len(argv) < 4:
print('Usage: python dir.py <dir> <orderby> <order>')
exit(1)
sel = lambda f : f[0]
if argv[2].lower() == 'name':
sel = lambda f : f[0]
if argv[2].lower() == 'size':
sel = lambda f : f[1].st_size
if argv[2].lower() == 'time':
sel = lambda f : f[1].st_mtime
rev = False
if argv[3].lower() == 'asc':
rev = False
if argv[3].lower() == 'desc':
rev = True

allf = [(f,stat(f)) for f in listdir(argv[1])]
allf.sort(reverse=rev, key=sel)
for f in allf:
print('%-32s %10d %s' % (f[0], f[1].st_size, strftime('%d-%b-%Y
%H:%M:%S', localtime(f[1].st_mtime))))

Arne

On 1/25/2022 7:21 PM, Arne Vajhøj wrote:
> On 1/25/2022 3:50 PM, Dave Froble wrote:
>> On 1/25/2022 2:09 PM, Simon Clubley wrote:
>>> It would be nice to be able to see the output from a DIRECTORY command
>>> optionally sorted by one of largest size, smallest size, oldest date,
>>> newest date, etc.
>>>
>>> Likewise, it would be nice to be able to optionally specify the sort
>>> order in which filenames are returned by f$search().
>>>
>>> Does anyone agree ?
>>
>> Already wrote it, in Basic. Want a copy?
>
> Python code:
>
> from os import listdir, stat
> from sys import argv, exit
> from time import strftime, localtime
>
> if len(argv) < 4:
> print('Usage: python dir.py <dir> <orderby> <order>')
> exit(1)
> sel = lambda f : f[0]
> if argv[2].lower() == 'name':
> sel = lambda f : f[0]
> if argv[2].lower() == 'size':
> sel = lambda f : f[1].st_size
> if argv[2].lower() == 'time':
> sel = lambda f : f[1].st_mtime
> rev = False
> if argv[3].lower() == 'asc':
> rev = False
> if argv[3].lower() == 'desc':
> rev = True
>
> allf = [(f,stat(f)) for f in listdir(argv[1])]
> allf.sort(reverse=rev, key=sel)
> for f in allf:
> print('%-32s %10d %s' % (f[0], f[1].st_size, strftime('%d-%b-%Y %H:%M:%S',
> localtime(f[1].st_mtime))))
>
> Arne
>

It was much more fun, and educational, writing it in Basic ...

--
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 Tuesday, 25 January 2022 at 19:09:32 UTC, Simon Clubley wrote:
> It would be nice to be able to see the output from a DIRECTORY command
> optionally sorted by one of largest size, smallest size, oldest date,
> newest date, etc.
>
> Likewise, it would be nice to be able to optionally specify the sort
> order in which filenames are returned by f$search().
>
> Does anyone agree ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

(ignoring f$search for now)

You mean like DIR on RT11 (single user PDP11 OS) has had since the 1990s or thereabouts?

..DIR /SORT:[sort_option]

Sort_options include DATE and SIZE.

You can also include a /REVERSE qualifier to reverse the default sort order.

See e.g. http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf

Somebody must have thought it was worth doing.

Den 2022-01-26 kl. 13:49, skrev John Wallace:
> On Tuesday, 25 January 2022 at 19:09:32 UTC, Simon Clubley wrote:
>> It would be nice to be able to see the output from a DIRECTORY command
>> optionally sorted by one of largest size, smallest size, oldest date,
>> newest date, etc.
>>
>> Likewise, it would be nice to be able to optionally specify the sort
>> order in which filenames are returned by f$search().
>>
>> Does anyone agree ?
>>
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
>
> (ignoring f$search for now)
>
> You mean like DIR on RT11 (single user PDP11 OS) has had since the 1990s or thereabouts?
>
> .DIR /SORT:[sort_option]
>
> Sort_options include DATE and SIZE.
>
> You can also include a /REVERSE qualifier to reverse the default sort order.
>
> See e.g. http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf
>
> Somebody must have thought it was worth doing.
>

Might need a new message:

%DIRECT-E-TOLARGETOSORT, directory to large for SORT qualifier

Since the file names can not be read in any other sorting order
then alphabetical, they need to be read into memory and sorted.

On 1/26/2022 8:20 AM, Jan-Erik Söderholm wrote:
> Den 2022-01-26 kl. 13:49, skrev John Wallace:
>> On Tuesday, 25 January 2022 at 19:09:32 UTC, Simon Clubley wrote:
>>> It would be nice to be able to see the output from a DIRECTORY command
>>> optionally sorted by one of largest size, smallest size, oldest date,
>>> newest date, etc.
>>>
>>> Likewise, it would be nice to be able to optionally specify the sort
>>> order in which filenames are returned by f$search().
>>>
>>> Does anyone agree ?

>> (ignoring f$search for now)
>>
>> You mean like DIR on RT11 (single user PDP11 OS) has had since the
>> 1990s or thereabouts?
>>
>> .DIR /SORT:[sort_option]
>>
>> Sort_options include DATE and SIZE.
>>
>> You can also include a /REVERSE qualifier to reverse the default sort
>> order.
>>
>> See e.g.
>> http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf
>>
>> Somebody must have thought it was worth doing.
>
> Might need a new message:
>
> %DIRECT-E-TOLARGETOSORT, directory to large for SORT qualifier
>
> Since the file names can not be read in any other sorting order
> then alphabetical, they need to be read into memory and sorted.

True, but with modern HW sizes then it would be an extremely
rare case.

1 thousand entries of 256 bytes is only 256 KB.

1 million entries of 256 bytes is "only" 256 MB.

Arne

On 2022-01-26, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>
> You mean like DIR on RT11 (single user PDP11 OS) has had since the 1990s or thereabouts?
>
> .DIR /SORT:[sort_option]
>
> Sort_options include DATE and SIZE.
>
> You can also include a /REVERSE qualifier to reverse the default sort order.
>
> See e.g. http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf
>
> Somebody must have thought it was worth doing.

Interesting. I wasn't aware of that.

Thanks John. (And yes, I agree someone must have thought it was worth
adding that functionality).

Simon.

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

On 2022-01-26, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> Might need a new message:
>
> %DIRECT-E-TOLARGETOSORT, directory to large for SORT qualifier
>
> Since the file names can not be read in any other sorting order
> then alphabetical, they need to be read into memory and sorted.

We are no longer living in the world of 256Kbytes of system memory
and using RM02s for our disk drives. :-)

I do this just fine elsewhere without a problem...

Simon.

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

On 2022-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> True, but with modern HW sizes then it would be an extremely
> rare case.
>
> 1 thousand entries of 256 bytes is only 256 KB.
>
> 1 million entries of 256 bytes is "only" 256 MB.
>

And that's only virtual memory which is needed. You don't even need
that much physical memory to be present to process a gigantic directory.

Simon.

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

Den 2022-01-26 kl. 15:03, skrev Simon Clubley:
> On 2022-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> True, but with modern HW sizes then it would be an extremely
>> rare case.
>>
>> 1 thousand entries of 256 bytes is only 256 KB.
>>
>> 1 million entries of 256 bytes is "only" 256 MB.
>>
>
> And that's only virtual memory which is needed. You don't even need
> that much physical memory to be present to process a gigantic directory.
>
> Simon.
>

How do you process this with reasonable performance if you do not
have the physical memory to store your filenames in and do the sorting?
And what kind of "virtual" memory are you talking about?

On 1/26/2022 8:30 AM, Arne Vajhøj wrote:
> On 1/26/2022 8:20 AM, Jan-Erik Söderholm wrote:
>> Den 2022-01-26 kl. 13:49, skrev John Wallace:
>>> On Tuesday, 25 January 2022 at 19:09:32 UTC, Simon Clubley wrote:
>>>> It would be nice to be able to see the output from a DIRECTORY command
>>>> optionally sorted by one of largest size, smallest size, oldest date,
>>>> newest date, etc.
>>>>
>>>> Likewise, it would be nice to be able to optionally specify the sort
>>>> order in which filenames are returned by f$search().
>>>>
>>>> Does anyone agree ?
>
>>> (ignoring f$search for now)
>>>
>>> You mean like DIR on RT11 (single user PDP11 OS) has had since the
>>> 1990s or thereabouts?
>>>
>>> .DIR /SORT:[sort_option]
>>>
>>> Sort_options include DATE and SIZE.
>>>
>>> You can also include a /REVERSE qualifier to reverse the default sort
>>> order.
>>>
>>> See e.g.
>>> http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf
>>>
>>> Somebody must have thought it was worth doing.
>>
>> Might need a new message:
>>
>> %DIRECT-E-TOLARGETOSORT, directory to large for SORT qualifier
>>
>> Since the file names can not be read in any other sorting order
>> then alphabetical, they need to be read into memory and sorted.
>
> True, but with modern HW sizes then it would be an extremely
> rare case.
>
> 1 thousand entries of 256 bytes is only 256 KB.
>
> 1 million entries of 256 bytes is "only" 256 MB.

There are two different approaches:
- read into a linear data structure and sort that
- read into a tree
but it should not be that different.

Arne

On 2022-01-26, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2022-01-26 kl. 15:03, skrev Simon Clubley:
>> On 2022-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> True, but with modern HW sizes then it would be an extremely
>>> rare case.
>>>
>>> 1 thousand entries of 256 bytes is only 256 KB.
>>>
>>> 1 million entries of 256 bytes is "only" 256 MB.
>>>
>>
>> And that's only virtual memory which is needed. You don't even need
>> that much physical memory to be present to process a gigantic directory.
>>
>
> How do you process this with reasonable performance if you do not
> have the physical memory to store your filenames in and do the sorting?

That depends on the OS paging algorithms and the sorting algorithm in use.

> And what kind of "virtual" memory are you talking about?

Normal process virtual memory. Only a small part of the virtual address
space of an active process needs to be backed by physical memory at any
one time, although ideally most of it would be.

Simon.

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

On 1/26/2022 1:48 PM, Simon Clubley wrote:
> On 2022-01-26, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2022-01-26 kl. 15:03, skrev Simon Clubley:
>>> On 2022-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> True, but with modern HW sizes then it would be an extremely
>>>> rare case.
>>>>
>>>> 1 thousand entries of 256 bytes is only 256 KB.
>>>>
>>>> 1 million entries of 256 bytes is "only" 256 MB.
>>>>
>>>
>>> And that's only virtual memory which is needed. You don't even need
>>> that much physical memory to be present to process a gigantic directory.
>>>
>>
>> How do you process this with reasonable performance if you do not
>> have the physical memory to store your filenames in and do the sorting?
>
> That depends on the OS paging algorithms and the sorting algorithm in use.
>
>> And what kind of "virtual" memory are you talking about?
>
> Normal process virtual memory. Only a small part of the virtual address
> space of an active process needs to be backed by physical memory at any
> one time, although ideally most of it would be.

I don't think DIR causing hard PF's would provide a good UX.

But luckily I don't think it would be necessary.

Arne

Den 2022-01-26 kl. 20:28, skrev Arne Vajhøj:
> On 1/26/2022 1:48 PM, Simon Clubley wrote:
>> On 2022-01-26, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>> Den 2022-01-26 kl. 15:03, skrev Simon Clubley:
>>>> On 2022-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>
>>>>> True, but with modern HW sizes then it would be an extremely
>>>>> rare case.
>>>>>
>>>>> 1 thousand entries of 256 bytes is only 256 KB.
>>>>>
>>>>> 1 million entries of 256 bytes is "only" 256 MB.
>>>>>
>>>>
>>>> And that's only virtual memory which is needed. You don't even need
>>>> that much physical memory to be present to process a gigantic directory.
>>>>
>>>
>>> How do you process this with reasonable performance if you do not
>>> have the physical memory to store your filenames in and do the sorting?
>>
>> That depends on the OS paging algorithms and the sorting algorithm in use.
>>
>>> And what kind of "virtual" memory are you talking about?
>>
>> Normal process virtual memory. Only a small part of the virtual address
>> space of an active process needs to be backed by physical memory at any
>> one time, although ideally most of it would be.
>
> I don't think DIR causing hard PF's would provide a good UX.

That is why I asked what virmem has to do with anything here.

>
> But luckily I don't think it would be necessary.
>

No, probably not. DIR's are usually not that large on VMS.

> Arne
>

> It would be nice to be able to see the output from a DIRECTORY command
> optionally sorted by one of largest size, smallest size, oldest date,
> newest date, etc.

This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
IIRC, there have been modified directory-like program submissions in the past.

Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:
1) Existing DIRECTORY source code from VSI, in whatever language it's written in, and enhance it the way you want, OR
2) Create new program code in C, calling system routines to do the work.

Submit the new code to VSI.

They can either use it as part of their new DIRECTORY baseline, or it can be put into the community source program.

David

Den 2022-01-27 kl. 03:51, skrev dthi...@gmail.com:
>
>> It would be nice to be able to see the output from a DIRECTORY command
>> optionally sorted by one of largest size, smallest size, oldest date,
>> newest date, etc.
>
> This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
> IIRC, there have been modified directory-like program submissions in the past.
>
> Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:

> 1) Existing DIRECTORY source code from VSI,

Is that even possible?

And besides, just as with some other suggested DCL enhancement
just a week or two ago, this might be of use for a very small
part of the users of VMS systems, and enhancing DCL is probably
very low, if at all, on the wish lists of any VSI customer.

The large amount of users of VMS systems and applications
never see any DCL environment.

Must be many way more important things in VMS to enhance...

On 1/26/2022 9:51 PM, dthi...@gmail.com wrote:
>
>> It would be nice to be able to see the output from a DIRECTORY command
>> optionally sorted by one of largest size, smallest size, oldest date,
>> newest date, etc.
>
> This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
> IIRC, there have been modified directory-like program submissions in the past.

Nah, today's users want the vendor to do all the work ...

> Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:
> 1) Existing DIRECTORY source code from VSI, in whatever language it's written in, and enhance it the way you want, OR
> 2) Create new program code in C, calling system routines to do the work.

Why C, when there are better languages?

> Submit the new code to VSI.
>
> They can either use it as part of their new DIRECTORY baseline, or it can be put into the community source program.

I have a subroutine that acquires file information. Limited at this time, but
easily modified to acquire additional information. Such could be a good
beginning to a more general utility. Available to all who ask.

--
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 27/01/2022 08:39, Dave Froble wrote:
> On 1/26/2022 9:51 PM, dthi...@gmail.com wrote:
>>
>>> It would be nice to be able to see the output from a DIRECTORY command
>>> optionally sorted by one of largest size, smallest size, oldest date,
>>> newest date, etc.
>>
>> This sounds like a good opportunity for some community-contributed
>> software (like the old DECUS Library).  :-))
>> IIRC, there have been modified directory-like program submissions in
>> the past.
>
> Nah, today's users want the vendor to do all the work ...
>
>> Write a new program, DIRECTORY2 and a CLD file to do what you'd like
>> the modified DIRECTORY to do, either using:
>>   1) Existing DIRECTORY source code from VSI, in whatever language
>> it's written in, and enhance it the way you want, OR
>>   2) Create new program code in C, calling system routines to do the
>> work.
>
> Why C, when there are better languages?
>
>> Submit the new code to VSI.
>>
>> They can either use it as part of their new DIRECTORY baseline, or it
>> can be put into the community source program.
>
> I have a subroutine that acquires file information.  Limited at this
> time, but easily modified to acquire additional information.  Such could
> be a good beginning to a more general utility.  Available to all who ask.
>
>

I would be interested to look at it

--
Chris

On 1/27/2022 3:39 AM, Dave Froble wrote:
> On 1/26/2022 9:51 PM, dthi...@gmail.com wrote:
>>
>>> It would be nice to be able to see the output from a DIRECTORY command
>>> optionally sorted by one of largest size, smallest size, oldest date,
>>> newest date, etc.
>>
>> This sounds like a good opportunity for some community-contributed
>> software (like the old DECUS Library).  :-))
>> IIRC, there have been modified directory-like program submissions in
>> the past.
>
> Nah, today's users want the vendor to do all the work ...

Not todays users in general.

But sometimes it seems like VMS users do.

>> Write a new program, DIRECTORY2 and a CLD file to do what you'd like
>> the modified DIRECTORY to do, either using:
>>   1) Existing DIRECTORY source code from VSI, in whatever language
>> it's written in, and enhance it the way you want, OR
>>   2) Create new program code in C, calling system routines to do the
>> work.
>
> Why C, when there are better languages?

RMS calls work in any native language.

But most below 40 only know C and/or C++ in that category.

:-(

>> Submit the new code to VSI.
>>
>> They can either use it as part of their new DIRECTORY baseline, or it
>> can be put into the community source program.
>
> I have a subroutine that acquires file information.  Limited at this
> time, but easily modified to acquire additional information.  Such could
> be a good beginning to a more general utility.  Available to all who ask.

For getting info about a file then many languages comes with
functionality for that including C, Python, Java etc..

Arne

On 2022-01-26, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2022-01-26 kl. 20:28, skrev Arne Vajhøj:
>> On 1/26/2022 1:48 PM, Simon Clubley wrote:
>>>
>>> Normal process virtual memory. Only a small part of the virtual address
>>> space of an active process needs to be backed by physical memory at any
>>> one time, although ideally most of it would be.
>>
>> I don't think DIR causing hard PF's would provide a good UX.
>
> That is why I asked what virmem has to do with anything here.
>

I was addressing your comment about needing a new error message
for very large directories when trying to sort them.

That's not needed because what determines whether the sort runs to
completion is the amount of virtual memory available to a process,
not the amount of physical memory, and when you are talking about that,
then it's no different from the issues involved in running any other
program that might consume a lot of memory.

In practice, the directory would have to be a stupid large size for
this to be in any way a constraint.

>>
>> But luckily I don't think it would be necessary.
>>
>
> No, probably not. DIR's are usually not that large on VMS.
>

Agreed. I've sorted large directories on Linux and _never_ had a problem.

Simon.

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

On 2022-01-27, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2022-01-27 kl. 03:51, skrev dthi...@gmail.com:
>>
>>> It would be nice to be able to see the output from a DIRECTORY command
>>> optionally sorted by one of largest size, smallest size, oldest date,
>>> newest date, etc.
>>
>> This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
>> IIRC, there have been modified directory-like program submissions in the past.
>>
>> Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:
>
>> 1) Existing DIRECTORY source code from VSI,
>
> Is that even possible?
>

No.

And even if the answer was yes, then there are also other issues
like access to the regression testing suite VSI uses and copyright
assignment of your code to VSI if they want to use your code
directly within VMS itself.

Simon.

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

In article <ssu8sq$lmu$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-01-27, Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2022-01-27 kl. 03:51, skrev dthi...@gmail.com:
>>>
>>>> It would be nice to be able to see the output from a DIRECTORY command
>>>> optionally sorted by one of largest size, smallest size, oldest date,
>>>> newest date, etc.
>>>
>>> This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
>>> IIRC, there have been modified directory-like program submissions in the past.
>>>
>>> Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:
>>
>>> 1) Existing DIRECTORY source code from VSI,
>>
>> Is that even possible?
>>
>
>No.
>
>And even if the answer was yes, then there are also other issues
>like access to the regression testing suite VSI uses and copyright
>assignment of your code to VSI if they want to use your code
>directly within VMS itself.

Seeing as how you're such a proponent of 'ix', where one doesn't go to the
toilet without a pipe, why not this?

$ PIPE DIRECTORY/SIZE/WIDTH=(FILENAME:60) | SORT/KEY=(POSITION:60,SIZE=12) SYS$PIPE SYS$OUTPUT

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

I speak to machines with the voice of humanity.

On Thursday, January 27, 2022 at 3:39:38 AM UTC-5, Dave Froble wrote:
> On 1/26/2022 9:51 PM, dthi...@gmail.com wrote:
> >
> >> It would be nice to be able to see the output from a DIRECTORY command
> >> optionally sorted by one of largest size, smallest size, oldest date,
> >> newest date, etc.
> >
> > This sounds like a good opportunity for some community-contributed software (like the old DECUS Library). :-))
> > IIRC, there have been modified directory-like program submissions in the past.
> Nah, today's users want the vendor to do all the work ...
> > Write a new program, DIRECTORY2 and a CLD file to do what you'd like the modified DIRECTORY to do, either using:
> > 1) Existing DIRECTORY source code from VSI, in whatever language it's written in, and enhance it the way you want, OR
> > 2) Create new program code in C, calling system routines to do the work..
> Why C, when there are better languages?

If you are about to use the B-word, better is relative. And if there was such an important tool in BASIC, would have needed Macro, C, BLISS AND BASIC compilers (and their nightmare RTLs) in the development path. I don't want another critical, proprietary tool in the system.