On 7/14/23 6:36 PM, Chris Townley wrote:
> On 14/07/2023 22:30, gah4 wrote:

>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>> tail -f works.  I don't know if tail -f is supposed to work on VMS,
>> though.
>>
>> The main target is embedded Linux, especially where the whole system
>> is in flash memory.
>
> But type/tail does ISTR

On most of the interesting cases it fails with invalid file organization.

On 7/14/2023 9:48 PM, Craig A. Berry wrote:
>
> On 7/14/23 6:36 PM, Chris Townley wrote:
>> On 14/07/2023 22:30, gah4 wrote:
>
>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>>>
>>> The main target is embedded Linux, especially where the whole system
>>> is in flash memory.
>>
>> But type/tail does ISTR
>
> On most of the interesting cases it fails with invalid file organization.
>

Works very well here. Of course, I don't use invalid file organizations.

:-)

--
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 Friday, July 14, 2023 at 3:14:23 PM UTC-7, Craig A. Berry wrote:
> bash has some builtins but other things as separate executables. It
> sounds like busybox just has everything as a builtin.

As well as I know it, in the usual case all those are symlinks.
The normal sh built-ins will still be built-in, and the others will use
the link, and run another busybox.

That works well for systems that can keep one copy in memory,
but run it more than once using that copy. And you can replace
the symlink with an actual program, or symlink to something else.

The standalone_shell configure option, not the default, has it check
for busybox applets that are not normally shell built-ins, before checking
the path. Especially convenient if there are no other files to run.

On 15/07/2023 02:33, gah4 wrote:
> On Friday, July 14, 2023 at 4:36:41 PM UTC-7, Chris Townley wrote:
>
> (snip, I wrote)
>
>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>
> tail -f reads the end of a file, then waits and checks to see if it got bigger.
> That is, if the EOF went away.
>
> Not all file system, I suspect, can do that.
>

Sorry, I should have said TYPE/TAIL/CONTINUOUS which works with some
caveats on the file

--
Chris

On 7/14/23 9:58 PM, Dave Froble wrote:
> On 7/14/2023 9:48 PM, Craig A. Berry wrote:
>>
>> On 7/14/23 6:36 PM, Chris Townley wrote:
>>> On 14/07/2023 22:30, gah4 wrote:
>>
>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>> tail -f works.  I don't know if tail -f is supposed to work on VMS,
>>>> though.
>>>>
>>>> The main target is embedded Linux, especially where the whole system
>>>> is in flash memory.
>>>
>>> But type/tail does ISTR
>>
>> On most of the interesting cases it fails with invalid file organization.
>>
>
> Works very well here.  Of course, I don't use invalid file organizations.
>
> :-)
>

I don't either, but the job controller does, and log files from batch
jobs are about the only reason I would use this feature. If memory
serves this is a well-known problem and somebody (maybe Hein?) had a fix
in the works that never got prioritized.

$ type/tail somelogfile.log
%TYPE-W-OPENIN, error opening DSA0:[SOMEUSER]somelogfile.log;1 as input
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
-RMS-F-ORG, invalid file organization value
$ dir/full somelogfile.log

Directory DSA0:[SOMEUSER]

somelogfile.log;1 File ID: (9158,13,0)
Size: 900/912 Owner: [SOMEGROUP,SOMEUSER]
Created: 15-JUL-2023 08:23:51.37
Modified: 15-JUL-2023 08:23:51.41 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 15-JUL-2023 08:23:51.37
Attr Mod: 15-JUL-2023 08:23:51.41
Data Mod: 15-JUL-2023 08:23:51.37
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 912, Extend: 0, Global buffer count: 0,
No version limit
Record format: VFC, 2 byte header, maximum 0 bytes, longest 1024 bytes
Record attributes: Print file carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 900/912 blocks.

