HN user

ilyagr

1,046 karma
Posts10
Comments304
View on HN

Now the readme says

"Note: Any command not mentioned is included in this suite. "

which I found quite confusing. It's a very large set, potentially infinite depending on what the universe of all commands is :)

You should link to the list of all the commands in your package.

Actually, it would be more correct to do

    echo '^q toggle-option -redraw-on-quit\nq' >> ~/.config/lesskey
The original version I suggested works too, but by accident. `redraw-on-quit` is the actual option name.

(I'd edit my original message, but it's too late for that)

----

Also, note that if you put `--redraw-on-quit` into your `LESS` config (and not `-X`), and set up `^q` as above, things will still work but with flipped behavior of `q` and `^q`.

If your version of `less` is new enough, I believe that the `--redraw-on-quit` behavior is in every way (slightly) better than the `-X` behavior. In addition to the above, some terminals have special behaviors in alternate screen (like converting mouse wheel to up/down keys), which `--redraw-on-quit` will preserve.

There's a way to make `^q` quit `less` and not clear the screen (like `less -X`), while `q` quits `less` and clears the screen (like normal `less`).

1. Do `echo '^q toggle-option -redraw-screen\nq' >> ~/.config/lesskey`

2. Make sure `less` is invoked without `-X` (or with `-+X` if you want to be sure).

This `^q` command is particularly useful for `git log` output and other things where you might need to refer back to them in the next terminal command you do. (In fact, `git` uses `less -FRX` by default, so you'd need to override its config to use `less -FR` instead for the above to work as intended). The `q` command is useful when you don't want to lose what you had on the screen before invoking `less`.

Take Two: Eshell 1 year ago

Is <https://github.com/trapd00r/vidir> the same as `vidir` from <https://joeyh.name/code/moreutils/>?

Shout out to moreutils, there are many nice utilities, and there's a `moreutils` package in most distributions.

Update: Looking at the authors listed in the man pages, the `trapd00r` version looks to be a fork of the moreutils version. Not sure how the functionality compares. Both versions seem to have been updated since the fork.

If you search the code, they support Rosetta, which means an ARM Linux kernel running x86 container userspace with Rosetta translation. Linux kernel can be told to use a helper to translate code using non-native architecture.

Actually, they explain it in detail here: https://github.com/apple/containerization/issues/70#issuecom...

It's unclear whether this will keep being supported in macOS 28+, though: https://github.com/apple/container/issues/76, https://www.reddit.com/r/macgaming/comments/1l7maqp/comment/...

An intelligence that reasons this way would be, in human terms, batshit insane and completely immoral. So, it seems unlikely that many or maybe any humans would experience it as "otherwise benign" if it had power over their lives.

And if we do get an all-powerful dictator, we will be screwed regardless of whether their governing intelligence is artificial or composed of a group of humans or of one human (with, say, powerful AIs serving them faithfully, or access to some other technology).

Ah, apparently with real t-strings, `t"SELECT {a-1}"` should be allowed while `t"SELECT {}"` is not.

Here is Python master branch:

    Python 3.15.0a0 (heads/main:ea2d707bd5, May 16 2025, 12:20:56) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> t"Hello {a}"
    Traceback (most recent call last):
      File "<python-input-1>", line 1, in <module>
        t"Hello {a}"
                 ^
    NameError: name 'a' is not defined
    >>> a=3
    >>> t"Hello {a+5}"
    Template(strings=('Hello ', ''), interpolations=(Interpolation(8, 'a+5', None, ''),))
    >>> t"Hello {}"
      File "<python-input-6>", line 1
        t"Hello {}"
                 ^
    SyntaxError: t-string: valid expression required before '}'

Both already possible, they have official symbols representing them.

I'm not sure what you mean. For an illustration, my terminal does not print anything for them.

    $ printf "qq\36\37text\n"
    qqtext
*Update/Aside:* "My terminal", in this case, was `tmux`. Ghostty, OTOH, prints spaces instead of RS or US.

Unicode does have some symbols for every non-printable ASCII character, which you can see as follows with https://github.com/sharkdp/bat (assuming your font has the right characters, which it probably does):

    $ printf "qq\36\37text\n" | bat -A --decorations never
    qq␞␟text␊
Here, `␞` is https://www.compart.com/en/unicode/U+241E, one of the symbols for non-printable characters that Unicode has; different fonts display it differently. See also https://www.compart.com/en/unicode/block/U+2400.

Is there some better representation it has?

It's a clever format, especially if the focus is on machines generating it and humans or machines reading it. It might even work for humans occasionally making minor edits without having to load the file in the spreadsheet.

I think it can encode anything except for something matching the regex `(\t+\|)+` at the end of cells (*Update:* Maybe `\n?(\t+\|)+`, but that doesn't change my point much) including newlines and even newlines followed by `\` (with the newline extension, of course).

For a cell containing `cell<newline>\`, you'd have:

    |cell<tab>|
    \\<tab   >|
(where `<tab >` represents a single tab character regardless of the number of spaces)

Moreover, if you really needed it, you could add another extension to specify tabs or pipes at the end of cells. For a POC, two cells with contents `a<tab>|` and `b<tab>|` could be represented as:

    |a<tab  ><tab>|b
    ~tab pipe<tab>|tab pipe
(with literal words "tab" and "pipe"). Something nicer might also be possible.

*Update:* Though, if the focus is on humans reading it, it might also make sense to allow a single row of the table to wrap and span multiple lines in the file, perhaps as another extension.

I don't think popularizing these ASCII characters would solve the problem in its entirety.

If RS and US were in common use, there would be a need to have a visible representation for them in the terminal, and a way to enter RS on the keyboard. Pretty soon, strings that contain RS would become much more common in the wild.

Then, one day somebody would need to store one of those strings in a table, and there would be no way to do so without escaping.

I do think that having RS display in the terminal (like a newline followed by some graphic?) and using it would be an improvement over TSV's use of newline for this purpose, but considering that it's not a perfect solution, I can understand why people are not overly motivated to make this happen. The time for this may have been 40+ years ago when a standard for how to display or type it would be feasible to agree upon.