020111 067544 023556 020164 062556 062145 067040 020157
072163 062545 065556 067151 020147 062550 060570 062544
064543 060555 020554 005012

--
Beauty and harmony are as necessary to you as the very breath of life.

On Sat, 9 Nov 2024 09:36:58 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:

> 020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
> 065556 067151 020147 062550 060570 062544 064543 060555 020554 005012

041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
062151 060556 020155 060543 064151 067145 027056 027077

John Ames wrote this post while blinking in Morse code:

> On Sat, 9 Nov 2024 09:36:58 -0500
> Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
>
>> 020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
>> 065556 067151 020147 062550 060570 062544 064543 060555 020554 005012
>
> 041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
> 071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
> 062151 060556 020155 060543 064151 067145 027056 027077

Damn, I still haven't found a program that would easily reverse octal to a
string.

--
Q: How many marketing people does it take to change a light bulb?
A: I'll have to get back to you on that.

On 11/11/2024 1:58 PM, Chris Ahlstrom wrote:
> John Ames wrote this post while blinking in Morse code:
>
>> On Sat, 9 Nov 2024 09:36:58 -0500
>> Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
>>
>>> 020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
>>> 065556 067151 020147 062550 060570 062544 064543 060555 020554 005012
>> 041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
>> 071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
>> 062151 060556 020155 060543 064151 067145 027056 027077
> Damn, I still haven't found a program that would easily reverse octal to a
> string.
>

This is crude, but it seems to work for the post you're replying to,
with big-endian two-byte integers:

===
#include <stdio.h>

int main(void)
{     union {
        unsigned short s;
        char c[2];
    } w;
    unsigned int wi;
    char junk;

    while (scanf("%o%c", &wi, &junk) > 0) {
        w.s = wi;
        printf("%c%c", w.c[1], w.c[0]);
    }
    printf("\n");

    return 0;
} ===

To read a sequence of two-byte octal little-endian integers, swap w.c[1]
and w.c[0].

Louis

Louis Krupp wrote this post while blinking in Morse code:

> On 11/11/2024 1:58 PM, Chris Ahlstrom wrote:
>> John Ames wrote this post while blinking in Morse code:
>>
>>> On Sat, 9 Nov 2024 09:36:58 -0500
>>> Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
>>>
>>>> 020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
>>>> 065556 067151 020147 062550 060570 062544 064543 060555 020554 005012
>>> 041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
>>> 071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
>>> 062151 060556 020155 060543 064151 067145 027056 027077
>> Damn, I still haven't found a program that would easily reverse octal to a
>> string.
>>
>
> This is crude, but it seems to work for the post you're replying to,
> with big-endian two-byte integers:
>
> ===
> #include <stdio.h>
>
> int main(void)
> {
>     union {
>         unsigned short s;
>         char c[2];
>     } w;
>     unsigned int wi;
>     char junk;
>
>     while (scanf("%o%c", &wi, &junk) > 0) {
>         w.s = wi;
>         printf("%c%c", w.c[1], w.c[0]);
>     }
>     printf("\n");
>
>     return 0;
> }
> ===
>
> To read a sequence of two-byte octal little-endian integers, swap w.c[1]
> and w.c[0].

Thanks!

--
After all, what is your hosts' purpose in having a party? Surely not for
you to enjoy yourself; if that were their sole purpose, they'd have simply
sent champagne and women over to your place by taxi.
-- P. J. O'Rourke

E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A

On 2024-11-12, John Ames <commodorejohn@gmail.com> wrote:

> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A

Ah, finally something I can understand!

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

In comp.os.linux.misc, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
> This is crude, but it seems to work for the post you're replying to,
> with big-endian two-byte integers:

[snip C code with Unicode whitespace]

> To read a sequence of two-byte octal little-endian integers, swap w.c[1]
> and w.c[0].

Or you could just pipe the output through `dd conv=swab`.

Elijah
------
whose c compiler doesn't like non-ASCII whitespace

Charlie Gibbs wrote this post while blinking in Morse code:

> On 2024-11-12, John Ames <commodorejohn@gmail.com> wrote:
>
>> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A
>
> Ah, finally something I can understand!