Den 2023-07-15 kl. 15:32, skrev Craig A. Berry:
>
> On 7/14/23 9:58 PM, Dave Froble wrote:
>> On 7/14/2023 9:48 PM, Craig A. Berry wrote:
>>>
>>> On 7/14/23 6:36 PM, Chris Townley wrote:
>>>> On 14/07/2023 22:30, gah4 wrote:
>>>
>>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>>> tail -f works.  I don't know if tail -f is supposed to work on VMS,
>>>>> though.
>>>>>
>>>>> The main target is embedded Linux, especially where the whole system
>>>>> is in flash memory.
>>>>
>>>> But type/tail does ISTR
>>>
>>> On most of the interesting cases it fails with invalid file organization.
>>>
>>
>> Works very well here.  Of course, I don't use invalid file organizations.
>>
>> :-)
>>
>
> I don't either, but the job controller does, and log files from batch
> jobs are about the only reason I would use this feature. If memory
> serves this is a well-known problem and somebody (maybe Hein?) had a fix
> in the works that never got prioritized.
>
> $ type/tail somelogfile.log
> %TYPE-W-OPENIN, error opening DSA0:[SOMEUSER]somelogfile.log;1 as input
> -SYSTEM-E-UNSUPPORTED, unsupported operation or function
> -RMS-F-ORG, invalid file organization value
> $ dir/full somelogfile.log
>
> Directory DSA0:[SOMEUSER]
>
> somelogfile.log;1             File ID:  (9158,13,0)
> Size:          900/912        Owner:    [SOMEGROUP,SOMEUSER]
> Created:    15-JUL-2023 08:23:51.37
> Modified:   15-JUL-2023 08:23:51.41 (1)
> Expires:    <None specified>
> Backup:     <No backup recorded>
> Effective:  <None specified>
> Recording:  <None specified>
> Accessed:   15-JUL-2023 08:23:51.37
> Attr Mod:   15-JUL-2023 08:23:51.41
> Data Mod:   15-JUL-2023 08:23:51.37
> Linkcount:  1
> File organization:  Sequential
> Shelved state:      Online
> Caching attribute:  Writethrough
> File attributes:    Allocation: 912, Extend: 0, Global buffer count: 0, No
> version limit
> Record format:      VFC, 2 byte header, maximum 0 bytes, longest 1024 bytes
> Record attributes:  Print file carriage control
> RMS attributes:     None
> Journaling enabled: None
> File protection:    System:RWED, Owner:RWED, Group:RE, World:
> Access Cntrl List:  None
> Client attributes:  None
>
> Total of 1 file, 900/912 blocks.

As I have understood this (veruy annoying) thing is that
the file org is not "invalid" as such, it is just not
supported by type/tail...

On 2023-07-14 14:55, Arne Vajhøj wrote:
> On 7/13/2023 9:25 AM, bill wrote:
>> On 7/13/2023 1:50 AM, gah4 wrote:
>>> On Wednesday, July 12, 2023 at 3:46:45 PM UTC-7, Steven Schweda wrote:
>>>>> [...] For example, gzip, gunzip, zcat, and gzcat, are all the
>>>>> same file, but do different things based on argv[0].
>>>> Common in the past, but the GNU folks decided against that scheme
>>>> some time ago. (At least a dozen years?)
>
>>> A MacBook Air with OS 10.12.6 has two different files, not linked,
>>> but with exactly the same contents.
>>>
>>> ls -li compress uncompress
>>> 421074 -rwxr-xr-x  1 root  wheel  27680 Jul 14  2017 compress
>>> 421907 -rwxr-xr-x  1 root  wheel  27680 Jul 14  2017 uncompress
>>> and cmp -l shows that they are the same.
>>>
>>> FreeBSD does use the hard links, and also Linux.
>>> The Linux system is 13 years old, so doesn't disagree with your dozen
>>> years.
>>
>> Which is yet another example of "throw more hardware at the problem".
>> A link would save the space, but who cares.
>
> We can discuss the optimal choice between:
> * paying more dollars to get bigger disk
> * the complexity of programs with multiple behavior depending on name
>
> But I don't think that is the case here. I think the case is that
> the cheapest disk you can buy for new systems are so big that there
> is enough space, so no money is saved by adding the complexity of
> multiple behaviors.

I think you missed the point.

In this case, the program does deal with the different behaviors
depending on under which name it is invoked. It's identical binaries.

The issue is just that you could have had just one copy of the program,
but they installed two. For absolutely zero difference except they use
up more disk space.

Johnny

On 2023-07-15 00:14, Craig A. Berry wrote:
>
> On 7/14/23 4:07 PM, Arne Vajhøj wrote:
>> (separate executables should run under DCL, but I believe
>> some of these are shell internal commands)
>
> bash has some builtins but other things as separate executables.  It
> sounds like busybox just has everything as a builtin.

Yes. That is the whole point of busybox. It's just one binary, that have
all commands as built-in. Meaning you are not depending on other
programs first of all being installed, and second, not be corrupted,
third, not being dependent on some dynamic library that you might have.

