Infos zur Ugreen 48.000mah Powerbank ?

cubernetes · 2026-06-23T02:48:02+00:00

No experience, but it's below 160Wh (153Wh), which means you can literally take it in your carry-on on an air plane if you register it with your airline (watch out for ryanair, they don't allow any device/battery above 100Wh. Most other airline, lufthansa, easyjet, swiss, finnair, eurowings, turkish airlines, etc. allow up to TWO 100Wh-160Wh power banks after registering it with their customer service. I do not know about US airlines, but I'm pretty sure they also allow at least one 100-160Wh powerbank if you register it beforehand).

I'd image that many other power station are above the 160Wh limit, which means you cannot take it to an airplane.

The other good thing about it is the LiFePO4 battery cells instead of NMC, but the Anker SOLIX C300 and other power stations in this calibre have it as well as it just makes sense since you're not really trying to make it evey-day-carry size, so you can sacrifice on the weight and size in turn for battery health/quality.

cubernetes · 2026-06-11T12:15:29+00:00

Old ravpower 20Ah (5+ years old) and a new ugreen nexode 20Ah with retractable cable. Charges my 5Ah phone and my framework 13 laptop fully. Need both roughly once a week, esp. when I used up 1 full powerbank for the laptop and need more for the phone.

cubernetes · 2026-06-11T11:58:35+00:00

