Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions

[Gregory Pietsch]

If anyone finds any bugs or errors in my code, don't hesitate to tell 
me, as long as it's legitimate. I do not believe that I introduced new 
bugs in 2.20, but you never know.


As far as I know, there are two giant missing pieces of Edlin that I can 
surmise from all I have read about it. One is the obsolete workings of 
M$ Edlin's 'a' command. The second is implementing the F-keys and others 
with regard to modifying lines. The former is truly an obsolete way of 
dealing with large files; the latter I am constantly thinking about how 
to do it portably without making it look like a bag on the side of 
Edlin. If anyone can help remedy this and other headaches, I'd be happy.


Gregory

On 5/17/2022 3:23 PM, Jim Hall wrote:

I'm resharing an announcement from the website about Edlin 2.20:



Thanks to Gregory Pietsch, there is a new version of the classic
FreeDOS Edlin editor. If you haven't used Edlin, it's a text-mode
"line editor" for DOS that's similar to the Unix "ed(1)" editor. Some
of the more visible changes in this version of Edlin: + Added '#' as a
synonym for "$+1" + Added "New file." for new filenames on command
line + Added "Abort edit (Y/N)? " message. You can download the source
code from Edlin at SourceForge
. We have also
mirrored this release in the FreeDOS Files Archive at Ibiblio, under
/files/dos/edlin




I've also compiled Edlin 2.20 for DOS (both 16-bit and 32-bit) and
shared my executables here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.20/
edlin-220exe.zip


*I did only light testing of these Edlin executables, but they
compiled without error and they seem to run fine for me. Please test
yourself before using.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions

[Jim Hall]

I'm resharing an announcement from the website about Edlin 2.20:


Thanks to Gregory Pietsch, there is a new version of the classic
FreeDOS Edlin editor. If you haven't used Edlin, it's a text-mode
"line editor" for DOS that's similar to the Unix "ed(1)" editor. Some
of the more visible changes in this version of Edlin: + Added '#' as a
synonym for "$+1" + Added "New file." for new filenames on command
line + Added "Abort edit (Y/N)? " message. You can download the source
code from Edlin at SourceForge
. We have also
mirrored this release in the FreeDOS Files Archive at Ibiblio, under
/files/dos/edlin




I've also compiled Edlin 2.20 for DOS (both 16-bit and 32-bit) and
shared my executables here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.20/
edlin-220exe.zip


*I did only light testing of these Edlin executables, but they
compiled without error and they seem to run fine for me. Please test
yourself before using.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions

[Jim Hall]

On Thu, May 12, 2022 at 8:56 PM Gregory Pietsch  wrote:
>
> I'm thinking of editing Edlin to match historical behavior after
> downloading a 1982 IBM DOS manual and a 1987 Microsoft OS/2 manual I
> found floating around the 'Net. I want to make Edlin still the small
> program it has always been without adding things that would make the
> executable super-huge, so I want to get some feedback from the list
> before I do anything. The things I am considering are below:


My thoughts:

> 1. At the beginning of the program, when Edlin reads the file whose
> name is on the command line, the historical thing to do is output
> "End of input file" if the entire input file has been slurped in or
> "New file" if the file does not exist yet. FreeDOS Edlin just runs the
> same code as the T command to slurp the file in and give the output
> of that command, which is the number of lines read.

I think "New file" is good when you're starting a new file. But "End
of input file" isn't very helpful information. I prefer "X lines read"
if it's an existing file. That way, I will know if Edlin read my file
correctly.

> 2. The IBM DOS manual adds "#" as the line number that's one beyond
> the last line. This should be an easy add that doesn't change existing
> behavior.

That's a nice feature that I'd forgotten about. Yes, that makes sense.

> 3. The historical behavior for the Q command is to always verify that
> the user wanted to quit the program with an "Abort edit (Y/N)?" message.

I think it's always a good idea to verify that the user wants to quit.
Yes, this sounds good to me.

> 4. Historically, the E command erased any backup copy (i.e. the file
> with the .BAK extension) after writing and before quitting. I don't
> know if I want to emulate this behavior.

I'll sometimes make a backup copy of a file before I edit it, so I
might copy FDAUTO.BAT to FDAUTO.BAK before I edit the file, so I can
go back to the backup copy later. It would be bad if Edlin deleted my
backup copy on its own, just because it had the same "*.BAK"
extension. I prefer Edlin not delete files.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions

[Steve Nickolas]

On Thu, 12 May 2022, Gregory Pietsch wrote:


FreeDOS Mavens,

I'm thinking of editing Edlin to match historical behavior after downloading 
a 1982 IBM DOS manual and a 1987 Microsoft OS/2 manual I found floating 
around the 'Net. I want to make Edlin still the small program it has always 
been without adding things that would make the executable super-huge, so I 
want to get some feedback from the list before I do anything.




Well, there wouldn't be anything wrong with poking around at the MS-DOS 
2.11 version since it's MIT-licensed now and we legally have the sauce ;)


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Historical vs. Hysterical Edlin Versions

[Gregory Pietsch]

FreeDOS Mavens,

I'm thinking of editing Edlin to match historical behavior after 
downloading a 1982 IBM DOS manual and a 1987 Microsoft OS/2 manual I 
found floating around the 'Net. I want to make Edlin still the small 
program it has always been without adding things that would make the 
executable super-huge, so I want to get some feedback from the list 
before I do anything. The things I am considering are below:


1. At the beginning of the program, when Edlin reads the file whose
   name is on the command line, the historical thing to do is output
   "End of input file" if the entire input file has been slurped in or
   "New file" if the file does not exist yet. FreeDOS Edlin just runs
   the same code as the T command to slurp the file in and give the
   output of that command, which is the number of lines read.
2. The IBM DOS manual adds "#" as the line number that's one beyond the
   last line. This should be an easy add that doesn't change existing
   behavior.
3. The historical behavior for the Q command is to always verify that
   the user wanted to quit the program with an "Abort edit (Y/N)?" message.
4. Historically, the E command erased any backup copy (i.e. the file
   with the .BAK extension) after writing and before quitting. I don't
   know if I want to emulate this behavior.

I'll probably come up with some more. I am reluctant to add strings to 
Edlin, though, because it would make Jerome's i18n project more hairy. 
Nevertheless, part of the project's goals are to emulate historical 
behavior and eliminate hysterical behavior. There's a lot more there 
that I want to tackle just as soon as I figure it out, but I want to 
tackle the low-hanging fruit first. What do the list-subscribers say?


Gregory
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel