---

Hejsa,

Er der nogen af jer, der kender et godt eksempel på IPC via pipes på en
*bsd like platform?

Jeg er ude efter:

$bash> foo -a -b -c | bar -a -b -c

Jeg er ude efter at skrive foo applikationen. Output skal være en binær
stream.

mvh

Nikolaj Hansen

---

I dk.edb.system.unix, skrev Nikolaj Hansen:
> Hejsa,
>
> Er der nogen af jer, der kender et godt eksempel på IPC via pipes på en
> *bsd like platform?
>
> Jeg er ude efter:
>
> $bash> foo -a -b -c | bar -a -b -c
>
> Jeg er ude efter at skrive foo applikationen. Output skal være en binær
> stream.

| forbinder bare foo's STDOUT med bar's "STDIN".. intet magi i det.

Hvis de så forstår hinandens data, så virker det.

Eller er der mere i det, end det du lige har efterspurgt?

Jesper

--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:

> | forbinder bare foo's STDOUT med bar's "STDIN".. intet magi i det.
>
> Hvis de så forstår hinandens data, så virker det.
>
> Eller er der mere i det, end det du lige har efterspurgt?

Tror jeg egentlig ikke, jeg havde bare en eller anden ide om, at man var
nødt til at encode det på en eller anden måde hvis det ikke er tekst man
sender på denne måde.

eks.

myDecoder | lame

Hvor jeg regner med at det skal være en wav eller pcm stream.

mvh

Nikolaj Hansen

---

I dk.edb.system.unix, skrev Nikolaj Hansen:
> Jesper Krogh wrote:
>
> > | forbinder bare foo's STDOUT med bar's "STDIN".. intet magi i det.
> >
> > Hvis de så forstår hinandens data, så virker det.
> >
> > Eller er der mere i det, end det du lige har efterspurgt?
>
> Tror jeg egentlig ikke, jeg havde bare en eller anden ide om, at man var
> nødt til at encode det på en eller anden måde hvis det ikke er tekst man
> sender på denne måde.

Det er helt op til programmerne selv at være enige om et format de kan
forstå. Så ja, hvis du skal kode mod en eksisternde applikation, så skal
du vide hvad det er den ønsker at forstå.

Jesper

--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:
> Det er helt op til programmerne selv at være enige om et format de kan
> forstå. Så ja, hvis du skal kode mod en eksisternde applikation, så skal
> du vide hvad det er den ønsker at forstå.

Så er jeg nok nødt til lige at se på, hvordan lame behandler en indput
pipe i dens source.

mvh

Nikolaj Hansen

---

I dk.edb.system.unix, skrev Nikolaj Hansen:
> Jesper Krogh wrote:
> > Det er helt op til programmerne selv at være enige om et format de kan
> > forstå. Så ja, hvis du skal kode mod en eksisternde applikation, så skal
> > du vide hvad det er den ønsker at forstå.
>
> Så er jeg nok nødt til lige at se på, hvordan lame behandler en indput
> pipe i dens source.

Det er nok bedre at læse dokumentationen. ..

SYNOPSIS
lame [options] <infile> <outfile>

Fiffet er så .. at hvis den ikke læser fra STDIN overhovet, så kan du
"snyde" den på 2 måder.. du kan substituter <infile> med standard-in.

Den ene måde er at bruge "-" der betyder standard-in, den anden er at
bruge en "named-pipe".. der er en filsystem ting.

mkfifo pipe

Så kan du starte de 2 programmer individuelt, hvor den ene skriver til
filen "pipe" mens den anden læser fra den.


Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:

> mkfifo pipe
>
> Så kan du starte de 2 programmer individuelt, hvor den ene skriver til
> filen "pipe" mens den anden læser fra den.

Jeg tror i grunden det er det jeg er ude efter. Jeg har et util, der
bruger libxine til at decode en wma mms over http. libxine har bare
desværre ikke en pipe output plugin. Det var den jeg overvejede at lave.
De har dog en file output.

Men hvis man bare kan lave tricket med mkfifo streamfile og så referere
til den fil begge steder så er man jo hjemme.

Selvom nr 1. vil være lidt pænere. I hvert fald mere lig andre
en/decoders funktionalitet.

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:
>
> libxine har bare
> desværre ikke en pipe output plugin. Det var den jeg overvejede at lave.
> De har dog en file output.
>
> Men hvis man bare kan lave tricket med mkfifo streamfile og så referere
> til den fil begge steder så er man jo hjemme.

Det er ikke sikkert, at det kan lade sig gøre. Det
afhænger af formatet. Nogle formater starter med en
oplysning om filens længde. Med en fil er det nemt
nok at først skrive filen med nul i længdefeltet og
så til slut gå tilbage og overskrive feltet i starten
af filen med den rigtige værdi.

Hvis det du ønsker skal kunne lade sig gøre, så
kræver det enten at output formatet kan bruges uden
nogen længde header, eller at du er i stand til at
udregne længden på forhånd.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:

> Det er ikke sikkert, at det kan lade sig gøre. Det
> afhænger af formatet. Nogle formater starter med en
> oplysning om filens længde. Med en fil er det nemt
> nok at først skrive filen med nul i længdefeltet og
> så til slut gå tilbage og overskrive feltet i starten
> af filen med den rigtige værdi.

Det er rigtigt.

Men lige i forbindelse med streaming af audio, så er der ikke nogen
længde i header. Principielt set er den uendelig stor, da du jo kan lade
stream'en køre mod radiostationen lige så længe du vil.

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:
>
> Men lige i forbindelse med streaming af audio, så er der ikke nogen
> længde i header. Principielt set er den uendelig stor, da du jo kan lade
> stream'en køre mod radiostationen lige så længe du vil.

Problemstillingen med streaming er ca. den samme.
Så ethvert format, der kan bruges til streaming
burde også virke i dit tilfælde.

F.eks. har IFF en længde header, så ingen IFF
format kan virke. Det udelukker så 8SVX, AIFF
og egentlig også wav (wav er et RIFF format som
stort set bare er IFF med modsat byte ordering).

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Den Tue, 19 Jul 2005 12:53:29 +0000 (UTC) skrev Jesper Krogh:
> I dk.edb.system.unix, skrev Nikolaj Hansen:
>> Jesper Krogh wrote:
>> > Det er helt op til programmerne selv at være enige om et format de kan
>> > forstå. Så ja, hvis du skal kode mod en eksisternde applikation, så skal
>> > du vide hvad det er den ønsker at forstå.
>>
>> Så er jeg nok nødt til lige at se på, hvordan lame behandler en indput
>> pipe i dens source.
>
> Det er nok bedre at læse dokumentationen. ..
>
> SYNOPSIS
> lame [options] <infile> <outfile>
>
> Fiffet er så .. at hvis den ikke læser fra STDIN overhovet, så kan du
> "snyde" den på 2 måder.. du kan substituter <infile> med standard-in.
>
> Den ene måde er at bruge "-" der betyder standard-in, den anden er at
> bruge en "named-pipe".. der er en filsystem ting.

En fifo er ofte ikke nødvendig, man kan blot bruge /dev/stdin som
filnavn - eller hvis denne ikke eksisterer, /proc/self/fd/0

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.