forrie@morwyn.UUCP (Forrie Aldrich) (02/06/91)
I'm not sure how long ago I posted this, but because of the problems
some people are having with the new groups, I decided to post this
request one more time. Pardon the inconvenience! :)
I'm looking for a way to view standard ".GIF" files on the 3B1...
there MUST be a way... but I have no idea, and would appreciate it
if someone out there could let me know.
Thanks in advance!
Forrie
--
--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--------------------
Forrest Aldrich, Jr.| ...uunet!eci!morwyn!forrie |forrie@morywn.UUCP
| <email paths> |
CREATIVE CONNECTIONS| ...uunet!zinn!eci!morwyn!forrie |Graphic Illustration
------------------\-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/------------------
\___ PO Box 1541 - Dover, NH 03820 ___/ gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/21/91)
In <1991Feb7.204039.5842@sonyd1.Broadcast.Sony.COM> bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) writes: >cat filename.gif | remsh cray giftoppm '|' ppmtopgm '|' pgmtopbm | pbmto3b1 >:-) I've never understood why some people insist on using cat(1) to get stuff into the standard input of the lead program in a pipeline. I claim that: cat a | b | c is entirely equivalent in result to: b < a | c Right? -- Gary S. Trujillo gst@gnosys.svle.ma.us Somerville, Massachusetts {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst
dts@quad.sialis.com (David Sandberg) (02/22/91)
In article <993@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >I've never understood why some people insist on using cat(1) to get stuff >into the standard input of the lead program in a pipeline. I claim that: > cat a | b | c >is entirely equivalent in result to: > b < a | c The latter may be functional equivalent, but it's not nearly as readable to my eyes. The "path" by which the data "travels" starts in the middle of the command line, then jumps backwards to the start before leap-frogging forward to the end. On the other hand, using cat(1) to feed the start of a pipeline gives you a nice "front-to-back" data path which is more readily apparent at the viewer's first glance. (In my opinion, of course.) -- \\ David Sandberg \ ,=, ,=, \\ // dts@quad.sialis.com / | |uadric `=,ystems // \\ uunet!umn-cs!sialis!quad!dts \ `=\ `=' \\
bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) (02/22/91)
In article <993@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >In <1991Feb7.204039.5842@sonyd1.Broadcast.Sony.COM> > bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) writes: > >>cat filename.gif | remsh cray giftoppm '|' ppmtopgm '|' pgmtopbm | pbmto3b1 >>:-) > >I've never understood why some people insist on using cat(1) to get stuff >into the standard input of the lead program in a pipeline. I claim that: > > cat a | b | c > >is entirely equivalent in result to: > > b < a | c > >Right? Yes, it could have been: < filename.gif remsh cray giftoppm '|' ppmtopgm '|' pgmtopbm | pbmto3b1 (it was based on a pipeline using cat in the previous posting, and was intended as humour (note the smiley)-- the previous poster asked if there was a way to do the conversion in less than 3 minutes) Note that I've put the redirection first above; that preserves the data flow from left to right, which is also evident in the pipeline using cat. -- Bruce Lilly, Product Manager, | bruce@Broadcast.Sony.COM Digital Television Tape Recording, | uunet!sonyusa!sonyd1!bruce Sony, 3 Paragon Drive, Montvale, | lilb@sony.compuserve.com (slow) NJ 07645-1735 | Telephone: 1(201)358-4161 | FAX: 1(201)358-4089
ebh@argon.UUCP (Ed Horch) (02/22/91)
In article <993@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >I've never understood why some people insist on using cat(1) to get stuff >into the standard input of the lead program in a pipeline. I claim that: > > cat a | b | c > >is entirely equivalent in result to: > > b < a | c That's correct, but notationally, setting up a long pipeline using only pipes is, for some people, more intuitive than throwing a re- direction in there, since the order "do something with a, then b, then c" is maintained. There may be a performance cost due to creating an additional process for "cat a", but a smart shell will know how to short- cut around that. -Ed
rmfowler@texrex.uucp (Rex Fowler) (02/23/91)
In article <659@quad.sialis.com> dts@quad.sialis.com (David Sandberg) writes: >In article <993@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >>I've never understood why some people insist on using cat(1) to get stuff >>into the standard input of the lead program in a pipeline. I claim that: >> cat a | b | c >>is entirely equivalent in result to: >> b < a | c > >The latter may be functional equivalent, but it's not nearly as >readable to my eyes. The "path" by which the data "travels" >starts in the middle of the command line, then jumps backwards to >the start before leap-frogging forward to the end. On the other >hand, using cat(1) to feed the start of a pipeline gives you a >nice "front-to-back" data path which is more readily apparent at >the viewer's first glance. (In my opinion, of course.) > >-- > \\ David Sandberg \ ,=, ,=, \\ > // dts@quad.sialis.com / | |uadric `=,ystems // > \\ uunet!umn-cs!sialis!quad!dts \ `=\ `=' \\ If your into speed, use method 2. If your into pretty, use method 1. Method 1 creates an extra unnecessary process. Of course, in the case of viewing gif->pbm files, it's not very significant since the conversions take so long anyway. To save time viewing your GIF files, why not just keep them stored as PBM files. Then everytime you want to view one of them, its ready to go.. % giftoppm filename.gif | ppmtopgm | pgmtopbm > filename.pbm % pbmto3b1 filename.pbm -- Rex Fowler <rmfowler%texrex@cirr.com> UUCP: egsner!texrex!rmfowler
gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/24/91)
In <843@argon.UUCP> ebh@argon.UUCP (Ed Horch) writes: ... > > cat a | b | c > > > >is entirely equivalent in result to: > > > > b < a | c (And, as Bruce Lilly recently observed, it's also equivalent to < a b | c which David might like better, since it preserves his left-to-right ordering. ... > There may be a performance cost due to creating an additional > process for "cat a", but a smart shell will know how to short- > cut around that. I guess it was the performance cost that concerned me most - it just requires an extra process and takes system buffers unnecessarily. What's this about a "smart shell"? I've never heard of a shell that optimizes commands. It seems inherantly very difficult to recognize that the two commands listed above are equivalent, since it requires a knowledge of what cat(1) does. What shell are we talking about here? Actually, this discussion probably doesn't belong in the unix-pc news- groups, but I appreciate everyone's tolerance. And now we return you to your regular programming... :-) Gary -- Gary S. Trujillo gst@gnosys.svle.ma.us Somerville, Massachusetts {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst
kennii@wybbs.mi.org (Kenn Booth II) (02/25/91)
In article <843@argon.UUCP>, ebh@argon.UUCP (Ed Horch) writes: > In article <993@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: > >I've never understood why some people insist on using cat(1) to get stuff > >into the standard input of the lead program in a pipeline. I claim that: > > > > cat a | b | c > > > >is entirely equivalent in result to: > > > > b < a | c > > That's correct, but notationally, setting up a long pipeline using > only pipes is, for some people, more intuitive than throwing a re- > direction in there, since the order "do something with a, then b, > then c" is maintained. > > There may be a performance cost due to creating an additional > process for "cat a", but a smart shell will know how to short- > cut around that. > I find it easiest just to save files as "file.x.y" as in "file.2.5" for file 2 of 5... then, at a glance of my directory, I can tell if they are missing anything... then, do a: cat file.* | uudecode | zoo -test *.zoo will combine them, decode, and test the .zoo archive it leaves when done (assuming it uses .zoo... I leave it off when done...) (note... the above example probably won't work on systems that don't always keep the directory in alphabetical order...) Kenn "Jazz" Booth II -- Micro-Data Consultants [jazz@eurynome.grand-rapids.mi.us] [...!uunet!mailrus!eurynome!jazz] [kennii@wybbs.mi.org] [...!uunet!mailrus!sharkey!wybbs!kennii] [jazz@entropy.UUCP] [...!uunet!mailrus!{eurynome|wybbs}!entropy!jazz]
ebh@argon.UUCP (Ed Horch) (02/26/91)
In article <996@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >In <843@argon.UUCP> ebh@argon.UUCP (Ed Horch) writes: >> There may be a performance cost due to creating an additional >> process for "cat a", but a smart shell will know how to short- >> cut around that. > >What's this about a "smart shell"? I've never heard of a shell that >optimizes commands. It seems inherantly very difficult to recognize >that the two commands listed above are equivalent, since it requires >a knowledge of what cat(1) does. What shell are we talking about here? The Korn Shell has subsumed several common commands as shell builtins. I stand corrected on one point - cat isn't one of them, but echo and test are, among others. Yes, it does have knowledge about what those commands do. The shell decides whether to perform any task either inline, in a subshell, or in a subprocess, depending upon what would be most optimal. -Ed
forrie@morwyn.UUCP (Forrie Aldrich) (02/26/91)
I'm curious ...
Is there a way to SCAN pictures (via your typical scanner) into the 3B1?
I'm interested in scanning some photos, etc... and in turn creating
GIF files...
Please let me know if it's possible. I assume too that it would require
special software to do this... wonder if any has been written?
Thanks!
Forrie
--
--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--------------------
Forrest Aldrich, Jr.| ...uunet!eci!morwyn!forrie |forrie@morywn.UUCP
| <email paths> |
CREATIVE CONNECTIONS| ...uunet!zinn!eci!morwyn!forrie |Graphic Illustration
------------------\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/------------------
\___ PO Box 1541 - Dover, NH 03820 ___/