search

dosemu2 / comcom64

64bit command.com
https://github.com/dosemu2/comcom32/
GNU General Public License v3.0
32 stars 5 forks source link

"more" doesnt work #17

Closed stsp closed 7 months ago

stsp commented 5 years ago

dir |more gives the directory listing only for the first time. The subsequent invocations produce nothing. And even for the first time, it doesn't pause the scrolling.

ecm-pushbx commented 5 years ago

It not pausing the scrolling seems to be because perform_more https://github.com/stsp/comcom32/blob/cd728dae6acc5c3f2791d09abf62083f468f4393/command.c#L2442 just transfers data from its stdin to stdout, no prompting happens there. The prompting it should do is presumably similar to my paging facility in lDebug, which is at https://bitbucket.org/ecm/ldebug/src/49eb5bad57a9f3912c7e20ecf48300154cfa5202/source/lineio.asm#lines-350

The other bug may be due to wonky pipe handling, if I had to guess.

RossBoylan commented 5 years ago

I just built on Debian testing aka buster the latest comcom32, fdpp, and dosemu2. I also noticed more was wonky, but also erratic.

The first couple of times I tried to use with "more afile" (i.e., no pipe) it just sat there unresposive. After hitting some ^C and ^Z it exited, said it was shutting down, and when I hit enter it closed the emulator. (2 times means I restarted dosemu2, did the same things, and got the same result). crash-more-boot.log

Thinking I need to use a pipe (I couldn't get help within the shell beyond the name of the command) I did more < afile. Which printed the file out. It was too short to require pauses. Then I tried "more afile" again, which printed only a blank line but did return. "more <afile" (no space between < and a) also printed a blank line and returned. "more < afile", exactly the command I used before, also produced a blank line and returned.

I'm adding to this bug b/c it seems similar; I don't actually know if it's the same cause, or if the cause is within comcom32.

stsp commented 5 years ago

As for ^C - I think its just a default handling of comcom32 to terminate. Unrelated to more. Something to be changed.

stsp commented 5 years ago

The other bug may be due to wonky pipe handling, if I had to guess.

I suppose we really need a 64bit port now, as debugging this 32bit dpmi code looks difficult. With 64bit port we'll just be able to use gdb rather than have to guess.

stsp commented 7 months ago

After hitting some ^C and ^Z it exited

I believe those are fixed. more is still broken though.

stsp commented 7 months ago

Should now be fixed.