Busybox is usually involved when you have some embedded system, or for
the recovery tools in case your system has been corrupted or messed up,
so that you can get back to a good state.

Johnny

On 2023-07-15 03:33, gah4 wrote:
> On Friday, July 14, 2023 at 4:36:41 PM UTC-7, Chris Townley wrote:
>
> (snip, I wrote)
>
>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>
> tail -f reads the end of a file, then waits and checks to see if it got bigger.
> That is, if the EOF went away.
>
> Not all file system, I suspect, can do that.

I have a hard time imagining any file system that could not. Such a file
system would then also not be able to append to an existing file.

Johnny

On 2023-07-15 16:04, Jan-Erik Söderholm wrote:
> Den 2023-07-15 kl. 15:32, skrev Craig A. Berry:
>>
>> On 7/14/23 9:58 PM, Dave Froble wrote:
>>> On 7/14/2023 9:48 PM, Craig A. Berry wrote:
>>>>
>>>> On 7/14/23 6:36 PM, Chris Townley wrote:
>>>>> On 14/07/2023 22:30, gah4 wrote:
>>>>
>>>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>>>> tail -f works.  I don't know if tail -f is supposed to work on
>>>>>> VMS, though.
>>>>>>
>>>>>> The main target is embedded Linux, especially where the whole system
>>>>>> is in flash memory.
>>>>>
>>>>> But type/tail does ISTR
>>>>
>>>> On most of the interesting cases it fails with invalid file
>>>> organization.
>>>>
>>>
>>> Works very well here.  Of course, I don't use invalid file
>>> organizations.
>>>
>>> :-)
>>>
>>
>> I don't either, but the job controller does, and log files from batch
>> jobs are about the only reason I would use this feature. If memory
>> serves this is a well-known problem and somebody (maybe Hein?) had a fix
>> in the works that never got prioritized.
>>
>> $ type/tail somelogfile.log
>> %TYPE-W-OPENIN, error opening DSA0:[SOMEUSER]somelogfile.log;1 as input
>> -SYSTEM-E-UNSUPPORTED, unsupported operation or function
>> -RMS-F-ORG, invalid file organization value
>> $ dir/full somelogfile.log
>>
>> Directory DSA0:[SOMEUSER]
>>
>> somelogfile.log;1             File ID:  (9158,13,0)
>> Size:          900/912        Owner:    [SOMEGROUP,SOMEUSER]
>> Created:    15-JUL-2023 08:23:51.37
>> Modified:   15-JUL-2023 08:23:51.41 (1)
>> Expires:    <None specified>
>> Backup:     <No backup recorded>
>> Effective:  <None specified>
>> Recording:  <None specified>
>> Accessed:   15-JUL-2023 08:23:51.37
>> Attr Mod:   15-JUL-2023 08:23:51.41
>> Data Mod:   15-JUL-2023 08:23:51.37
>> Linkcount:  1
>> File organization:  Sequential
>> Shelved state:      Online
>> Caching attribute:  Writethrough
>> File attributes:    Allocation: 912, Extend: 0, Global buffer count:
>> 0, No version limit
>> Record format:      VFC, 2 byte header, maximum 0 bytes, longest 1024
>> bytes
>> Record attributes:  Print file carriage control
>> RMS attributes:     None
>> Journaling enabled: None
>> File protection:    System:RWED, Owner:RWED, Group:RE, World:
>> Access Cntrl List:  None
>> Client attributes:  None
>>
>> Total of 1 file, 900/912 blocks.
>
>
> As I have understood this (veruy annoying) thing is that
> the file org is not "invalid" as such, it is just not
> supported by type/tail...

Right.

And the secondary problem being that it's a little tricky to find the
last n lines in such a file organization. You'll have to do some
heuristics, and hope you got it right. But that usually is possible to
do with a high chance of success. So it could definitely be done. (I
have such a tool for RSX...)

Johnny

On Saturday, July 15, 2023 at 7:44:36 AM UTC-7, Johnny Billquist wrote:
> On 2023-07-15 03:33, gah4 wrote:

(snip)

> > tail -f reads the end of a file, then waits and checks to see if it got bigger.
> > That is, if the EOF went away.
> > Not all file system, I suspect, can do that.

> I have a hard time imagining any file system that could not. Such a file
> system would then also not be able to append to an existing file.

