I’ve got a prototype of my hardcopy simulator going. I’m typing on the keyboard and the “display” goes to the printer:

https://movq.de/v/56feb53912/s.png

https://movq.de/v/235c1eabac/MVI_8810.MOV.mp4

The biiiiiiiiiig problem is that the print head and plastic cover make it impossible to see what’s currently being printed, because this is not a typewriter. This means: In order to see what I just entered, I have to feed the paper back and forth and back and forth … it’s not ideal.

I got that idea of moving back/forth from Drew DeVault, who – as it turned out – did something similar a few years back. (I tried hard to read as little as possible of his blog post, because figuring things out myself is more fun. But that could mean I missed a great idea here or there.)

But hey, at least this is running on my Pentium 133 on SuSE Linux 6.4, printer connected with a parallel cable. 😍

(Also, yes, you can see the printouts of earlier tests and, yes, I used ed(1) wrong at one point. 🤪 And ls insisted on using colors …)

Something happened with the frame rate of terminal emulators lately. It looks like there’s a trend to run at a high framerate now? I’m not sure exactly. This can be seen in VTE-based terminals like my xiate or XTerm on Wayland. foot and st, on the other hand, are fine.

My shell prompt and cursor look like this:

$ █

When I keep Enter pressed, I expect to see several lines like so:

$
$
$
$
$
$
$ █

With the affected terminal emulators, the lines actually show up in the following sequence. First, we have the original line:

$ █

Pressing Enter yields this as the next frame:

$
█

And then eventually this:

$
$ █

In other words, you can see the cursor jumping around very quickly, all the time.

Another example: Vim actually shows which key you just pressed in the bottom right corner. Keeping j pressed to scroll through a file means I get to see a j flashing rapidly now.

(I have no idea yet, why exactly XTerm in X11 is fine but flickering in Wayland.)

The WM_CLASS Property is used on X11 to assign rules to certain windows, e.g. “this is a GIMP window, it should appear on workspace number 16.” It consists of two fields, name and class.

Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called app_id.

When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.

Some compositors map name to app_id, others map class to app_id, and even others directly expose the original name and class.

Apparently, there is no consensus.

Just discovered how easy it is to recall my last arg in shell and my brain went 🤯 How come I’ve never learned about this before!? I wonder how many other QOL shortcuts I’m missing on 🥲

@kat@yarn.girlonthemoon.xyz @prologic@twtxt.net Given that all these programs are super old (tar is from the late 1970ies), while trying to retain backwards-compatibilty, I’m not surprised that the UI isn’t too great. 🤔

find has quite a few pitfalls, that is very true. At work, we don’t even use it anymore in more complex scenarios but write Python scripts instead. find can be fast and efficient, but fewer and fewer people lack the knowledge to use it … The same goes for Shell scripting in general, actually.

Can you automate the drawing with a script? On X11, you can:

#!/bin/sh

# Position the pointer at the center of the dot, then run this script.

sleep 1

start=$(xdotool getmouselocation --shell)
eval $start

r=400
steps=100
down=0

for step in $(seq $((steps + 1)) )
do
    # pi = 4 * atan(1)
    new_x=$(printf '%s + %s * c(%s / %s * 2 * (4 * a(1)))\n' $X $r $step $steps | bc -l)
    new_y=$(printf '%s + %s * s(%s / %s * 2 * (4 * a(1)))\n' $Y $r $step $steps | bc -l)

    xte "mousemove ${new_x%%.*} ${new_y%%.*}"
    if ! (( down ))
    then
        xte 'mousedown 1'
        down=1
    fi
done

xte 'mouseup 1'
xte "mousemove $X $Y"

Interestingly, you can abuse the scoring system (not manually, only with a script). Since the mouse jumps to the locations along the circle, you can just use very few steps and still get a great score because every step you make is very accurate – but the result looks funny:

🥴

@lyse@lyse.isobeef.org I’m open to other suggestions 🤣 But hopefully both adding the additional prompt, not allowing it to enter shell history and removing from my shell history prevents me from doing such silly things in haste by pressing ^R and using fuzzy search which if you type fast you sometimes get wrong 😑

Then I cleaned up my shell history of all of the invocations I ever made of dkv rm ... to make sure I never ever have this so easily accessible in my shell history (^R):

$ awk '
  /^#/ { ts = $0; next }
  /^dkv rm/ { next }
  { if (ts) print ts; ts=""; print }
' ~/.bash_history > ~/.bash_history.tmp && mv ~/.bash_history.tmp ~/.bash_history && history -r

So I re-write this shell alias that I used all the time alias dkv="docker rm" to be a much safer shell function:

dkv() {
  if [[ "$1" == "rm" && -n "$2" ]]; then
    read -r -p "Are you sure you want to delete volume '$2'? [Y/n] " confirm
    confirm=${confirm:-Y}
    if [[ "$confirm" =~ ^[Yy]$ ]]; then
      # Disable history
      set +o history

      # Delete the volume
      docker volume rm "$2"

      # Re-enable history
      set -o history
    else
      echo "Aborted."
    fi
  else
    docker volume "$@"
  fi
}

@lyse@lyse.isobeef.org Doing the devil’s work:

https://movq.de/v/b895c14411/los86-shell-cursor-history.mp4

Better than nothing. 😅

I’ve never liked the behavior of OpenBSD’s shell where it just scrolls horizontally:

https://movq.de/v/1371f7efbc/vid-1741714971.mp4

But now I’m this close to implementing the same thing in my own shell – because it’s probably much, much easier than multiline stuff. 😅

@prologic@twtxt.net I think printf is a more portable option than echo -e for interpreting \t as tab. E.g. printf ‘%s\t%s\t%s’ “$url” “$time” “$text”. In general I always prefer printf over echo for anything non-trivial in unix shell scripts. See last paragraph of https://en.wikipedia.org/wiki/Echo_(command)#History

Diving into mblaze, I think I’ve nearly* reached peek email geek.

Just a bunch of shell commands I can pipe together to search, list, view and reply to email (after syncing it to a local Maildir).

EXAMPLES at https://git.vuxu.org/mblaze/tree/README

So far I’m using most of the tools directly from the command line, but I might take inspiration from https://sr.ht/~rakoo/omail/ to make my workflow a bit more efficient.

*To get any closer, I think I’d have to hand-craft my own SMTP client or something.

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

• Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

• “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

• Thanks for phrasing the bit about deletions so neutrally.

• I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

• Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

• For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

• Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

• Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

• I’m a little sad about other protocols being not recommended.

• I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

@movq@www.uninformativ.de I don’t know if I’d want to discard the twts. I think what I’m looking for is a command “jenny -g https://host.org/twtxt.txt” to fetch just that one feed, even if it’s not in my follow list. I could wrap that in a shell script so that when I see a twt in reply to a feed I don’t follow, I can just tap a key and the feed will get added to my maildir. I guess the script would look for a mention at the start of a selected twt and call jenny -g on the feed.

@prologic@twtxt.net @jmjl@tilde.green
It looks like there’s a podman issue for adding the context subcommand that docker has. Currently podman does not have this subcommand, although this comment has a translation to podman commands that are similar-ish.

It looks like that’s all you need to do to support podman right now! Though I’m not 100% sure the containers I tried really are running remotely. Details below.

I manually edited the shell script that cas.run add returns, changing all the docker commands to podman commands. Specifically, I put alias docker=podman at the top so the check for docker would pass, and then I replaced the last two lines of the script with these:

podman system connection add cas  "host=tcp://cas.run..."
podman system connection default cas

(that … after cas.run is a bunch of connection-specific stuff)

I ran the script and it exited with no output. It did create a connection named “cas”, and made that the default. I’m not super steeped in how podman works but I believe that’s what you need to do to get podman to run containers remotely.

I ran some containers using podman and I think they are running remotely but I don’t know the right juju to verify. It looks right though!

This means you could probably make minor modifications to the generated shell script to support podman. Maybe when the check for docker fails, check for podman, and then later in the script use the podman equivalents to the docker context commands.

According to the RedMonk programming language rankings from Jan 2023, Go and Scala are tied at 14th place 😏

1 JavaScript
2 Python
3 Java
4 PHP
5 C#
6 CSS
7 TypeScript
7 C++
9 Ruby
10 C
11 Swift
12 Shell
12 R
14 Go
14 Scala
16 Objective-C
17 Kotlin
18 PowerShell
19 Rust
19 Dart

Image

a simple Makefile for forwarding internet to your local machine:

SSH_HOST=https://xuu.me
PRIV_KEY=~/.ssh/id_ed25519
forward:
	LOCAL_PORT=$(HOST_PORT); sh -c "$(shell http --form POST $(SSH_HOST) pub=@$(PRIV_KEY).pub | grep ^ssh | head -1 | awk '{ print "ssh -T -p " $$4 " " $$5 " -R " $$7 " -i $(PRIV_KEY)"  }')"

I have been using Unix for 25+ years and I just learned about the status character in shells (often ^T). Huh.

@prologic@twtxt.net rc, the Plan 9 shell.

Posted to Entropy Arbitrage: Small-D date Night https://john.colagioia.net/blog/2020/03/18/date.html #techtips #programming #shell #date #gnu #linux #calendar