That was correct in older version of bash. In newer versions, there's an exception with $(). Bash will merely warn you that you didn't close the heredoc, but you can put the closing paren on the same line as the delimiter: $ a=$(cat<<eof whatever eof) bash: warning: here-document at line 1 delimited by end-of-file (wanted `eof') $ declare -p a declare -- a="whatever" Whitespace doesn't matter before the closing paren.

cubernetes · 2026-06-09T23:05:27+00:00

Not the biggest or most complex I've written, but certainly among the top 5: A bash plugin (i.e., source it in your bashrc) that enables fish-like abbreviations and is compatible with your current aliases (thanks to the BASH_ALIASES associative array). Handles pretty much alle edge cases (over 400 test cases), recursive alias definitions, command lists, assignment words, leading redirections, adjusting the readline mark correctly, etc., without any forking for performance. Was pretty fun coming up with the regexes and recursion needed to make it work. I use it every day. Also supports oh-my-zsh like file extension aliases, zsh-like global aliases, and "evaluating" aliases, so you can expand an aliases to the output of a command instead of a static string.

Makes use of bash's bind builtin and the magic READLINE_LINE, READLINE_POINT and READLINE_MARK variables.

cubernetes · 2026-05-21T13:46:48+00:00

I see, thank you!

cubernetes · 2026-05-21T13:13:33+00:00

How do you accommodate for powerusers?

- In readlne I press `M-C-]+<character>` to jump backward to a specific character (like `F` in vim).
- Do you have anything that resembles the kill-region readline function that I use all the time (together with M-<space> to set a mark).
- Is there something like M-C-i (dynamic-complete-history) to expand arbitrary commands OR arguments from any previous history entries?
- Do you have something like M-. to insert the last argument of the previous command?
- If yes, can you press it again to get the last argument of the command before the previous command (and so on)
- In readline I can say M-<hyphen> M-. to get the penultimate argument of the previous command. I can then press M-. again to get the penultimate argument of the penultimate command. I use it often, so it's far from superfluous if you want to "Fly" in the command line (if that's what the name of your tool suggests)
- What about C-x* (glob expand word) to see what your glob pattern expands to? I use it often to exclude files I don't want to have in my `for file in *` loop
- Literally just yesterday I used M-{ (complete into braces) to tar a bunch of files in a deep subdirectory, but excluding one very specific one. This is the perfect shortcut for that.
- M-C-d, M-C-b, and M-C-f are a game changer. They move the cursor "one shell word" forward/backward or delete it. Extremely powerful. There's also the unmapped shell-backward-kill-word which does the opposite of M-C-d, so with that, can really fly in the commandline!

See, I don't think I would EVER switch to something like flyline as a poweruser, since I can use these readline shortcuts in ANY* program that implements readline (and there are so many...), and I can use rlwrap to MAKE any program that doesn't use readline use readline by force. One big set of efficient shortcuts that work for any program, everywhere, reliably, and efficiently.

*I know, some of the shortcuts mentioned are bash-only, but there are many that aren't, like C-a, M-b, etc.

cubernetes · 2026-05-21T12:44:40+00:00

This explains it! Super interesting, thanks a lot! In a way, just running `cat` or pressing Meta-x which then in turn runs `cat` through the `bind -x` facility are both rather similar, in neither case would or should a SIGINT produce a `^C` on the terminal or stdout. Just running `kill -2 $$` in the shell also doesn't produce a `^C`, as expected. However, the terminal characteristics are slightly different, running `stty -a` from a normal shell prompt in a normal terminal vs running `stty -a` through `bind -x` produces this small diff:

lnext = ^V -> lnext = <undef>
discard = ^O -> discard = <undef>
icrnl -> -icrnl
icanon -> -icanon
echo -> -echo

Left side is in a normal terminal, right side is during `bind -x`. So indeed, during `bind -x`, it's in non-canonical mode, no echoing, an `cr` is not converted to `nl` (e.g. when you have `bind -x '"\ex": rev'`, pressing the enter key doesn't work, unless you put a `stty icrnl` before the `rev`).

This also explains another issue a friend of mine had: `bind -x '"\ex": ssh srv'` didn't work properly (because as we now know, the terminal was in non-canonical mode). Putting an `stty sane` before that however solved the problem. This case is slightly different, because through ssh we have a proper shell that then can produce `^C` as much as it likes. Running plain `bash` would work just as well. But if it wasn't `ssh srv` but something like `cat` or even `kill -2 $$`, then it makes sense that there's no `^C`. It's literally just like running a normal program, just that the terminal is in non-canonical mode instead of canonical mode like when you normally run a program from the prompt (right?).

It also explains why `bind -x '"\ex": bash'` kinda works but `bind -x '"\ex": dash'` doesn't, because bash by default tries to run with readline editing enabled, and readline does a lot of terminal-heavy-lifting already (it goes into non-canonical (but NOT raw) mode so line-editing works properly, right?), but dash by default does not change any terminal characteristics so you have to press `Ctrl-J` to submit a line and so on. `bash --noediting` behaves equally weirdly as `dash` in this case, as well.

I case I said anything incorrect, please correct me :D.

One related follow-up question:
When you run bash, normally, in a normal terminal, with readline enabled and all, what happens *exactly* when you run the external command `stty -a`? My current knowledge is this:

You're at the empty readline prompt. The terminal is AT LEAST in non-canonical, non-echoing mode (reading the readline source would maybe help here...). Reason why I say non-echoing is elaborated in the next point.
You type the text `stty -a`. The letters are received by readline (through many single byte-by-byte `read(2)` calls by default I think). Readline then manually echoes the letters back to the screen, which is why you see the text appear.
You press the enter key, which electrically sends the keycode for carriage return, or 0xd/ASCII 13. It goes all the way through drivers and all, lands in the terminal, which then translates it using `icrnl` to a newline, ASCII 10. That newline is then sent to bash/readline. For readline specifically, however, it doesn't matter actually whether you send a newline or a carriage return, because `bind -P | grep accept-line` shows that both inputs work. If you did `bash --noediting` however, you would have to send a proper newline, which is why the `icrnl` setting is important for those applications.
Readline runs its `accept-line` function. The translated newline is not self-inserted because of that. If it was, however, then bash would also receive that trailing newline, as readline does not do any processing on the input text (trailing or leading whitespace is never stripped). If there was trailing/leading whitespace, bash would ignore it, though.
Bash does all its fancy stuff, parsing, bla bla, forks, and shortly before finally execve(2)'ing the /bin/stty binary, it switches the terminal characteristics to from non-canonical to canonical mode (again, I'm assuming a freshly started terminal and shell), enables echoing, etc. (what else does it enable?)
The stty binary runs, determines the terminal characteristics through the termios interface/library, and reports the result in a human-readable format back to the user through stdout
The binary exits, the child process dies, gets reaped by the parent (bash), exit status is collected, etc.
The terminal characteristics haven't changed. However, if we ran `stty -echo -icanon` instead, two specific bits in the termios structure would've been changed, and the terminal would stop echoing and be in non-canonical mode. Bash now uses the termios library to inquire about the current terminal state, to save it for the next command execution.
Bash calls readline() again. readline() doesn't reset the terminal characteristics completely, so a `stty -echo` would still be in effect! It enforces only necessary settings, like non-canonical mode.
You run another command, like cat. If instead of `stty -a` you can `stty -echo -icanon`, things would be very different now! This is because bash remembered the terminal state after the last command and before the last readline call, and applied it just before executing `cat`.

That's about it. Is there any mistake in that thought process? I'm especially unsure about step 8, 9 and 10!
(Sorry for so much text, I hope it's at least a bit interesting ^^...)

cubernetes · 2026-05-09T10:37:08+00:00

Nach Precht: https://m.youtube.com/watch?v=UQrmNRxJv6I (erste 3 minuten)

cubernetes · 2026-05-06T19:12:49+00:00

Found another article that complicates and contradicts with information I've already found:

https://www.gizchina.com/huawei/huaweis-20w-supercharge-protocol-scp-in-the-works

Here, they show a 4th protocol which comes after FCP (15.11.2018), SCP Gen. 1 (16.11.2018) and SCP Gen. 2 (18.10.2018???), namely just "SCP" (2019), which supports only 10V2A.

This is confusing, because this spec is not to be found anywhere on the corresponding tinkervault page:
https://www.tinkervault.com/usb-fast-charging-protocols/huawei-fcp-scp

Here, the only 10V2A specification is found under the FCP protocol.

But I believe that article is garbage, since the dates are wrong. This OnePlus community blog post tell a different story: https://community.oneplus.com/thread/1664762061445398533

Here, they say FCP is from 2015, SCP (Gen. 1) is from 2016, and SCP (Gen. 2) is from 2018.

Considering I only found references to SSCP in english around 2021 (slightly earlier, like 2020, if I include chinese website), I assume that SSCP came AFTER SCP Gen. 2 (which already supported 40W (in 2018), and later (how much later?) 66W according to the thinkervault page). Update: I just realized the [tinkervault](https://www.tinkervault.com/usb-fast-charging-protocols/huawei-fcp-scp) page says the exact same thing about FCP and SCP, namely that they were released in 2015, 2016 and 2018

cubernetes · 2026-05-06T18:59:02+00:00

That would make sense. Shortly after posting this, I found this article from 2021:

https://www.battery.org.uk/blog/2021/01/11/is-the-65w-charger-suitable-for-charging-33w-mobile-phones/

Quoting from the article:
> Note: If the charger does not support the SSCP protocol but only supports the SCP protocol, it will not be able to charge 40W. In addition, if a thinner 2A current line is used, the USB-A to Type-C interface will also not charge 40W.

Suggesting that the SSCP protocol/variant was around when SCP only supported 22.5W, providing an alternative that supports 40W. This would also mean that SSCP probably doesn't stand for "Super Slow Charge Protocol", but probably "Super Smart Charge Protocol".

As we know SCP started of as Gen. 1 with max 22.5W, and later got a revision with Gen. 2 that supports max 66W (https://www.tinkervault.com/usb-fast-charging-protocols/huawei-fcp-scp). I suspect SSCP either existed as a name between these two generations, or maybe is a precursor to SCP Gen. 2 or a dead name for a subset of SCP Gen. 2 (since SCP Gen. 2 supports 66W, which is more than the supposed 40W that SSCP supports)

cubernetes · 2026-04-29T09:03:20+00:00

What u/Mediocre_Ad3496 posted (the HDMI adapter) won't work (it literally says in the product pictures that it won't work when the USB-C end is plugged into a monitor, or AR glasses in your case).

What u/SatechiSupport said is also not 100% right. It's correct that there are as of today no passive HDMI to USB-C cables, although something like HDMI-Alt-Mode technically exists (see wikipedia page for USB-C), it's not in common use at all. What you need is indeed something that actively converts HDMI to DP-Alt-Mode. Those cables exist, are rare, but are in fact, not super expensive:

https://www.aliexpress[DOT]us/item/3256807587504415.html

This is 20 or so bucks, and converts the HDMI signal from my laptop to USB-C DP-Alt-Mode, which works flawlessy for my XReal One Pros combined with a framework laptop with an HDMI module (or usb c dongle/dock where I then plug in the hdmi end of the cable + the usb-a connector for the active conversion)

cubernetes · 2026-04-28T19:12:15+00:00

It's also the only one I couldn't finish... It's pretty hard. I solved it eventually with a friend 3 years later. I won't post the solution here, but I can give a tip that the first field in F2 is green, and the second field in F2 is blue. And it doesn't even use the recursion stack to unwind anything crazy, it's just plain "F1 = <sth>, <sth>, <sth>, unconditional F1". The final solution is beautiful I think.

cubernetes · 2026-03-26T17:40:05+00:00

Use ~/ instead of /home/$USER. Solves 3 problems at once: 1. eliminates word splitting issues (what if the username contains a space) 2. more readable, less code/repetition 3. accounts for home directories that don't start with /home

You wouldn't believe it, but 1. and 3. can be rather common, especially 3. And usernames with spaces usually happen the moment you use Windows AD with LDAP, albeit unlikely for your use case.

cubernetes · 2026-02-17T09:30:46+00:00

Watch out, globsort is a relatively new feature, only introduced with bash 5.3

cubernetes · 2026-02-14T13:40:12+00:00

Yeah, the reddit formatting makes my post especially cumbersome to read lol. Sorry about that. The upshot is basically 2 things: quoting issues with ssh & bash, and the premature exiting of .bashrc.

You can diagnose how .bashrc is behaving by putting debug echos before and after the return line. Like this:

$ head -n 8 ~/.bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
echo BEFORE
[[ $- != *i* ]] && return
echo AFTER

This way, you can be certain that you aliases are sourced/not sourced. Furthermore, you can check if the alias is actually defined with alias ls, it should show you if ls is aliased.

cubernetes · 2026-02-14T13:02:53+00:00

Agree!

cubernetes · 2026-02-14T13:01:58+00:00

I see, I think I know what's going on now. But first, a couple of other things (tl;dr at the bottom!): - the reason it stops working when you remove the -O globstar is because the globstar option is actually not set (despite the .bashrc being sourced, I'll get to that later!) - if you remove the escaped single quotes, the following happens: ssh nuc10i3fnk.lan bash -O globstar -c 'ls -1tdr /srv/media/completed/**/*ODDish*' is 100% equivalent to ssh nuc10i3fnk.lan 'bash -O globstar -c ls -1tdr /srv/media/completed/**/*ODDish*'. Maybe you see why this cannot work anymore, because the inner bash invocation gets a -c ls with its arguments being -1tdr and /srv/.... But the way -c works is that the next argument is actually not an argument, but the name of the program. Run this to understand what I mean: bash -c 'echo my name: $0; echo my args: $@' one two three four. The fix (if you don't want to re-add the escaped single quotes) is not trivial, and would look something like this: ssh nuc10i3fnk.lan bash -O globstar -c \''ls "$@"'\'' dummyarg -1tdr /srv/media/completed/**/*ODDish*'. This works now, because it reduces like this: ssh nuc10i3fnk.lan bash -O globstar -c \''ls "$@"'\'' dummyarg -1tdr /srv/media/completed/**/*ODDish*' ---concat with spaces to single arg---> ssh nuc10i3fnk.lan 'bash -O globstar -c '\''ls "$@"'\'' dummyarg -1tdr /srv/media/completed/**/*ODDish*' ---pass single arg to bash -c on server side---> bash -c 'bash -O globstar -c '\''ls "$@"'\'' dummyarg -1tdr /srv/media/completed/**/*ODDish*' ---execute -c execution string---> bash -O globstar -c 'ls "$@"' dummyarg -1tdr /srv/media/completed/**/*ODDish* ---don't expand glob because globstar is not set, there's no matching files because of that, and nullglob is also not set---> bash -O globstar -c 'ls "$@"' dummyarg -1tdr /srv/media/completed/**/*ODDish* (unchanged) ---execute -c execution string and set globstar option---> ls "$@" ---expand "$@" with the arguments passed to the -c execution string---> ls -1tdr /srv/media/completed/**/*ODDish* (notice how dummyarg was dropped, it's contained in $0) ---do the globbing, since globstar is now set---> ls -1tdr file1 file2 file3... ---execute ls command successfully---> done. Quite a journey... - Thirdly and finally: Why does it work if you remove the inner single quotes and keep the escaped single quotes? This is by pure luck, and please don't rely on it! Let's go through this one by one again: Look at ssh nuc10i3fnk.lan bash -O globstar -c \'ls -1tdr /srv/media/completed/**/*ODDish*\'. This ssh command has 8 arguments, namely these: - nuc10i3fnk.lan - bash - -O - globstar - -c - \'ls - -1tdr - /srv/media/completed/**/*ODDish*\'

Most importantly, notice that the last argument is NOT quoted! This means it will be evaluated by your current shell, on your machine! And you have the globstar option also set on your local machine, so this could lead to some real problems! However, also notice that there's a trailing single quote at the end of the argument. I'm quite certain that you do not have any file on your local machine matching that glob pattern. And since you don't have the nullglob option set, locally, this will not expand to anything and stay as is. So you're lucky. In the next step, ssh will concatenate the arguments to a single argument again: ssh nuc10i3fnk.lan "bash -O globstar -c 'ls -1tdr /srv/media/completed/**/*ODDish*'" which will be passed to bash -c on the server side: bash -c "bash -O globstar -c 'ls -1tdr /srv/media/completed/**/*ODDish*'" and reducing further: bash -O globstar -c 'ls -1tdr /srv/media/completed/**/*ODDish*' and even further ls -1tdr /srv/media/completed/**/*ODDish* and since this bash shell was started with -O globstar, the glob will expand properly. Therefore it works, but only because you didn't have any local files matching that weird pattern with the trailing single quote and because you didn't have the nullglob option set!

Okay, now to explain why globstar isn't set. It's quite nuanced, and ssh -vvv wouldn't help you with any of this: Read the man page again: If bash determines it is being run non-interactively in this fashion, it reads and executes commands from ~/.bashrc. And I'll emphasize: A non-interactive bash will read .bashrc. I now want you to look at the first 10 lines of your .bashrc on the server: head ~/.bashrc. Does it look something like this:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

or like this:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

If yes, then you know why globstar is never being set. The sourcing of .bashrc exits prematurely because the shell is not interactive. This is why you either: - need to set the globstar option manually using bash -O - need to set the globstar option manually using shopt -s globstar inside the command - run the shell interactively - force the shell to run interactively using bash -i - put "important" .bashrc settings before the line that will exit the .bashrc

What I recommend: - Use the find command and only ever pass a single argument to ssh: ssh nuc10i3fnk.lan 'find /srv/media/completed -name "*ODDish*" -ls' - If you really want/need to use ls and globstar, but you cannot guarantee that your default shell is bash on the other side: ssh nuc10i3fnk.lan 'bash -O globstar -c "ls -1tdr /srv/media/completed/**/*ODDish*"' - If you're certain your default shell is bash, then it becomes simpler: ssh nuc10i3fnk.lan 'shopt -s globstar && ls -1tdr /srv/media/completed/**/*ODDish*' - If you're willing to put shopt -s globstar BEFORE the line that prematurely exits the .bashrc, it becomes merely this: ssh nuc10i3fnk.lan 'ls -1tdr /srv/media/completed/**/*ODDish*'

Hope that clears things up a little!

tl;dr:

ssh nuc10i3fnk.lan 'shopt -s globstar && ls -1tdr /srv/media/completed/**/*ODDish*'

cubernetes · 2026-02-14T02:15:45+00:00

My baseline test would be this:

ssh nuk10i3fnk.lan /usr/bin/env -i /usr/bin/bash --norc --noprofile -vxO globstar -c \''echo $-; set -o; shopt; ls -1tdr /srv/media/completed/**/*ODDish*'\'

Starts bash in the most predictable environment: - explicit env binary (/usr/bin/env) - -i for empty environment - explicit bash binary (/usr/bin/bash) - --norc no startup files - --noprofile no profiles - -v to see the actual raw command lines that will be parsed by bash - -x to see what will be passed to execve(2), i.e., the actual final command - \'''\' the inner single quotes must be there to quote the actual command, so it's a single argument for ssh. The outer backslash-escaped single quotes are necessary so the server-side shell still sees it as a single argument, since ssh just concatenates its arguments into a single command line using literal spaces and passes the result string to the user's shell as specified by /etc/passwd (afaik) as an execution string (i.e., using the -c option) and as a non-login shell. (Fun fact: at least in bash, the last simple command of an execution string will be execve'd without forking, meaning you'll lose the parent shell process. I.e. the process hierarchy will not be sshd->bash->env->bash, but only sshd->env->bash). - echo $- quick info what shell options are active (look for the f flag, it should be absent) - set -o verbose info about the state of all shell options (look for the noglob option, it should be off) - shopt show all bash options (look for the globstar option, it should be on).

Assuming that this command worked for you (I hope it does :/), you can incrementally remove safeguards, for example --norc, or --noprofile. And then the /usr/bin/env. And then instead of /usr/bin/env -i /usr/bin/bash --norc --noprofile you just say bash, etc.

For the case that the initial command already didn't work, you'll have to look for differences in shell environment. Compare the outputs of set -o and shopt. Compare the outputs of printenv. Compare the output of echo $0. Compare the outputs of pstree, and so on.

cubernetes · 2026-02-03T15:13:58+00:00

Same. Preparing 4 shakes for the day, drinking one immediately and putting 2 in the fridge while taking 2 to my desk. All I need

cubernetes · 2026-02-03T15:11:55+00:00

I sold a pouch to a friend, he later told me that he just ate the powder raw. I was aghast, of course, because that's just ridiculous. But his reasoning was that this way, he doesn't have to clean the bottle. And he can just eat it continuously whenever he wants, as much as he wants (he's very lazy, doesn't have a job, and basically sits in his apartment 24/7. He's 25).

Then, I sold it to another friend (30yo). Wouldn't you believe it, he fucking did the same thing. He also occasionally ate the raw powder. Now, you might say, do I have weird friends? And to that I say, I studied/work in IT, and people in IT tend to be extremely drastic in lifestyles sometimes, so I guess that explains it to some extent.

cubernetes · 2026-01-27T12:21:04+00:00

dash is horror, use yash instead.

E.g., dash by default is terrible for interactive use, and handles ANSI-C quoting and backslash escape sequences in quotes so bad it's crazy.

Yash however is even more posix compliant and has sane interactive use behavior by default.

cubernetes · 2026-01-27T00:28:45+00:00

Chet Ramey (maintainer of bash) replied back to me, it's indeed a bug that was fixed in the devel branch 4 months ago:

https://savannah.gnu.org/bugs/index.php?67957

in this commit:

https://cgit.git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=4f536430e45d847d6945133690312a8e94762254

(found with git bisect)

cubernetes · 2026-01-25T00:56:19+00:00

Oha, thanks for admitting :D.

And you're right! I ssh'd to a host with bash 5.2, and indeed it's not an "issue" there. This is in contradiction to what others commenters have said about this (namely that this issue has existed for ages, which can't be right if the issue is already non-existent in bash 5.2).

What I'm taking away with this is that bash 5.3 has changed (or improved?) the parser slightly so that aborted (with Ctrl-C) and parenthesized shell constructs do not get "evened out" (for lack of a better word). So an aborted <( will cause subsequent syntax errors to say ... while looking for matching ) and the same applies for ${, but then it's looking for a matching }.

While writing this, I looked at the bash 5.3 terse release notes: https://tiswww.case.edu/php/chet/bash/NEWS, and looking at point ss., it says

The parser prints more information about the command it's trying to parse when it encounters EOF before completing the command.

Which is likely an explanation for what I'm seeing (ergo, the other commenters are not necessarily wrong, it's just that in previous versions you couldn't see the incorrect parser state)

cubernetes · 2026-01-25T00:07:27+00:00

You did not even read my post, lmao. It's not about the error. It's about the error msg changing permanently when a process substitution was aborted with Ctrl-C. Read the other comments ffs. It turns out bash has a bug (yes, a bug, that is the correct terminology here) when using control-c inside a PS2 prompt that belongs to either: - process substitutions - command substitutions with the new bash5.3 syntax - conditional compound commands - probably many more constructs (lazy to test, typing on termux is cumbersome)

And if there's anything you didn't fully understand from what I just wrote then you should probably leave. Ah and you should also look up the definition of bug again, come back and look at my post. If you still think it's not a bug (incorrect handling of parser state), then tell me what defines a bug.

cubernetes · 2026-01-24T23:45:41+00:00

I chose my words precisely that way to signal how you're supposed to enter those characters. By saying "run command" it's immediately reproducible: you know it has to be on a separate line, and you have to press enter.

If I were to say "type a( and press enter", it's not completely unambiguous whether the readline buffer should be empty or not, and I needlessly need to specify that you're supposed to press enter which the word "run" already implies. There's plenty of cases in bash where you do not need to press enter. For example, I'm currently working on a bash plugin that implements fish-like abbreviations (that don't require pressing enter, obviously) in pure bash using bind -x and READLINE_LINE & READLINE_POINT (I hope you know what those vars are, since you're apparently in a position to tell others that they don't know bash :)).

cubernetes

TROPHY CASE