I suspect all could do it if you close, and reopen the file.

But the Unix ones do it without close/open, and then I found that
also worked on OS/2.

On 2023-07-15 19:41, gah4 wrote:
> On Saturday, July 15, 2023 at 7:44:36 AM UTC-7, Johnny Billquist wrote:
>> On 2023-07-15 03:33, gah4 wrote:
>
> (snip)
>
>>> tail -f reads the end of a file, then waits and checks to see if it got bigger.
>>> That is, if the EOF went away.
>
>>> Not all file system, I suspect, can do that.
>
>> I have a hard time imagining any file system that could not. Such a file
>> system would then also not be able to append to an existing file.
>
> I suspect all could do it if you close, and reopen the file.
>
> But the Unix ones do it without close/open, and then I found that
> also worked on OS/2.

Also works on RSX, which basically also means any VMS system/filesystem
shouldn't be a problem.

In general, I'm still of the opinion that any system I can image would
be capable. Opening a file for append do mean that you need to be able
to find where the end of the file is, and seek to there, unless you have
a very specific "open for append" system call.
Otherwise any system would basically open a file for append by opening
it for writing, finding where the eof is, and seek there. Then you could
start writing.

And if you had such a special function, there is still the question of
how seeks then work. If you don't have a seek at all, then sure, you
might not be able to do a tail -f either. But otherwise, what happens if
you seek to beyond eof and try to read? And what if you seek to eof that
you found before, and just try reading again? If someone have added more
to the file, it either would just give eof error, in case the local
program cached where eof is, and just checked against that, or else it
would try to do a read, and then it would get the new data, right?

And if you cache the eof, there is no reason why you could not get it
updated.

But even if you don't have a seek function, the question is what happens
when you reach eof. Reading would return eof error, obviously. And I
would think it would also be true no matter how many times you try.
And then comes the question, what happens if someone did append to the
file in between?

With RSX (and I assume VMS), the eof point is sortof cached, but an
attempt to read beyond it is perfectly possible, and will succeed/fail
based on the actual file content.

Johnny

On 7/15/2023 9:32 AM, Craig A. Berry wrote:
>
> On 7/14/23 9:58 PM, Dave Froble wrote:
>> On 7/14/2023 9:48 PM, Craig A. Berry wrote:
>>>
>>> On 7/14/23 6:36 PM, Chris Townley wrote:
>>>> On 14/07/2023 22:30, gah4 wrote:
>>>
>>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>>>>>
>>>>> The main target is embedded Linux, especially where the whole system
>>>>> is in flash memory.
>>>>
>>>> But type/tail does ISTR
>>>
>>> On most of the interesting cases it fails with invalid file organization.
>>>
>>
>> Works very well here. Of course, I don't use invalid file organizations.
>>
>> :-)
>>
>
> I don't either, but the job controller does, and log files from batch
> jobs are about the only reason I would use this feature. If memory
> serves this is a well-known problem and somebody (maybe Hein?) had a fix
> in the works that never got prioritized.
>
> $ type/tail somelogfile.log
> %TYPE-W-OPENIN, error opening DSA0:[SOMEUSER]somelogfile.log;1 as input
> -SYSTEM-E-UNSUPPORTED, unsupported operation or function
> -RMS-F-ORG, invalid file organization value
> $ dir/full somelogfile.log
>
> Directory DSA0:[SOMEUSER]
>
> somelogfile.log;1 File ID: (9158,13,0)
> Size: 900/912 Owner: [SOMEGROUP,SOMEUSER]
> Created: 15-JUL-2023 08:23:51.37
> Modified: 15-JUL-2023 08:23:51.41 (1)
> Expires: <None specified>
> Backup: <No backup recorded>
> Effective: <None specified>
> Recording: <None specified>
> Accessed: 15-JUL-2023 08:23:51.37
> Attr Mod: 15-JUL-2023 08:23:51.41
> Data Mod: 15-JUL-2023 08:23:51.37
> Linkcount: 1
> File organization: Sequential
> Shelved state: Online
> Caching attribute: Writethrough
> File attributes: Allocation: 912, Extend: 0, Global buffer count: 0, No
> version limit
> Record format: VFC, 2 byte header, maximum 0 bytes, longest 1024 bytes
> Record attributes: Print file carriage control
> RMS attributes: None
> Journaling enabled: None
> File protection: System:RWED, Owner:RWED, Group:RE, World:
> Access Cntrl List: None
> Client attributes: None
>
> Total of 1 file, 900/912 blocks.

