Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Richard Hirst <rhirst@linuxcare.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] pipes
Date: Thu, 15 Feb 2001 16:38:58 +0000	[thread overview]
Message-ID: <20010215163858.C1374@linuxcare.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0102100106450.27808-100000@front.linuxcare.com.au>; from alan@linuxcare.com.au on Sat, Feb 10, 2001 at 02:29:50AM +1100

Is this still a problem?

On Sat, Feb 10, 2001 at 02:29:50AM +1100, Alan Modra wrote:
> Would anyone like to hazard a guess as to whether pipes work OK?
> 
> The fixincludes problem I'm seeing with devel branch gcc builds looks like
> a loss of data in a pipe.  fixincl does a fairly standard trick of opening
> a pipe(2) to a fork & exec'd shell, and by putting a little debugging code
> in I see some fishy commands in the shell.
> 
> Good debug info looks like:
> 
> ==
> case hppa-unknown-linux-gnu in
> *-*-sysv4* | \
> i?86-*-sysv5* | \
> i?86-*-udk* | \
> i?86-*-solaris2.[0-4] | \
> powerpcle-*-solaris2.[0-4] | \
> sparc-*-solaris2.[0-4] )
>     echo run ;;
> * ) echo skip ;;
> esac
> ==
> cd /usr/include
> case hppa-unknown-linux-gnu in
> *-*-sysv4* | \
> i?86-*-sysv5* | \
> i?86-*-udk* | \
> i?86-*-solaris2.[0-4] | \
> powerpcle-*-solaris2.[0-4] | \
> sparc-*-solaris2.[0-4] )
>     echo run ;;
> * ) echo skip ;;
> esac
> 
> echo
> echo ShElL-OuTpUt-HaS-bEeN-cOmPlEtEd
> 
> where the first hunk of text between `=='s is wrapped in
> `cd /usr/include' .. `echo funky stuff' and plugged into the pipe.  The
> hunk of text after the second `==' is what the shell reads from the pipe.
> Everything works as expected for a while, and then we get
> 
> ==
> file=sys/stat.h
> if ( test  -r types/vxTypesOld.h ) > /dev/null 2>&1
> then echo TRUE
> else echo FALSE
> fi
> ==
> cd /usr/include
> file=sys/stat.h
> if ( test  -r types/vxTypesOld.h ) > /dev/null 2>&1
> then echo TRUE
> else echo FALSE
> fi
> d
> 
> Oops, did we just lose 41 chars?

Interesting that the loss is from the start of the wrapper text.  Is
the wrapping done in a local buffer and the whole lot written as one
operation to the pipe?  Or is it three seperate writes?

> Unfortunately, I'm not sure where the loss happens.  When I tried to
> "strace -f -s 256 ...", I ran into

Yes, strace -f doesn't seem to work.  I plan to look at that rsn.

Richard

  reply	other threads:[~2001-02-15 16:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-09 15:29 [parisc-linux] pipes Alan Modra
2001-02-15 16:38 ` Richard Hirst [this message]
2001-02-22  6:37 ` [parisc-linux] pipes Alan Modra
2001-02-22 10:37   ` Jes Sorensen
2001-02-22 11:00   ` Richard Hirst
2001-02-22 11:09     ` Richard Hirst
2001-02-22 11:26       ` Alan Cox
2001-02-22 11:39         ` Alan Modra
2001-02-22 11:52           ` Alan Cox
2001-02-22 11:53           ` Richard Hirst
2001-02-22 11:34     ` Alan Modra
2001-02-22 11:52       ` Richard Hirst
2001-02-22 12:27         ` Alan Modra
2001-02-22 13:03           ` Richard Hirst
2001-02-22 13:27             ` Alan Modra
2001-02-22 17:00               ` Richard Hirst
2001-02-22 17:44                 ` Paul Bame
2001-02-23 12:25                   ` Richard Hirst
2001-02-23 12:43                     ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010215163858.C1374@linuxcare.com \
    --to=rhirst@linuxcare.com \
    --cc=alan@linuxcare.com.au \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox