l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
July 21: Defensive computing: Information security for individuals
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2001 Dec 30 17:01

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] reading gzip'd files inline
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] reading gzip'd files inline



On Mon, 19 Feb 2001, Micah Cowan wrote:

> On Mon, Feb 19, 2001 at 04:06:38PM -0800, jdnewmil@dcn.davis.ca.us wrote:
> > On Mon, 19 Feb 2001, Micah Cowan wrote:

[...]

> > > vi <(gzip -d -c doc.txt.gz)
> > > gv <(gzip -d -c doc.ps.gz)
> > > 
> > > Which will only work if the program doesn't mind fifos and doesn't try
> > > to use things like ftell(), fseek(), etc.
> > 
> > I guess the first command must include the "-" argument.
> > 
> > It is interesting to consider what must be happening here when you
> > actually do put the "-" in ... you have redirected vi input from the
> > terminal to a pipe.  Since vim actually handles this okay, it must be
> > reading to the end of the pipe and then resetting control back to the
> > controlling terminal by itself so you can give it editing commands.  
> > Quite a slick trick. :)
> 
> I don't understand your response at all - I assume you're talking
> about the first command of /my/ reply, since you replied to my
> message?

Yes.  Sorry for the imprecision.

> My commands aren't piping or redirecting to standard input of
> anything; the <(command) construct actually takes the output of
> whatever command is and writes it to a temporary fifo, and gets
> replaced in the command line by the name of that fifo.  This allows
> you to redirect program output to programs which can't /read/ standard
> input as files.

Learn something new every day.

> If you're /not/ responding to my post, I don't see how vim can
> "actually handle this okay", since there is no possible way to "reset"
> control back to the controlling terminal for programs whose input is
> piped, because at the time they're invoked, standard input has already
> been set to the pipe.

Then explain

 vi - <whateverfileyouwant.txt

> Okay, I suppose it could dup() stdout if it detects that that is a
> terminal, but that'd be very cludgey and un-vim-like.

Now where is that source...

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
Work:<JeffN@endecon.com>              Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.