So, ls -R is a command I use a lot to quickly verify the file structure of my projects, or check for any leftover files, as it's simple enough to use and read, and is part of coreutils (which means I don't need to install anything, as it's already available on all distros). However, lately, my projects have grown more complex, having more and more files and sub-directories, and sub-directories of sub-directories, which I don't care about at all. Using ls -RI "PATTERN" used to work well, but now I'm facing an issue where there are files matching a specific pattern that I want to ignore in one specific directory, but not in the other, and vice versa. The problem is that ls -I "PATTERN" seems to look for the shell PATTERN in name of the file, rather than its full path, which makes it impossible to do something like ls -R "subdir/file.a", as the name of the file I'm trying to ignore here is "file.a", and not "subdir/file.a" (which is its path). In short, **is there any way to make** ls -I **look for the pattern in the full path of the file, instead of only its name, or is there any coreutils equivalent command that would allow me to do that without losing much human readability?** --- Here's a quick example to illustrate my problem: 1. File structure:

.
    ├── subdir1
    │   ├── file.a
    │   └── file.b
    └── subdir2
        ├── file.a
        └── file.b

2. What I want:

.:
    subdir1    subdir2
    
    ./subdir1:
    file.a
    
    ./subdir2:
    file.b

3. What I get with ls -ARIsubdir1/file.b -Isubdir2/file.a:

.:
    subdir1  subdir2
    
    ./subdir1:
    file.a	file.b
    
    ./subdir2:
    file.a	file.b

I am trying to better understand printf so I read multiple pages on this command, but I also stumbled upon different behavior of %q directive. Namely, stated on this page : > What is the difference between printf of bash shell, and /usr/bin/printf? The main difference is that the bash built-in printf supports the %q format specifier, which prints escape symbols alongside characters for safe shell input, while /usr/bin/printf does not support %q. *** It behaves different, but I may not fully understand what the sentence means. The following is *different*, yet I think equally effective:

info printf | grep -A 4 '%q'

> An additional directive %q, prints its argument string in a format that can be reused as input by most shells. Non-printable characters are escaped with the POSIX proposed $'' syntax, and shell metacharacters are quoted appropriately. This is an equivalent format to ls --quoting=shell-escape output.

$ touch 'printf testing %q.delete'
# no output

$ \ls -l printf\ testing\ %q.delete
-rw-rw-r-- 1 vlastimil vlastimil 0 Jun 15 23:21 'printf testing %q.delete'

$ /usr/bin/printf '%q\n' printf\ testing\ %q.delete
'printf testing %q.delete'

$ printf '%q\n' printf\ testing\ %q.delete  # Bash builtin
printf\ testing\ %q.delete

*** Can anyone elaborate on these differences, maybe adding in which scenarios it is advised to use this or that one? Thank you.

I have to finish a writeup of a few coreutils commands for a course at the moment, and I can't think of a starting point for a small practical code example that demonstrates the potential uses of stdbuf. Has anyone used it to fix the interaction of a couple specific unix commands? I know what it does. It's just that the first commands that came to mind have their own buffering controls, and normal terminal output is line buffered anyway. It must be popular for appending to logs, yet I can't find a good command to demonstrate there. In the case of nohup, are there any commands that are commonly run with it to prevent interruption? As I mentioned, I am working on this for a course assignment at the moment. This however doesn't violate any of its rules. I'm just trying to find a good starting point for these examples. I don't have one for stdbuf, and I dislike the rudimentary one I was using for nohup.

I observe that, on Ubuntu 24.04.2 with coreutils version 9.4-3ubuntu6, running:

bash
$ tail -c 4097 /dev/zero
$ echo $?
0

exits immediately with a status code of 0. I expected the command to block indefinitely since /dev/zero is an endless stream. In contrast, the following commands behave as expected (i.e., they block until interrupted):

bash
$ tail -c 4096 /dev/zero
^C
$ echo $?
130
$ cat /dev/zero | tail -c 4097
^C
$ echo $?
130