OpenVMS V7.2 on node DFE90A 15-JUL-2023 18:34:41.36 Uptime 299 05:59:05

$ t/tail netserver.log

Connect request received at 25-OCT-2022 22:09:58.00
from remote process AS800::"0=DFE"
for object "SYS$COMMON:[SYSEXE]FAL.EXE"

--------------------------------------------------------

--------------------------------------------------------

Connect request received at 25-OCT-2022 22:11:51.99
from remote process AS800::"0=DFE"
for object "SYS$COMMON:[SYSEXE]FAL.EXE"

--------------------------------------------------------

DFE job terminated at 25-OCT-2022 22:16:53.76

Accounting information:
Buffered I/O count: 15046 Peak working set size: 490
Direct I/O count: 1867 Peak page file size: 4051
Page faults: 1499 Mounted volumes: 0
Charged CPU time: 0 00:00:17.85 Elapsed time: 0 00:07:49.56
$

NETSERVER.LOG;12 File ID: (4619,103,0)
Size: 4/4 Owner: [DFE]
Created: 25-OCT-2022 22:09:04.26
Revised: 25-OCT-2022 22:16:53.84 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 4, Extend: 0, Global buffer count: 0
No version limit
Record format: VFC, 2 byte header, maximum 0 bytes, longest 80 bytes
Record attributes: Print file carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Ok, my test was on a VAX, but I doubt that has any bearing. Don't have a clue.
Unless you're trying to read the file while it's still open. That doesn't work.

--
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 Saturday, July 15, 2023 at 6:43:21 PM UTC-4, Dave Froble wrote:
> Unless you're trying to read the file while it's still open. That doesn't work.

That's kind of the whole point of 'tail -f' 8-}

