POSIX people, I need a tool recommendation:

I want a tool that will listen on stdin for a tar file and run a commandline for every file encountered, with the file being piped to it.

Ideally, I don't want things to touch the disk, because the tar file and files within it are likely to be big.

Is there a POSIX-style tool for this?

Can someone be kind to point me to documentation in freeBSD so I can change the font size of the console font at will?
It's unreadable in ghostBSD and it's too big in freeBSD relative to my IPS LED panels resolutions

This is something I should have known for decades.
TIT (today I taught) myself how to get lolcat permanently on every command that I enter without explicitly calling the pipe.

Syntax

'ssh yourserver port yourlogin|lolcat'

It's so nice to get lolcat on everything!

. #bash #TIL #TTT #sh #zsh #ksh #csh #tksh #fish #tcsh  #lolcat  #currentComputing #Colours #POSIX  #fresh #programming

I'm trying to add "genric" #signal handling to #poser. Ultimate goal is to provide a way for #swad to handle #SIGHUP, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).

Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in #SIGINFO which doesn't even exist on all platforms ...

Now, #POSIX specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on #Linux? Should I check #NSIG and, if not defined, just define it to 64?

Very important developments in DE

#LibreOffice #OpenSource #POSIX #GNU

https://fosstodon.org/@libreoffice/114420405083717141

Don't tell me you still don't have a boxyBSD VM. Request one while they lasr

Here's the status of the hypervisors running boxyBSD VMs

. #bash #freeBSD #boxyBSD #sh #zsh #ksh #csh  #netBSD #openBSD #POSIX

I'm going to play with this powerful ffmpeg feature time stretching

#POSIX #FFmpeg #Linux #OpenSource #bash

https://ffmpegbyexample.com/examples/749f6u35/timestretch_audio_and_video_using_rubberband_filter/

Revisiting #async / #await in #POSIX C, trying to "add some #security"

Recap: Consider a classic #reactor-style service in C with a #threadpool attached to run the individual request handlers. When such a handler needs to do some I/O, it'll have to wait for its completion, and doing so is kind of straight forward by just blocking the worker thread executing the job until whatever I/O was needed completes.

Now, blocking a thread is never a great thing to do and I recently tooted about an interesting alternative I found: Make use of the (unfortunately deprecated) POSIX user context switching to enable releasing the worker thread while waiting. In a nutshell, you create a context with #makecontext that has its own private #stack, and then you can use #swapcontext to get off the thread, and later again to get back on the thread. A minor issue is: It must be the *same* thread ... so you might have to wait until it completes something else before you can resume your job. But then, that's probably okayish, you can make sure in your job scheduling to only use worker threads with awaited tasks attached when no other thread is available.

In my first implementation, I just used #malloc to create a 64kiB private stack for each thread job. That's perfectly fine if you can guarantee your job will never consume more stack space, AND it won't have any vulnerabilities allowing some attacker to mess with the stack. But in practice, especially for a library offering this async/await implementation, it's nothing but a wild #CVE generator.

So, I now improved on that:

* Allocate a much larger stack of now 2MiB. That alone makes issues at least less likely. And on a sane modern OS, we can still assume pages will only be mapped "on demand".
* Only allocate the stack directly before running the thread job, and delegate allocation to some internal "stack manager" that keeps track of all allocated stacks and reuses them, only freeing them on exit. This should avoid most of the allocation overhead.
* If MAP_ANON / MAP_ANONYMOUS is available, use #mmap for allocating the stack. That at least gives a chance to stay away from other allocations ....
* But finally, if MAP_STACK is available, use this flag! From my research, #FreeBSD, #OpenBSD and #NetBSD will for example make sure there's at least one "guard page" below a stack mapped with this flag, so a stack overflow consistently takes the SIGSEGV emergency exit . #Linux knows this flag as well, but doesn't seem to implement such protection at this time ...

TIL about "silly renames" in #nfs and #fuse, and their 30-year history. Ashamed I ever thought positive thoughts about open-and-delete on #posix filesystems. On the plus side, I think I now understand some mysterious failures I've observed.
Seeing how bad we (in the sense of "I") can be at evaluating an API is something of a relief from watching how #democracy was being destroyed all along.
#silly_rename #silly_name #silly

Linus Torvalds has proper motivated reasons for really disliking file systems without a case sensitivity.

Read this with me from the kernel lkml, regarding bcachefs.

Re: [GIT PULL] bcachefs fixes for 6.15-rc4 - Linus Torvalds
https://lore.kernel.org/lkml/CAHk-=wjajMJyoTv2KZdpVRoPn0LFZ94Loci37WLVXmMxDbLOjg@mail.gmail.com/

#bash #sh #zsh #ksh #csh #tcsh #fish #git #Linux #lkml #POSIX #FOSS #100daysofCode #640DaysOfCode #coding #1024DaysOfCode #github #programming #Torvalds #filesystem

KDE keyboard shortcut note:

Goto

system settings > shortcuts > kwin

Check out the actions which can be bound to keyboard shortcuts.

Now
In here you're taught how to de Google yourself meaning how to use alternative applications on your phone your smart dumb phone

#OpenSource #POSIX #GNU #is #not #UNIX #Linux #Alphabet #Android

https://tuta.com/blog/how-to-leave-google-gmail

I figured #swad's password file management tool (swadpw) should really *ensure* that when reading a password from the #terminal, prompts are printed to exactly that terminal.

Well, I already check whether standard input *is* a terminal. In that case, I assume it *should* be writable. It certainly *is* writable on #FreeBSD and #Linux. But I can't find any guarantee looking at #POSIX specs .

Ok, so I wrote a weirdo function to provide fallbacks. Is this taking it too far? And how would I ever test these fallbacks?

Linus Torvalds has coded git two decades ago.

Learn about why how who and where here

https://youtu.be/sCr_gb8rdEI?si=s8tDVh1e8dBTGWkJ

#bash #sh #zsh #ksh #csh #tcsh #fish #git #Linux #POSIX #FOSS #100daysofCode #640DaysOfCode #coding #1024DaysOfCode #github #programming

Just released: #swad v0.3!

https://github.com/Zirias/swad/releases/tag/v0.3

swad is the "Simple Web Authentication Daemon", your tiny, efficient and (almost) dependency-free solution to add #cookie + login #form #authentication to whatever your #reverse #proxy offers. It's written in pure #C, portable across #POSIX platforms. It's designed with #nginx' 'auth_request' in mind, example configurations are included.

This release brings a file-based credential checker in addition to the already existing one using #PAM. Also lots of improvements, see details in the release notes.

I finally added complete build instructions to the README.md:

https://github.com/Zirias/swad

And there's more documentation available: manpages as well as a fully commented example configuration file.

What if bash was written in Rust? I think it's time.

**brush** — Bash/POSIX-compatible shell implemented in Rust

Bo(u)rn(e) RUsty SHell

Built & tested on Linux/macOS/Windows

GitHub: https://github.com/reubeno/brush