Activity for alx
| Type | On... | Excerpt | Status | Date |
|---|---|---|---|---|
| Comment | Post #291263 |
I recommend that you minimize the amount of data you need on your computer, and use git for the few files that you still need. That way, you don't need to do this thing, which is painful. (more) |
— | 25 days ago |
| Comment | Post #291214 |
Debian Sid is that thing for me. In some cases I must be cautious and not do some upgrade, but other than that, it's usually fine. I usually do `sudo apt-get update && sudo apt-get upgrade -V`, which is fine (and that would usually be enough in Debian Stable). After that succeeds, in Sid you also ... (more) |
— | about 1 month ago |
| Comment | Post #291205 |
Let's say I send you some private message, let's say a bug report about a vulnerability.
Now, Mallory wants to read that message, and also your reply to it. He may take that message, add himself as Cc (AFAIK, the Cc field is not a protected field; see `crypt_protected_headers_read` in *muttrc*(5)... (more) |
— | about 1 month ago |
| Comment | Post #290837 |
Interesting! Unfortunately, I don't. It's within a release tarball. To be able to run `make dist` from within that tarball, I need to be able to list the files, but release tarballs don't have .git (and shipping an empty git repository within the tarball would be very fishy). (more) |
— | 3 months ago |
| Comment | Post #290386 |
@#57088
What's that `[]()` that you added? (more) |
— | 4 months ago |
| Comment | Post #290386 |
Nice sed(1) regex! It looks obvious after seeing it. (more) |
— | 5 months ago |
| Comment | Post #290322 |
Command substitution `$(...)` already strips the trailing newline. You don't need `-n`.
See <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03>.
Quoting POSIX:
> ... removing sequences of one or more \<newline\> characters at the end of the substitution.... (more) |
— | 5 months ago |
| Comment | Post #290201 |
@#53919
I get an error:
```
setfont: ERROR setfont.c:402 kfont_load_font: Cannot find default font
``` (more) |
— | 6 months ago |
| Comment | Post #290221 |
Most shells don't provide manual pages for their built-ins like exit, but exit(1) is defined by POSIX (The Portable Operating System Interface), and there are POSIX manual pages.
On Debian:
```
$ apt-file find /exit.1;
fish-common: /usr/share/fish/man/man1/exit.1
manpages-posix: /usr/share/m... (more) |
— | 6 months ago |
| Comment | Post #290204 |
Here are the drives I own:
- USB: <https://www.amazon.es/gp/product/B08H8GNGCZ>
```sh
$ time (sudo dd if=/dev/zero of=/dev/sdb bs=1MiB status=progress; sync)
33303822336 bytes (33 GB, 31 GiB) copied, 156 s, 213 MB/s
dd: error writing '/dev/sdb': No space left on device
31785+0 records in
... (more) |
— | 6 months ago |
| Comment | Post #290204 |
I'm very happy about it! Thanks for the question! :) (more) |
— | 6 months ago |
| Comment | Post #290201 |
Yes, as @Canina pointed out, I was trying to keep the Fixed font. I didn't check that other fonts had more sizes. It is indeed the simplest solution. (more) |
— | 6 months ago |
| Comment | Post #290203 |
The winner to my taste has been `Lat15-Terminus32x16.psf.gz`.
Heh, only caveat is I prefer the Fixed font. But size matters! I wish there was a large version of it. :)
As you said, I don't trust passing the kernel a different resolution. (more) |
— | 6 months ago |
| Comment | Post #290201 |
My default font is 8x16, and the largest one I can choose is 8x18. which I don't think will make much of a difference. Also, will it change the rectangle size, or will it just have less space between letters? That might even be negative to readability. (more) |
— | 6 months ago |
| Comment | Post #290119 |
Re: `\` and `|`: I agree that the `\` is a bit ugly. However, I find it less readable if the pipe symbol goes to the right. It's usually something very important, so I prefer it as the first symbol. I wish sh(1) had mandatory semicolons like C, so that escaping newlines wouldn't have been necessar... (more) |
— | 6 months ago |
| Comment | Post #290009 |
@#57088 No problem. Nitpicking helps get even better answers, or just random useful info. :)
You may find it interesting that find(1), because of the library it uses for name filtering, is very slow, and grep(1), even with the overhead of a new fork(2), outperforms find(1) very easily. You can ... (more) |
— | 6 months ago |
| Comment | Post #290119 |
It is a standalone program (actually, a shell script) that is designed to search through C code.
Here's the source code: <https://www.alejandro-colomar.es/src/alx/alx/grepc.git/tree/bin/grepc>
I would love to see it being used by other people and get bug reports! :-)
Feel free to email me for... (more) |
— | 6 months ago |
| Comment | Post #290136 |
Since you write the code, you can tell your kernel that no program can create such files. Or maybe you can program it so that only root can create such files. Or maybe programs that have some capability (read <https://man7.org/linux/man-pages/man7/capabilities.7.html>).
Regarding the question of... (more) |
— | 6 months ago |
| Comment | Post #290136 |
If you fear that attackers may create files by physically writing 0s and 1s into your drive, you can encrypt the drive. If it's encrypted, you can remain sure that the only way to add files to your drive is via software, and only if you know the key.
This also removes the possibility that someone... (more) |
— | 6 months ago |
| Comment | Post #290136 |
While a kernel could theoretically have backdoors creating such files anywhere in the millions of lines of code, it usually only has one (or a few at most) place where filenames are validated.
We assume you trust the code in your kernel, because otherwise why would you use it? If you don't trust ... (more) |
— | 6 months ago |
| Comment | Post #290136 |
If you modify gnome, an attacker could create files by calling system calls directly.
You need to modify the kernel if you really want to block any software from creating files with certain characters. (more) |
— | 6 months ago |
| Comment | Post #290119 |
If you make it configurable, so that it is disabled by default and can be enabled for users that want it, maybe you could convince kernel maintainers to merge the feature. (more) |
— | 6 months ago |
| Comment | Post #290113 |
@#8049
Maybe a safe assumption is that it would be on Linux, given the name of the server. :) (more) |
— | 6 months ago |
| Comment | Post #290009 |
> All *nix systems accept everything except / and \0 in file names.
And great news, POSIX may outlaw `\n` (and a few more) soon: <https://www.austingroupbugs.net/view.php?id=251>. (more) |
— | 7 months ago |
| Comment | Post #288401 |
To add a bit more to this:
POSIX.1-202x (Issue 8) is considering outlawing `\n` (actually, characters 1 through 31) in filenames.
See <https://www.austingroupbugs.net/view.php?id=251>.
And the POSIX portable filename character set already limits the characters that one should want to use in ... (more) |
— | 7 months ago |
| Comment | Post #290009 |
> Why not `find . -type f -name '*-min.jpg-*' -print0` to avoid the `grep`?
Because the grep(1) is so much simpler conceptually. I don't need to remember of all the options from find(1) that can be used for file names (`-ilname`, `-iname`, `-ipath`, `-iregex`, `-iwholename`, `-lname`, `-name`, `-... (more) |
— | 7 months ago |
| Comment | Post #290009 |
> All *nix systems accept everything except `/` and `\0` in file names.
That's true for the kernels. Individual programs may or may not. When writing scripts like this one (which I do often), it helps not having to consider such insane file names. Usual *nix filters do not like non-portable fil... (more) |
— | 7 months ago |
| Comment | Post #290009 |
> And there is no reason to assume the random string will only have alphanumerical values.
That was my inductive guess from the small sample. If it's different, the regex could be adjusted to fit. The good thing of using `[[:alnum:]]` is that it self-documents, so any mismatches will be easily d... (more) |
— | 7 months ago |
| Comment | Post #288436 |
`generate_lists | xargs some_program` works just as well, and it can pack several arguments into a single program invocation, being faster. In fact, find(1) is just a special case of `generate_lists`, so xargs(1) works in both cases better (the syntax is way simpler). (more) |
— | 7 months ago |
| Comment | Post #289936 |
Step 2 is conflating two functions:
- Finding all files in every dir.
- Filtering the previous step to just keep the first 3.
The former should be `find $dir -type f -maxdepth 1`.
The latter should be `head -n3`, maybe coupled with a `sort`, depending on what we understand by "first". (more) |
— | 7 months ago |
| Comment | Post #289936 |
```sh
$ dpkg -l | grep -e moreutils -e fd-find
ii fd-find 8.7.0-3+b1 amd64 Simple, fast and user-friendly alternative to find
ii moreutils 0.67-1 amd64 addition... (more) |
— | 7 months ago |
| Comment | Post #289936 |
```sh
$ find
.
./l1
./l1/l2
./l1/l2/f2
./l1/l2/f5
./l1/l2/f4
./l1/l2/d0
./l1/l2/d0/f2
./l1/l2/d0/f5
./l1/l2/d0/f4
./l1/l2/d0/f3
./l1/l2/d0/f1
./l1/l2/d0/f0
./l1/l2/f3
./l1/l2/d5
./l1/l2/d5/f2
./l1/l2/d5/f5
./l1/l2/d5/f4
./l1/l2/d5/f3
./l1/l2/d5/f1
./l1/l2/d5/f0
./l1/l2/d4
./l1... (more) |
— | 7 months ago |
| Comment | Post #289899 |
Thanks! That makes sense. (more) |
— | 7 months ago |
| Comment | Post #289899 |
Why set `lines=` to empty before entering the alternate screen? (more) |
— | 7 months ago |
| Comment | Post #289899 |
Why are the two trap(1) calls at different locations? (more) |
— | 7 months ago |
| Comment | Post #289899 |
Makes sense. Thanks! (more) |
— | 7 months ago |
| Comment | Post #289899 |
Thanks Kamil! Makes sense.
@quasimodo, no, that would have the same problems as my suggestion. (more) |
— | 7 months ago |
| Comment | Post #289899 |
Why do you need the `echo x` trick? What happens without it?
I think this would be simpler:
```sh
...
lines="$(tee /dev/tty | tail -n "$n")"
leave
printf '%s\n' "$lines"
```
Am I missing anything?
(more) |
— | 7 months ago |
| Comment | Post #289899 |
What's the reason for redirecting the whole `enter()` and `leave()` functions to /dev/tty?
Do both setterm(1) and tput(1) need to be redirected? Or is it only necessary to redirect one of them? (more) |
— | 7 months ago |
| Comment | Post #289875 |
Thanks!
Just a minor nitpick: `$COLUMNS` is not available (unless I export it manually). I replaced it with `tput cols`:
```sh
$ cat /usr/local/bin/ovr
#!/bin/sh
sed "s/^\(.\{,$(tput cols)\}\).*$/\1/;2,\$s/^/\x1B[1A\x1B[K/";
```
(see <https://stackoverflow.com/a/263900>) (more) |
— | 7 months ago |
| Comment | Post #289799 |
Yep. I hoped there was a way that I didn't find, but it seems the way is brute force. (more) |
— | 7 months ago |