dan@ivucsb.sba.ca.us (Dan Howell) (05/28/89)
When using the ARP shell with the ConMan PIP: device, it has problems when piping to more. If I do, for example: dir | more the directory listing comes out of more double spaced. Any ideas? -- -- Dan Howell <dan@ivucsb.sba.ca.us> <ivucsb!dan@anise.acc.com> -- 55 miles per hour: it's not a good idea, it's just the law.
andrewl@netcom.UUCP (Andrew Lagodzinski) (05/30/89)
In article <801@ivucsb.sba.ca.us> dan@ivucsb.sba.ca.us (Dan Howell) writes:
=When using the ARP shell with the ConMan PIP: device, it has problems when
=piping to more. If I do, for example:
=
=dir | more
Where did you get a version of more that accepts input from STDIN?
I use More from WorkBench 1.3 daily and would really like to be able to
pipe (using WShell and PIP:) stuff to More.
=--
=-- Dan Howell <dan@ivucsb.sba.ca.us> <ivucsb!dan@anise.acc.com>
=-- 55 miles per hour: it's not a good idea, it's just the law.
Andrew Lagodzinski
andrewl@netcomm.uucp !sun!amdahl!netcom!andrewl
andrew@cup.portal.com !sun!cup.portal.com!andrew deven@rpi.edu (Deven Corzine) (05/30/89)
In article <801@ivucsb.sba.ca.us> dan@ivucsb.sba.ca.us (Dan Howell) writes: > When using the ARP shell with the ConMan PIP: device, it has > problems when piping to more. If I do, for example: > dir | more > the directory listing comes out of more double spaced. Any ideas? Yeah, I've noticed that too. Specifically, the first 2-3 lines display single-spaced, and everything thereafter is double-spaced. I don't know if it's a bug in pip:, more, or both. Perhaps a CFLF turning into a \n\n? But that would leave the few single-spaced lines unexplained. Anyone at CATS care to take a stab at where the bug might be? (at least you can check out the more (V3.27, I believe) source code... Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
deven@rpi.edu (Deven Corzine) (05/30/89)
In article <1328@netcom.UUCP> andrewl@netcom.UUCP (Andrew Lagodzinski) writes: > In article <801@ivucsb.sba.ca.us> dan@ivucsb.sba.ca.us (Dan Howell) writes: > =When using the ARP shell with the ConMan PIP: device, it has > =problems when piping to more. If I do, for example: > =dir | more > Where did you get a version of more that accepts input from > STDIN? I use More from WorkBench 1.3 daily and would really like to > be able to pipe (using WShell and PIP:) stuff to More. Same one. More v3.27 off the Workbench 1.3 disk. runs resident, but causes a checksum error under ARes, so I use the nocheck option of ARes to take care of that. I believe more uses an IsInteractive() call to figure out whether to use stdin or ask for a filename... And it works with AShell and PIP:... sort of. I should think it would work identically with WShell and PIP:. Try it. (running it from a console window will always make it ask for a filename, because it is an interactive input.) Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
andrewl@netcom.UUCP (Andrew Lagodzinski) (05/31/89)
In article <DEVEN.89May30032727@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: [STUFF DELETED] >Same one. More v3.27 off the Workbench 1.3 disk. runs resident, but >causes a checksum error under ARes, so I use the nocheck option of >ARes to take care of that. I believe more uses an IsInteractive() >call to figure out whether to use stdin or ask for a filename... And >it works with AShell and PIP:... sort of. I should think it would >work identically with WShell and PIP:. Try it. (running it from a >console window will always make it ask for a filename, because it is >an interactive input.) > Well I don't know what I was thinking but it does work. I am using resi that came with WShell, but I have to use the -ignore option so that it will load, but it is smooth operation from there. I do have the double space problem mentioned in the original article though. >Deven >-- >shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 >shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America >deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> >"Simple things should be simple and complex things should be possible." - A.K. Andrew Lagodzinski andrewl@netcomm.uucp !sun!amdahl!netcom!andrewl andrew@cup.portal.com !sun!cup.portal.com!andrew
UH2@PSUVM.BITNET (Lee Sailer) (05/31/89)
In article <801@ivucsb.sba.ca.us>, dan@ivucsb.sba.ca.us (Dan Howell) says: > >When using the ARP shell with the ConMan PIP: device, it has problems when >piping to more. If I do, for example: > >dir | more > >the directory listing comes out of more double spaced. Any ideas? >-- I "fixed" this by replacing more with less.
mclek@dcatla.UUCP (Larry E. Kollar) (06/01/89)
In article <801@ivucsb.sba.ca.us>, dan@ivucsb.sba.ca.us (Dan Howell) says: >>.... If I do, for example: >> >>dir | more >> >>the directory listing comes out of more double spaced. Any ideas? In article <89151.100553UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) replies: >I "fixed" this by replacing more with less. I tried that too, and got an instant GURU. What version of less were you using? Still pipe dreaming, -- Larry Kollar ...!gatech!dcatla!mclek If potatoes aren't computers, why are there potato chips and potato bugs?
andy@cbmvax.UUCP (Andy Finkel) (06/01/89)
In article <DEVEN.89May30032151@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: >In article <801@ivucsb.sba.ca.us> dan@ivucsb.sba.ca.us (Dan Howell) writes: > >Anyone at CATS care to take a stab at where the bug might be? (at >least you can check out the more (V3.27, I believe) source code... MORE, when connected to an Amiga console handler attempts to put the handler into raw mode, where a CR is just a return, and a LF is just a newline. (basically it assumes it can turn off all CR->CRLF type conversion) Possibly this mode is not supported by one of the programs used. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Trouble can be purchased cheaply, though the refund may be more than you can afford." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
UH2@PSUVM.BITNET (Lee Sailer) (06/02/89)
In article <19495@dcatla.UUCP>, mclek@dcatla.UUCP (Larry E. Kollar) says: >In article <89151.100553UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) replies: >>I "fixed" this by replacing more with less. > >I tried that too, and got an instant GURU. What version of less were >you using? > Less 1.2, from Fish Disk 131, or thereabouts.
johnm@spudge.UUCP (John Munsch) (06/03/89)
>>In article <89151.100553UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) replies: >>>I "fixed" this by replacing more with less. >> >>I tried that too, and got an instant GURU. What version of less were >>you using? >>Larry Kollar ...!gatech!dcatla!mclek I've been waiting for someone to use these two words in conjunction just to see if I'm not crazy... GURU & less I have had to remove less from my system completely because it is a guaranteed GURU somewhere down the road after I use it. I've been completely unsuccessful at determining what it is that is causing the conflict because I've installed so many things on my machine recently (Rexx, ARP, GOMF, etc). Anybody got any suggestions of another viewing program that will operate from the CLI and will take wildcards in filenames? John Munsch
deven@rpi.edu (Deven Corzine) (06/03/89)
In article <7034@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >MORE, when connected to an Amiga console handler attempts to put the >handler into raw mode, where a CR is just a return, and a LF is just >a newline. (basically it assumes it can turn off all CR->CRLF type >conversion) Possibly this mode is not supported by one of the >programs used. I assume you're talking about it's Output()? When I try, for example, "list | more" (under AShell, using ConMan 1.3's PIP: to create the interprocess pipe), it shows a directory listing, but with a blank line between every line BUT the first two. I did "list | type opt h" to check the actual characters sent; only a LF (0x0a) is sent at the end of a line. I assume more checks IsInteractive(Input()) to know if to ask for a filename, so it seems to correctly figure out that its input (from list, through PIP:) is not a console device. Its output, on the other hand, is the current window. In raw mode, I would expect it to either work correctly, or start each new line directly below the end of the last. Double spacing I could see if a CRLF at the end of each line turned into a CRLFCRLF. But it's a single LF (or "newline") turning into CRLFLF, effectively. This I don't understand. The output from the list command contains NO CR character. What could be happening? Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
sdl@linus.UUCP (Steven D. Litvintchouk) (06/05/89)
In article <1000@spudge.UUCP> johnm@spudge.UUCP (John Munsch) writes: > I have had to remove less from my system completely because it is a > guaranteed GURU somewhere down the road after I use it. I've been > completely unsuccessful at determining what it is that is causing > the conflict.... Less v1.3 has a genuine and repeatable bug (which earlier versions of Less didn't have). If you run GOMF 3.0 with vector checking enabled (the ^ option), and run Less v1.3, GOMF 3.0 will trap the error. If you don't run GOMF 3.0 this way, the bug remains to cause bizarre behavior later on. For example, selecting a disk icon with the mouse immediately after starting Less v1.3 causes an immediate Guru. I have attempted to notify the author of Less v1.3 about this bug. So far, I have received no response. Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.
ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) (06/06/89)
In article <801@ivucsb.sba.ca.us> dan@ivucsb.sba.ca.us (Dan Howell) writes: >When using the ARP shell with the ConMan PIP: device, it has problems when >piping to more. If I do, for example: I haven't noticed this particular problem, but I have noticed that sending more than a couple kb of stuff through a pipe will generally crash. I've seen this problem with several combinations of programs, so it seems to be AShell or pip:, or some interaction between the two. Anyone else noticed problems when doing this? For instance, ls -l | grep <pattern> on a huge directory will crash. or zcat largefile.Z | more will crash. zcat largefile.Z >largefile more largefile works fine. -- Eric Kennedy ejkst@cisunx.UUCP
leivian@dover.sps.mot.com (Bob Leivian) (06/07/89)
In article <1000@spudge.UUCP> johnm@spudge.UUCP (John Munsch) writes: >>>In article <89151.100553UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) replies: >>>>I "fixed" this by replacing more with less. > >Anybody got any suggestions of another viewing program that will operate from >the CLI and will take wildcards in filenames? > >John Munsch I suggest anybody who has any information on this send me mail so I can fix the problem, rather than discarding the program, It does appear that 1.3 has a problem although I can't reproduce it. 1.2 is apparently ok, when I updated 1.2 to 1.3 I started with the rev 73 (up from rev 48) UNIX sources something in those updates is causing a problem. I cant find it, is has something to do witrh GOMF, MemWatch, 1.3 etc. In the meantime use rev 1.2 (fish 90's somewhere) -- still looking for the problem, Bob Leivian