## Debug attempt The strace output shows differences between the two invocations: | strace tail -c 4096 /dev/zero | strace tail -c 4097 /dev/zero | |---------------------------------------------------------------------|---------------------------------------------------------------------| | … | … | | close(3) = 0 | close(3) = 0 | | openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 | openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 | | fstat(3, {st_mode=S_IFCHR\|0666, st_rdev=makedev(0x1, 0x5), …}) = 0 | fstat(3, {st_mode=S_IFCHR\|0666, st_rdev=makedev(0x1, 0x5), …}) = 0 | | lseek(3, -4096, SEEK_END) = 0 | lseek(3, -4097, SEEK_END) = 0 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | read(3, "\0\0\0\0\0\0\0\0\0\\…, 4097) = 4097 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | fstat(1, {st_mode=S_IFIFO\|0600, st_size=0, …}) = 0 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | write(1, "\0\0\0\0\0\0\0\0\0\\…, 4096 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | close(3) = 0 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | write(1, "\0", 1) = 1 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | close(1) = 0 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | close(2) = 0 | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | exit_group(0) = ? | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | ~~+~~ exited with 0 ~~+~~ | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | | | read(3, "\0\0\0\0\0\0\0\0\00"…, 8192) = 8192 | | | … | |

I read the --help text for mktemp recently (the man page wasn't available) and came upon this: -u, --dry-run do not create anything; merely print a name (unsafe) Why is this "unsafe"? Is there any specific reason for this being marked as such?

Before you hit me with the obvious, I know, the backup option makes a backup of a file. But the thing is, the cp command in general backs up a file. One could argue a copy of a file is a backup. So more precisely, my question is this: what does the -b option do that the cp command doesn't do already? The cp(1) man page gives the following description of the --backup option: > make a backup of each existing destination file This definition isn't very useful, basically saying "the backup option makes a backup". This gives no indication as to what -b adds to the cp I know -b puts some suffix at the end of the name of the new file. But is there anything else it does? Or is that it? Is a -b backup just a cp command that adds something to the end of the filename? P.S. Do you typically use -b when making backups in your daily work? Or do you just stick to -a?

I want to copy a single file if (and only if) the destination does not exist. The source file changes rarely, maybe once a month. The destination almost never exists. Are there any differences between the -n and -u options? (Or both!) cp is being called directly from crond. No othercp options are used. The same cron job is called on several machines at the same time, reading from the same source and writing to the same destination (both on a shared GFS global file system). The destination file will be moved shortly thereafter by another process, so the only time it could exist is during the race when the cron job executes simultaneously on several nodes. Which would be more efficient? : * cp -n source dest * cp -u source dest * cp -nu source dest * cp -pu source dest I'm currently leaning towards the simple -n alternative.

Why is GNU Coreutil's dd unable to read /proc/pid/mem? PHP is able to read it, check this:

$ dd if=/proc/357668/mem bs=100 skip=93824992231424 count=1 iflag=fullblock
dd: /proc/357668/mem: cannot skip to specified offset
dd: error reading '/proc/357668/mem': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 4.4742e-05 s, 0.0 kB/s
$ php -r '$h=fopen("/proc/357668/mem","rb");
var_dump(fseek($h,93824992231424));
var_dump(fread($h,100));'
int(0)
string(100) "^?ELF^B^A^A^C^@^@^@^@^@^@^@^@^C^@>^@^A^@^@^@^X^S^@^@^@^@^@@^@^@^@^@^@^@^@P*X^@^@^@^@^@^@^@^@^@@^@8^@^M^@@^@^^^@^]^@^F^@^@^@^D^@^@^@@^@^@^@^@^@^@^@@^@^@^@^@^@^@^@@^@^@^@^@^@^@^@^B^@^@"

here is strace of dd:

sudo strace dd if=/proc/357668/mem bs=1 skip=93824992231424 count=1 iflag=fullblock
execve("/usr/bin/dd", ["dd", "if=/proc/357668/mem", "bs=1", "skip=93824992231424", "count=1", "iflag=fullblock"], 0x7fffffffe528 /* 15 vars */) = 0
brk(NULL)                               = 0x555555567000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7fbd000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=76631, ...}) = 0
mmap(NULL, 76631, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7faa000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\243\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=2125328, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2170256, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff7d98000
mmap(0x7ffff7dc0000, 1605632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7ffff7dc0000
mmap(0x7ffff7f48000, 323584, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b0000) = 0x7ffff7f48000
mmap(0x7ffff7f97000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1fe000) = 0x7ffff7f97000
mmap(0x7ffff7f9d000, 52624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f9d000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7d95000
arch_prctl(ARCH_SET_FS, 0x7ffff7d95740) = 0
set_tid_address(0x7ffff7d95a10)         = 364648
set_robust_list(0x7ffff7d95a20, 24)     = 0
rseq(0x7ffff7d96060, 0x20, 0, 0x53053053) = 0
mprotect(0x7ffff7f97000, 16384, PROT_READ) = 0
mprotect(0x555555565000, 4096, PROT_READ) = 0
mprotect(0x7ffff7ffb000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7ffff7faa000, 76631)           = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGUSR1, {sa_handler=0x5555555589f0, sa_mask=[INT USR1], sa_flags=SA_RESTORER, sa_restorer=0x7ffff7ddd320}, NULL, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x5555555589e0, sa_mask=[INT USR1], sa_flags=SA_RESTORER|SA_NODEFER|SA_RESETHAND|0xffffffff00000000, sa_restorer=0x7ffff7ddd320}, NULL, 8) = 0
getrandom("\xbe\x2a\x3f\x3b\xa5\xd1\xca\xdc", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0x555555567000
brk(0x555555588000)                     = 0x555555588000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2996, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=258, ...}) = 0
mmap(NULL, 258, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fbc000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=27028, ...}) = 0
mmap(NULL, 27028, PROT_READ, MAP_SHARED, 3, 0) = 0x7ffff7fb5000
close(3)                                = 0
futex(0x7ffff7f9c72c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fb4000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=47, ...}) = 0
mmap(NULL, 47, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fb3000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fb2000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=62, ...}) = 0
mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fb1000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_PAPER", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0
mmap(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fb0000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=48, ...}) = 0
mmap(NULL, 48, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7faf000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=270, ...}) = 0
mmap(NULL, 270, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fae000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1406, ...}) = 0
mmap(NULL, 1406, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fad000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3360, ...}) = 0
mmap(NULL, 3360, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fac000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=50, ...}) = 0
mmap(NULL, 50, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fab000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=360460, ...}) = 0
mmap(NULL, 360460, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7d3c000
close(3)                                = 0
openat(AT_FDCWD, "/proc/357668/mem", O_RDONLY) = 3
dup2(3, 0)                              = 0
close(3)                                = 0
lseek(0, 0, SEEK_CUR)                   = 0
lseek(0, 93824992231424, SEEK_CUR)      = 93824992231424
fstat(0, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
write(2, "dd: ", 4dd: )                     = 4
write(2, "/proc/357668/mem: cannot skip to"..., 49/proc/357668/mem: cannot skip to specified offset) = 49
write(2, "\n", 1
)                       = 1
read(0, "\177", 1)                      = 1
write(1, "\177", 1)                     = 1
close(0)                                = 0
close(1)                                = 0
write(2, "1+0 records in\n1+0 records out\n", 311+0 records in
1+0 records out
) = 31
write(2, "1 byte copied, 0.000602349 s, 1."..., 381 byte copied, 0.000602349 s, 1.7 kB/s) = 38
write(2, "\n", 1
)                       = 1
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

here is strace of php: https://pastebin.com/raw/9pacX2Q9 (warning: 190kb)

On Msys2 env.: $ cd /c/msys64/mingw64/lib/ $ ln -s libz.dll.a libzlib.dll.a But confusingly why ln command did copy instead of linking it symbolically ? $ ls -l libz* -rw-r--r-- 1 abdu None 108700 Jan 23 2024 libz.a -rw-r--r-- 1 abdu None 65914 Jan 23 2024 libz.dll.a -rw-r--r-- 1 abdu None 65914 Jan 23 2024 libzlib.dll.a -rw-r--r-- 1 abdu None 2298 Dec 13 03:15 libzoneoc.a Please one help out of confusion to solution

I've been thinking about discontinuing the use of GNU Coreutils on my Linux systems, but to be honest, unlike many other GNU components, I can't think of any alternatives *(on Linux)*. What alternatives are there to GNU coreutils? will I need more than one package? Links to the project are a must, bonus points for naming distro packages. Also please don't suggest things unless you *know* they work on Linux, and can reference instructions. I doubt I'll be switching kernels soon, and I'm much too lazy for anything much beyond a straightforward ./configure; make; make install. I'm certainly not going to hack C for it. ***warning:** if your distro uses coreutils removing them could break the way your distro functions. However not having them be first in your $PATH shouldn't break things, as most scripts should use absolute paths.*

### Short version I would like to create a tabular display of multiline text, similar to the following: all Build all targets document Create documentation of source files in the subfolders src and script, and write it to man test Run unit tests At the moment, my input for this looks as follows, but this can of course be changed: all---Build all targets document---Create documentation of source files in the subfolders src and script, and write it to man test---Run unit tests I’ve tried achieving this with a combination of awk and wrap/pr but while the line wrapping works, the indentation doesn’t. Here’s my current approach: … | awk -F '---' "{ printf '%-10s %s\n', $1, $2 }" \ | fold -w $(($COLUMNS - 1)) -s It generates the output all Build all targets document Create documentation of source files in the subfolders src and script, and write it to man test Run unit tests … in other words, the third line isn’t indented as intended. **How can I format the text with a given wrap length and a given hanging indent width?** — Without changing anything else about the text. Bonus: this should work with UTF-8 and escape/control characters. --- ### Background info The goal is to create [self-documenting Makefiles](https://gist.github.com/klmr/575726c7e05d8780505a) . As a consequence, the logic to format and display the code should be small, self-contained, and not rely on separately installed software; ideally, it should work on any system that can execute Makefiles, hence my restriction to (something close to) coreutils. That said, I briefly tried solving the problem using groff but this became too complex very quickly (and OS X groff is and old version that doesn’t seem to support UTF-8). The *original string* that I’m trying to parse and format therefore looks rather as follows: ## Build all targets all: test document ## Run unit tests test: ./run-tests . ## create documentation of source files in the subfolders src and script, ## and write it to man document: ${MAKE} -C src document ${MAKE} -C script document At the moment, this is parsed using a sed script (see link for details) that ignores multiline comments, before being fed to the formatting code posted above.

I have a Debian 12 system, which is console-only, without a graphical interface / Desktop environmen. I turned off the screen using setterm --blank force on the device itself, and now I can't turn it back on by pressing a key because force causes keyboard input to be ignored. I have access via SSH over a Debian 12 Desktop environment, but when I enter setterm -blank 0 through SSH as root, I get the message terminal xterm-256-color does not support --blank. I also can't switch between different TTYs on the device itself. Even when I switch to a TTY on the Debian desktop and use setterm --blank 0, I don't get any error message, but nothing happens. With setterm --blank poke, I get cannot force unblank. Is there another command from the core utilities that I can use to wake the screen up **without installing additional tools**? Otherwise, I'll just reboot.

I would like to get a list of all the places in a large file where the keys decrease from a previous line. I can check if the file is sorted using sort: sort -cns -k1.14,1.15 -k1.1,1.10 file.txt But it only tells me about the first failure to be sorted (sort: file.txt:42: disorder: .) Can I get it to continue, and tell me about further disorders in the file?

Scenario:

# on Linux
$ cat r456.txt
e+e+l
e+e-c

$ cat r456.txt | sort
e+e-c
e+e+l

$ sort --version
sort (GNU coreutils) 8.30

# on Cygwin
$ cat r456.txt
e+e+l
e+e-c

$ cat r456.txt | sort
e+e+l
e+e-c

$ sort --version
sort (GNU coreutils) 9.0
Packaged by Cygwin (9.0-1)

Here we see that sort on Linux and on Cygwin returns different results. Why? How to make sort on Linux and on Cygwin return the same results? --- UPD. Locales:

# on Linux
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

# on Cygwin
$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

--- UPD2. I've changed all locales on Cygwin to en_US.UTF-8. However, sort still returns different results:

# on Linux
$ cat r456a.txt
u1
u-1

$ cat r456a.txt | sort
u-1
u1

# on Cygwin
$ cat r456a.txt
u1
u-1

$ cat r456a.txt | sort
u1
u-1

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8

How to fix? --- UPD3. Observation: on both Linux and Windows all LC variables are set to en_US.UTF-8, strings to sort are:

ProfileDataContainer.cpp
ProfileData.cpp

Linux sort sorts them as

ProfileDataContainer.cpp
ProfileData.cpp

Cygwin sort sorts them as

ProfileData.cpp
ProfileDataContainer.cpp

Is it a bug in Linux sort or in Cygwin sort? How to make Linux sort produce the same results as Cygwin sort? Versions: Linux sort: 8.32, Cygwin sort: 9.0. Both are GNU coreutils.

I have a multi-gigabyte text file and I want to replace all occurrences of utf8mb4_0900_ai_ci in it with utf8mb4_unicode_520_ci. Usually, I’d use sed -i for this as suggested here: https://unix.stackexchange.com/questions/272052/find-and-replace-a-string-in-a-file-without-using-temp-file-with-sed However, this creates a temp file under the hood and I need this replacement to occur in an environment that won’t have the disk space to support that. How can I modify the file in-place?

I have a script equijoin2: #! /bin/bash # default args delim="," # CSV by default outer="" outerfile="" # Parse flagged arguments: while getopts "o:td:" flag do case $flag in d) delim=$OPTARG;; t) delim="\t";; o) outer="-a $OPTARG";; ?) exit;; esac done # Delete the flagged arguments: shift $(($OPTIND -1)) # two input files f1="$1" f2="$2" # cols from the input files col1="$3" col2="$4" join "$outer" -t "$delim" -1 "$col1" -2 "$col2" <(sort "$f1") <(sort "$f2") and two files $ cat file1 c c1 b b1 $ cat file2 a a2 c c2 b b2 Why does the last command fail? Thanks. $ equijoin2 -o 2 -d " " file1 file2 1 1 a a2 b b1 b2 c c1 c2 $ equijoin2 -o 1 -d " " file1 file2 1 1 b b1 b2 c c1 c2 $ equijoin2 -d " " file1 file2 1 1 join: extra operand '/dev/fd/62'

Trying to show setgid in a different color and failing. tried with the minimum: LS_COLORS="sg:41;41" ls -la --color=auto But still got regular directory colors for a setgid (chmod g+s) directory. Then tried with dircolors, first outputed the "template" with dircolors -p > ~/.dircolors, edited only the setgid line, and eval $(dircolors -b ~/.dircolors)

# ~/.dircolors
…
SETGID 30;44 # file that is setgid (g+s)                                                                                                                              
…

it produces:

env | grep LS_
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;44:ca=00:tw=30;42:ow=30;44;01:st=30;44;01:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:

tried more obvious colors 41;41 (red on red) but nothing. It does works fine for *files*, just not for *directories*. Here are some screenshots. D1 is a dir with setgid. same with tree just to make sure this is not something isolated to ls on the tests above I use su too, because both su and sg are gnu bash extensions not available on other shells.

$ bash --version
GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

$ ls --version
ls (GNU coreutils) 9.5
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .

What might be a reason that BSD cp and find don't "like" a trailing slash for directory names?

|     |            cp            |            mv            |
|-----|--------------------------|--------------------------|
|     | # to copy dir1/ contents |                          |
|     | cp -a dir1/* dir2/       | # to move dir1/ contents |
| GNU |                          | mv dir1/* dir2/          |
|     | # to copy dir1/ itself   |                          |
|     | cp -a dir1/ dir2/        | # to move dir1/ itself   |
|-----|--------------------------| mv dir1/ dir2/           |
|     | # to copy dir1/ contents | # mv dir1 dir2/ works    |
|     | cp -a dir1/ dir2/        | # same, but I don't      |
| BSD |                          | # consider this syntax   |
|     | # to copy dir1/ itself   | # really correct[^1]     |
|     | cp -a dir dir2/          |                          |

A similar issue with BSD find. It adds a trailing slash after the source path automatically, and so, if, for the sake of consistency\[\^1\], you already added it manually, as in find ./ -type f, the first / will be replaced with // instead. Though it doesn't break anything (at least, until you need to parse it), it looks ugly:

.//file1
.//file2
.//dir1/file3
.//dir2/file4

\[\^1\]: Because the root directory in Unix and Unix-like operating systems is /, I consider a trailing / to be not an excessive or optional but instead a mandatory (though its omission is often forgiven by the tools we use) part of directory names, and so I always refer to them like /usr/bin/ and not /usr/bin (and to refer to their contents, /usr/bin/*).

The GNU sort command is not sorting words of different lengths with common prefixes correctly for me, but only when using a field delimiter to sort on one of multiple fields. Here is the correct, expected sort behavior without using field delimiters:

$ cat /tmp/test0
b
c
ant
a
bcd
bc
cn

$ sort /tmp/test0
a
ant
b
bc
bcd
c
cn

Note that, for all words with a common string prefix, the shorter word sorts before the longer word. E.g. a is before ant, b is before bc is before bcd, etc. This is the accepted, standard way that English strings are sorted, e.g. in a dictionary. However, this sorting behavior changes when you are attempting to sort tabular data (such as a CSV file), and sorting on one of the columns. Here's what that looks like:

$ cat /tmp/test1
b,foo
c,bar
ant,baz
a,foo
bcd,ty
bc,pe
cn,cn

$ sort /tmp/test1 -t, -k1
a,foo
ant,baz
bcd,ty
bc,pe
b,foo
c,bar
cn,cn

Note that the words with a common prefix of a and c are still being handled correctly, but strings with a common prefix of b are not; bcd sorts before bc sorts before b, all of which is incorrect! This behavior is stable; you always get the same result. I'm experiencing this exact same issue on a much larger CSV file and the sorting errors there are deterministically random, if that makes sense. I've tried various flags to sort and none work to correct this behavior. -d and -s don't work. This is on GNU coreutils 9.4 sort for what it's worth. So, is this just a bug with the sort command? Am I somehow using it incorrectly? Is there anything better I can do that will dictionary sort the CVS by words in the first column?

Using coreutils sort, how can I sort numerically by a hexadecimal value (field)? I was expecting something along the lines of sort -k3,3x file_to_sort however, such an x does not exist. Edit: Best solution I came up with so far is: { echo ibase=16; cut -d' ' -f3 file_to_sort; } | bc | paste -d: - file_to_sort | sort -t: -k1,1n | cut -d: -f2- where the cut -d' ' -f3 isolates the search field (this is -k3,3 — this may vary, of course), and bc does conversion to decimal (requires upper-case hex, without 0x prefix, matching my case). Then I join, sort, and split columns. Minimal sample input: 5 hhf 25 3 ezh ae 1 hdh d12 2 ukr 9f 4 jjk 7 Expected output (file sorted by hex third column): 4 jjk 7 5 hhf 25 2 ukr 9f 3 ezh ae 1 hdh d12