I suspect all of the pieces are there, but nobody has put them together in
a single utility. For example, $ BACKUP/IGNORE=INTERLOCK doesn't care
if files are open or not. Years ago, I taught VMS C-Kermit about all of the
various permutations of RMS file structure, including a few well-known
cases of intentionally using undefined file types (True BASIC was one of
the offenders). It had to convert every possible file type to either canonical
ASCII, fixed-block binary, or a special format called "labeled"* (which was
invented by fdc and myself just to deal with VMS's myriad file types). The
only issue would seem to be that the tail program won't see a change in
EOF on slowly-growing files until the creating process either has a buffer
flush or closes the file, so the output might be bursty. But that's true on
Unix as well.

* Our test for this was to send a multi-key indexed file with RMS journaling
from VMS to TOPS-20 to a PC to IBM 370 VM/CMS and back to VMS and
having it arrive intact, complete with journal info.

On 7/16/2023 5:25 AM, terry-...@glaver.org wrote:
> On Saturday, July 15, 2023 at 6:43:21 PM UTC-4, Dave Froble wrote:
>> Unless you're trying to read the file while it's still open. That doesn't work.
>
> That's kind of the whole point of 'tail -f' 8-}

RSTS had/has an open mode with "read regardless" as an option. This can also
be done on VMS. But if a utility on VMS doesn't use such a capability, then it
won't happen.

Perhaps the design of the utility figures that since reading only what is on
disk doesn't see anything not yet written, that it's worthless to try.

I've implemented logging in various programs to flush writes to disk
immediately, since I'd usually want to see up to date logging on a current
running program.

It's the design of a utility and user programs that defines whether a capability
is implemented.

--
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 7/15/2023 10:47 AM, Johnny Billquist wrote:
> And the secondary problem being that it's a little tricky to find the
> last n lines in such a file organization. You'll have to do some
> heuristics, and hope you got it right. But that usually is possible to
> do with a high chance of success. So it could definitely be done. (I
> have such a tool for RSX...)

It depends on the record format.

VAR,VFC => read from start or make a good guess
FIX, STM, STMLF, STMCR => no problem
UDF => "last n lines" is not defined

Arne

On 7/15/2023 10:39 AM, Johnny Billquist wrote:
> On 2023-07-14 14:55, Arne Vajhøj wrote:
>> On 7/13/2023 9:25 AM, bill wrote:
>>> Which is yet another example of "throw more hardware at the problem".
>>> A link would save the space, but who cares.
>>
>> We can discuss the optimal choice between:
>> * paying more dollars to get bigger disk
>> * the complexity of programs with multiple behavior depending on name
>>
>> But I don't think that is the case here. I think the case is that
>> the cheapest disk you can buy for new systems are so big that there
>> is enough space, so no money is saved by adding the complexity of
>> multiple behaviors.
>
> I think you missed the point.
>
> In this case, the program does deal with the different behaviors
> depending on under which name it is invoked. It's identical binaries.

I got that.

> The issue is just that you could have had just one copy of the program,
> but they installed two. For absolutely zero difference except they use
> up more disk space.

The two cost are hardware and peoples time.

With todays TB disks it is very unlikely that having two copies of some
executables will require buying bigger and more expensive disk(s).

Having developer support the name test logic on multiple platforms
and having sys admins needing to worry about linked stuff
when they clean up is a very small effort but still an
effort greater than zero.

Arne

On 7/16/2023 2:28 PM, Arne Vajhøj wrote:
> The two cost are hardware and peoples time.
>
> With todays TB disks it is very unlikely that having two copies of some
> executables will require buying bigger and more expensive disk(s).
>
> Having developer support the name test logic on multiple platforms
> and having sys admins needing to worry about linked stuff
> when they clean up is a very small effort but still an
> effort greater than zero.

And just to make sure we are talking about the same.

VMS example:

$ type a.c
#include <stdio.h>

int main(int argc, char *argv[])
{ printf("I am A\n");
return 0;
} $ cc a
$ link a
$ type b.c
#include <stdio.h>

int main(int argc, char *argv[])
{ printf("I am B\n");
return 0;
} $ cc b
$ link b
$ run a
I am A
$ run b
I am B

$ del a.exe;*, b.exe;*
$ type ab.c
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{ if(strstr(argv[0], "]a.exe;") != NULL)
{
printf("I am A\n");
}
if(strstr(argv[0], "]b.exe;") != NULL)
{
printf("I am B\n");
}
return 0;
} $ cc ab
$ link ab
$ set file/enter=a.exe ab.exe
$ set file/enter=b.exe ab.exe
$ run a
I am A
$ run b
I am B
$ set file/remove a.exe;1
$ set file/remove b.exe;1

Arne

On Sunday, July 16, 2023 at 11:30:26 AM UTC-7, Arne Vajhøj wrote:

(snip)

> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char *argv[])
> {
> if(strstr(argv[0], "]a.exe;") != NULL)
> {
> printf("I am A\n");
> }
> if(strstr(argv[0], "]b.exe;") != NULL)
> {
> printf("I am B\n");
> }
> return 0;
> }
I suspect you need a slightly better way to recognize the program name.

I am not so sure what VMS passes for argv[0] in all cases.

For extra fun, you can use the Command Definition Utility.

I remember TeX does fun things with the command name and arguments.
You need CDU to make them work right.

On 2023-07-16 20:30, Arne Vajhøj wrote:
> On 7/16/2023 2:28 PM, Arne Vajhøj wrote:
>> The two cost are hardware and peoples time.
>>
>> With todays TB disks it is very unlikely that having two copies of some
>> executables will require buying bigger and more expensive disk(s).
>>
>> Having developer support the name test logic on multiple platforms
>> and having sys admins needing to worry about linked stuff
>> when they clean up is a very small effort but still an
>> effort greater than zero.
>
> And just to make sure we are talking about the same.

[...]

Yes. And my point is that this detail is there no matter what. So you
didn't "save" anything by having two binaries. Since it's actually just
one binary, and how it behaves is based on which name it was invoked as.

Yes, you *could* have different binaries, with the different behaviors,
and not have to deal with all this.

But that was not what was going on here. The binary we are talking about
still have this logic you are hinting at. It's just that in addition to
that engineering work, which seems to be your concern, it also uses up
twice the space (or even more, depending on how many copies of the
program you happen to install).

I feel like you didn't get the point that the decision on what the
program should do based on under what name it was invoked was not absent
with these multiple copies... It is still there, and still made use of.

Sure disk space is cheap and all that. But in this case, it's really
questionable why not have a hard link. Even at a fraction of a cents
difference in cost, it's still not zero, and bad behavior should really
not be propagated. Sooner or later a small problem becomes a bigger problem.

Johnny

