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:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
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, Feb 19, 2001 at 04:06:38PM -0800, jdnewmil@dcn.davis.ca.us wrote:
> On Mon, 19 Feb 2001, Micah Cowan wrote:
> 
> > On Mon, Feb 19, 2001 at 11:23:28AM -0800, Peter Jay Salzman wrote:
> > > question:
> > > 
> > > given
> > >   doc.txt.gz
> > >   doc.ps.gz
> > > 
> > > how do i read these file in line?   i've tried:
> > > 
> > >   gzip -d -c doc.txt.gz | vi
> > >   gzip -d -c doc.ps.gz | gv
> > > 
> > > but neither vim nor gv like getting data from stdin.  vim complains about no
> > > controlling tty and gv just displays nothing.
> > > 
> > > thanks!
> > > p
> > > 
> > > -- 
> > > "It's better to be safe than assimilated."                   p@dirac.org
> > >                       -- Chakotay                            www.dirac.org/p
> > 
> > You might try:
> > 
> > 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?

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.

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.

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.

Micah


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.