You all beat me for geek fu! :-(

But I am young. (67)

--
By failing to prepare, you are preparing to fail.

Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 21:12 this Tuesday (GMT):
> Charlie Gibbs wrote this post while blinking in Morse code:
>
>> On 2024-11-12, John Ames <commodorejohn@gmail.com> wrote:
>>
>>> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A
>>
>> Ah, finally something I can understand!
>
> You all beat me for geek fu! :-(
>
> But I am young. (67)

67 is not young..
--
user <candycane> is generated from /dev/urandom

candycanearter07 wrote this post while blinking in Morse code:

> Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 21:12 this Tuesday (GMT):
>> Charlie Gibbs wrote this post while blinking in Morse code:
>>
>>> On 2024-11-12, John Ames <commodorejohn@gmail.com> wrote:
>>>
>>>> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A
>>>
>>> Ah, finally something I can understand!
>>
>> You all beat me for geek fu! :-(
>>
>> But I am young. (67)
>
> 67 is not young.

It is when you got 80+ year-old Presidents and doddering Congressmen.

Anyway, I never got experience on IBM mainframes, just on DEC machines.

Ah yes:

--
Of all men's miseries, the bitterest is this:
to know so much and have control over nothing.
-- Herodotus

John Ames <commodorej...@gmail.com> [JA]:
JA> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A

Do you want a spell checker with that?

Pipe it to

xxd -r -ps -u | iconv -f EBCDIC-CP-US -t ascii | aspell -pipe list | fmt

(unix pipes can be such fun)

Fritz Wuehler schrieb am 14. Nov. 2024 um 21:13:
> John Ames <commodorej...@gmail.com> [JA]:
> JA> E399A840 A38889A2 40969540 86969940 A289A985 4B4B4B5A

> Do you want a spell checker with that?
>
> Pipe it to
>
> xxd -r -ps -u | iconv -f EBCDIC-CP-US -t ascii | aspell -pipe list | fmt
>
>
> (unix pipes can be such fun)

I increase it with

--8<---------------cut here---------------start------------->8---
nowplaying-cli get artist title | perl -p -e "s/\n/ - /" | rev | -c4- | rev
--8<---------------cut here---------------end--------------->8---

🤣

--
np: Lost Frequencies & Love Harder - You (feat. Flynn) [Deluxe Mix]

In comp.os.linux.misc, Clemens Schüller <cs.usenet@mailbox.org> wrote:
> I increase it with
>
> --8<---------------cut here---------------start------------->8---
> nowplaying-cli get artist title | perl -p -e "s/\n/ - /" | rev | -c4- | rev
> --8<---------------cut here---------------end--------------->8---

Okay, I give up.

1. How does that relate to EBCDIC?
2. What is the "-c4-" step doing?

(I have no programs on my path that start with "-". I do have a few that
end with "-".)

Elijah
------
"rev | rev" is no-op so really curious about the middle transition

On Thu, 14 Nov 2024 23:55:53 -0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:

> Okay, I give up.
>
> 1. How does that relate to EBCDIC?

(I think it was a topic shift to applications of *nix pipes...?)

On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:

> (I think it was a topic shift to applications of *nix pipes...?)

Oh shelly boy, the pipes, the pipes are calling ...

In comp.os.linux.misc, John Ames <commodorejohn@gmail.com> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
> > Okay, I give up.
> > 1. How does that relate to EBCDIC?
> (I think it was a topic shift to applications of *nix pipes...?)

Traditional Unix "spell", which merely outputs words not recognized
without context or even line numbers, is an application of pipes.

Roughly like this:

--8<---------------cut here---------------start------------->8---
cat ~/.spell.words /usr/dict/words 2>/dev/null |
tr A-Z a-z |
tr -dc a-z'
' |
grep '[a-z]' |
SPELLSTEMTOOL |
sort -u > $TMPFILE_A

< $INPUT_FILE tr -s ' ^I!$&()_+[]{}:l"'\''\\.,?/-' '
' |
tr A-Z a-z |
tr -dc a-z'
' |
grep '[a-z]' |
sort -u > $TMPFILE_B

comm -13 $TMPFILE_A $TMPFILE_B
--8<---------------cut here---------------end--------------->8---

Where SPELLSTEMTOOL is a heuristic that tries to make "try" into "tries"
and related dictionary fixes to compensate for the words file not having
all the variants. (These days it is /usr/share/dict/words but also
these days traditional spell is hard to find. Gnu spell is different.)

Elijah
------
or maybe the stem tool worked on file B in the other direction

On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
>
>> (I think it was a topic shift to applications of *nix pipes...?)
>
> Oh shelly boy, the pipes, the pipes are calling ...

Pipes are good.

But, really, they're just temp files the parent
process can access.

On Fri, 15 Nov 2024 02:49:54 -0500
"186282@ud0s4.net" <186283@ud0s4.net> wrote:

> Pipes are good.
>
> But, really, they're just temp files the parent process can access.

(shhh, don't tell anybody)

On 2024-11-14, Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.os.linux.misc, Clemens Schüller <cs.usenet@mailbox.org> wrote:
>
>> I increase it with
>>
>> --8<---------------cut here---------------start------------->8---
>> nowplaying-cli get artist title | perl -p -e "s/\n/ - /" | rev | -c4- | rev
>> --8<---------------cut here---------------end--------------->8---
>
> Okay, I give up.
>
> 1. How does that relate to EBCDIC?
> 2. What is the "-c4-" step doing?
>
> (I have no programs on my path that start with "-". I do have a few that
> end with "-".)
>
> Elijah
> ------
> "rev | rev" is no-op so really curious about the middle transition

I think the OP dropped a word - "cut -c4-" would make it
drop the first 3 characters of each line.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On Fri, 15 Nov 2024 02:49:54 -0500, 186282@ud0s4.net wrote:

> But, really, they're just temp files the parent process can access.

They’re in-kernel memory buffers, with a read end and a write end.
Actually you can have multiple processes at each end. Readers can
automatically block waiting for writers, writers can automatically block
waiting for readers.

Try doing that with temporary files.

On 2024-11-15, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
> This is a multi-part message in MIME format.
> --------------cDOk308Xy6TMkzB8MsXpyDQY
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
>
> On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
>> On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
>>>
>>>> (I think it was a topic shift to applications of *nix pipes...?)
>>>
>>> Oh shelly boy, the pipes, the pipes are calling ...
>>
>>   Pipes are good.
>>
>>   But, really, they're just temp files the parent
>>   process can access.
>
> Pipes *could* be implemented with temporary disk files, at least to an
> extent, but as far as I can tell, they're not.
>
> Quoting from this page:
>
> https://www.geeksforgeeks.org/piping-in-unix-or-linux/#
>
> In Linux, a pipe is not a regular file but a type of inter-process
> communication (IPC) mechanism that acts as a buffer, which can be
> used to connect the output of one process to the input of another.
> Although pipes are not files, they are implemented using file
> descriptors and share many behaviors with files. They exist only in
> memory and do not have a presence in the file system, unlike regular
> files.
>
> Louis

There are also "named pipes" aka FIFOs. On Devuan Daedalus (and
probably most other distributions) this command will show
information about them:

man 7 pipe

I have used a named pipe aka FIFO on a Raspberry PI. An mplayer
process reads from a PVR-USB2 TV receiver and writes to the named
pipe or FIFO. A netcat process reads from the named pipe or FIFO
to send the bits to a larger computer with substantial disk
storage. A 105 minute recording session is several GB in size.
A cron job, ssh, and some shell scripting launch the stuff.

(Unfortunately, either the amplified TV antenna in the attic has
lost its gain, or the PVR-USB2 unit has lost front-end gain, so
it has not captured a viewable program in a few years.)

HTH

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 11/15/24 6:20 AM, Louis Krupp wrote:
> On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
>> On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
>>>
>>>> (I think it was a topic shift to applications of *nix pipes...?)
>>>
>>> Oh shelly boy, the pipes, the pipes are calling ...
>>
>>   Pipes are good.
>>
>>   But, really, they're just temp files the parent
>>   process can access.
>
> Pipes *could* be implemented with temporary disk files, at least to an
> extent, but as far as I can tell, they're not.

Well, they can be on ACTUAL disk space - or on
a RAMdisk or just a reserved stretch of RAM.

The last one is quickest - but most taxing on
run-time resources.

> Quoting from this page:
>
> https://www.geeksforgeeks.org/piping-in-unix-or-linux/#
>
>    In Linux, a pipe is not a regular file but a type of inter-process
>    communication (IPC) mechanism that acts as a buffer, which can be
>    used to connect the output of one process to the input of another.
>    Although pipes are not files, they are implemented using file
>    descriptors and share many behaviors with files. They exist only in
>    memory and do not have a presence in the file system, unlike regular
>    files.

There are clearly a lot of ways to implement "pipes".
'C' does it the 'C' way.

IF you are doing multi-threaded/process style pgms then you
almost HAVE to use them if you want to xmit more than
a few bytes between parents/children. A few years back
I was experimenting with TCP/UDP servers and found that
it could be very useful to transmit a few dozen bytes
worth of active data between parents/children.

SO ... learn yer pipes !

On Sat, 16 Nov 2024 00:37:35 -0500, 186282@ud0s4.net wrote:

> IF you are doing multi-threaded/process style pgms then you almost
> HAVE to use them if you want to xmit more than a few bytes between
> parents/children. A few years back I was experimenting with TCP/UDP
> servers and found that it could be very useful to transmit a few
> dozen bytes worth of active data between parents/children.
>
> SO ... learn yer pipes !

Message queues and shared memory are handy for IPC too. I don't think
Microsoft ever figured either out. What they call message queues are
completely different.

On 16 Nov 2024 04:33:07 GMT, Robert Riches wrote:

> There are also "named pipes" aka FIFOs.

https://manpages.debian.org/7/pipe.7.en.html
https://manpages.debian.org/7/fifo.7.en.html

Not to be confused with Unix sockets.

https://manpages.debian.org/7/unix.7.en.html