On 2023-07-16 20:09, Arne Vajhøj wrote:
> On 7/15/2023 10:47 AM, Johnny Billquist wrote:
>> And the secondary problem being that it's a little tricky to find the
>> last n lines in such a file organization. You'll have to do some
>> heuristics, and hope you got it right. But that usually is possible to
>> do with a high chance of success. So it could definitely be done. (I
>> have such a tool for RSX...)
>
> It depends on the record format.

Right. But in this case, the record format was given.

> VAR,VFC => read from start or make a good guess
> FIX, STM, STMLF, STMCR => no problem
> UDF => "last n lines" is not defined

And in this case it was VFC. And as I said - you can usually make a good
guess.

Johnny

On 2023-07-16 00:42, Dave Froble wrote:

> Ok, my test was on a VAX, but I doubt that has any bearing.  Don't have
> a clue. Unless you're trying to read the file while it's still open.
> That doesn't work.

Why wouldn't it work on an open file? As long as you are allowed shared
reading it should be just fine.

Johnny

Den 2023-07-17 kl. 12:52, skrev Johnny Billquist:
> On 2023-07-16 20:09, Arne Vajhøj wrote:
>> On 7/15/2023 10:47 AM, Johnny Billquist wrote:
>>> And the secondary problem being that it's a little tricky to find the
>>> last n lines in such a file organization. You'll have to do some
>>> heuristics, and hope you got it right. But that usually is possible to
>>> do with a high chance of success. So it could definitely be done. (I
>>> have such a tool for RSX...)
>>
>> It depends on the record format.
>
> Right. But in this case, the record format was given.
>
>> VAR,VFC => read from start or make a good guess
>> FIX, STM, STMLF, STMCR => no problem
>> UDF => "last n lines" is not defined
>
> And in this case it was VFC. And as I said - you can usually make a good
> guess.
>
>   Johnny
>

But, "read from start" is the same as TYPE without /TAIL. And that is
what I do when I get that error from TYPE/TAIL. Just TYPE the log file
and let it scroll to the end, the net result is the same as when using
/tail, the last 24 (or so) lines are on the screen. And besides, more
lines are available based on the size of my scroll-back buffer in the
emulator, usually 20000 or 200000 lines.

Jan-Erik.

On 7/17/2023 6:45 AM, Johnny Billquist wrote:
> On 2023-07-16 20:30, Arne Vajhøj wrote:
>> On 7/16/2023 2:28 PM, Arne Vajhøj wrote:
>>> The two cost are hardware and peoples time.
>>>
>>> With todays TB disks it is very unlikely that having two copies of some
>>> executables will require buying bigger and more expensive disk(s).
>>>
>>> Having developer support the name test logic on multiple platforms
>>> and having sys admins needing to worry about linked stuff
>>> when they clean up is a very small effort but still an
>>> effort greater than zero.
>>
>> And just to make sure we are talking about the same.
>
> [...]
>
> Yes. And my point is that this detail is there no matter what. So you
> didn't "save" anything by having two binaries. Since it's actually just
> one binary, and how it behaves is based on which name it was invoked as.
>
> Yes, you *could* have different binaries, with the different behaviors,
> and not have to deal with all this.
>
> But that was not what was going on here. The binary we are talking about
> still have this logic you are hinting at. It's just that in addition to
> that engineering work, which seems to be your concern, it also uses up
> twice the space (or even more, depending on how many copies of the
> program you happen to install).
>
> I feel like you didn't get the point that the decision on what the
> program should do based on under what name it was invoked was not absent
> with these multiple copies... It is still there, and still made use of.

Ah.

You are saying that they ditched the linking but kept the code
that made linking work.

As if in my example had done:

$ cc ab
$ link/exe=a ab
$ link/exe=b ab

That is silly in my opinion. They should have gotten rid of that code.

Simple is good - complex is bad.

Arne

On 7/17/2023 6:55 AM, Johnny Billquist wrote:
> On 2023-07-16 00:42, Dave Froble wrote:
>
>> Ok, my test was on a VAX, but I doubt that has any bearing. Don't have a
>> clue. Unless you're trying to read the file while it's still open. That
>> doesn't work.
>
> Why wouldn't it work on an open file? As long as you are allowed shared reading
> it should be just fine.
>
> Johnny
>

I'm not familiar with the TYPE utility.

I am a bit familiar with RMS, the DLM, and usage.

My guess is that the utility doesn't use any "read regardless" capability. So
"allowed shared reading" may not be in use. Just a guess.

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