I'm making a custom ELF loader to learn how the dynamic loader works behind the scenes, and one of the program headers often found in them is PT_GNU_RELRO, which tells the loader to make that segment read-only after performing relocations. However, it doesn't look like there's a good way to update existing memory mappings' protections without replacing the entire thing. MAP_UNINITIALIZED seems to be what I'm looking for, but mmap(2) states that it doesn't work on most systems for security reasons. >**MAP_UNINITIALIZED (since Linux 2.6.33)** > >Don't clear anonymous pages. This flag is intended to improve performance on embedded devices. This flag is honored only if the kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED option. Because of the security implications, that option is normally enabled only on embedded devices (i.e., devices where one has complete control of the contents of user memory). Which is reasonable for loosening permissions, but I'm looking to restrict them. Is there a way, as a user process, to update a mmap mapping to be read-only without replacing existing data at that address?

Sample Data: Tab separated file (TSV)

a.1.58	fadado/CSV	https://github.com/fadado/CSV 
a.1.63	jehiah/json2csv	https://github.com/jehiah/json2csv 
a.1.80	stedolan/jq	https://github.com/stedolan/jq/issues/370 

Following selects one record using fzf, and stores 2nd and 3rd column to an array Link:

mapfile -d $'\t' -t Link < <(awk 'BEGIN{FS="\t"; OFS="\t"} {print $2,$3}' "${SessionP}" | fzf)

## Issue In the above command I have used -t option of mapfile, but echo "${Link}" prints a trailing new line! **Why is it not getting eliminated?** ## Reference - [mapfile Man Page - Linux - SS64.com](https://ss64.com/bash/mapfile.html)

> Recutils offers a way to encrypt specified fields in a record, whilst leaving the rest in clear text. -- [GNU Recutils Manual](https://www.gnu.org/software/recutils/manual/Editing-Records.html#Editing-Records) What encryption algorithm does it use by default?

Is it somehow possible to tweak Readline in a way that always uses an interactive fuzzy finder (fzf) for making selections in Bash completions? From the GNU Bash documentation, I understand that Readline is responsible for providing this behavior. So instead of configuring my own completions to use fzf, I thought it would be easier to tweak the general behavior.

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?

This question addresses the **first pass** of ddrescue on the device to be rescued. I had to rescue a 1.5TB hard disk. The command I used is: # ddrescue /dev/sdc1 my-part-img my-part-map When the rescue is started (with no optional parameters) on a good area of the disk, the read rate ("current rate") stays around 18 MB/s. It occasionally slows a bit, but then comes back to this speed. However, when it encounters a bad area of the disk, it may slow down significantly, and then it never comes back to the 18 MB/s, but stays around 3 MB/s, even after reading 50 GB of good disk with no problem. The strange part is that, when it is currently scanning a good disk area at 3 MB/s, if I stop ddrescue and restart it, it restarts at the higher reading rate of 18 MB/s. I actually saved about 2 days by stopping and restarting ddrescue when it was going at 3 MB/s, which I had to do 8 times to finish the first pass. My question is: why is it that ddrescue will not try to go back to the highest speed on its own. Given the policy, explicitly stated in the documentation, of doing first and fast the easy areas, that is what should be done, and the behavior I observed seems to me to be a bug. I have been wondering whether this can be dealt with with the option -a or --min-read-rate=… but the manual is so terse that I was not sure. Besides, I do not understand on what basis one should choose a read rate for this option. Should it be the above 18 MB/s? Still, even with an option to specify it, I am surprised this is not done by default. Meta note --------- Two users have voted to close the question for being primarily opinion based. I would appreciate knowing in what sense it is? I describe with some numerical precision the behavior of an important piece of software on an actual example, showing clearly that it does not meet a major design objective stated in its documentation (doing the easy parts as quickly as possible), and that very simple reasoning could improve that. The software is well know, from a very trusted source, with precise algorithms, and I expect that most defects were weeded out long ago. So I am asking experts for a possible known reason for this unexpected behavior, not being an expert myself on this issue. Furthermore, I ask whether one of the options of the software should be used to resolve the issue, which is even more a very precise question. And I ask for a detailed aspect (how to choose the parameter for this option) since I did not find documentation for that. I am asking for facts that I need for my work, not opinions. And I motivate it with experimental facts, not opinions.

As per my knowledge/understanding both help and man came at the same time or have very little time difference between them. Then GNU Info came in and from what I have seen is much more verbose, much more detailed and arguably much better than what man is. Many entries even today in man are cryptic. I have often wondered why Info which is superior to man in many ways didn't succeed man at all. I still see people producing man pages than info pages. Was it due to not helpful tools for info? Something in the licenses of the two? Or some other factor which didn't get info the success it richly deserved? I did see a few questions on unix stackexchange notably https://unix.stackexchange.com/questions/77514/what-is-gnu-info-for and https://unix.stackexchange.com/questions/19451/difference-between-help-info-and-man-command/159817 among others.

on a directory containing ~26 million files, GNU Find is 10 times faster than BusyBox find, why?

/var/www # time find /var/www -regex .*\.\(php\|js\|json\|html\|htm\|css\) -not -regex \(.*/docroot/external_libs/.*\|.*/docroot/phpmyadmin/.*\|.*/vendor/.*\|.*/data/vitec/.*\|.*/docroot/js/highcharts/.*\|.*/hotpatch_backups/.*\) -print0 > /dev/null
real    1m 20.09s
user    1m 6.94s
sys     0m 13.14s
/var/www # time busybox find /var/www -regex .*\.\(php\|js\|json\|html\|htm\|css\) -not -regex \(.*/docroot/external_libs/.*\|.*/docroot/phpmyadmin/.*\|.*/vendor/.*\|.*/data/vitec/.*\|.*/docroot/js/highcharts/.*\|.*/hotpatch_backups/.*\) -print0 > /dev/
null
real    13m 4.99s
user    1m 31.49s
sys     3m 16.60s

(Actually in production, we thought we saw busybox find being almost 30 times slower, 2 minutes to 60 minutes, but we're unable to reproduce it) Porting a system from Debian-linux (which defualts to GNU find) to Alpine-linux (which defaults to BusyBox find), and had a problem where a find command was hanging on Alpine but not on Debian.

I did a clean install of Arch Linux and imported my backed up gpg private key. As a sanity check I ran: gpg --list-keys Everything showed up as normal except for the uid which now reads: uid [ unknown ] User When I first created this key before the clean install it read: uid [ ultimate ] User Why would it change from [ ultimate ] to [ unknown ]after importing it onto a clean install?

Is there an official POSIX, GNU, or other guideline on where progress reports and logging information (things like "Doing foo; foo done") should be printed? Personally, I tend to write them to stderr so I can redirect stdout and get only the program's actual output. I was recently told that this is not good practice since progress reports aren't actually errors and only error messages should be printed to stderr. Both positions make sense, and of course you can choose one or the other depending on the details of what you are doing, but I would like to know if there's a commonly accepted standard for this. I haven't been able to find any specific rules in POSIX, the GNU coding standards, or any other such widely accepted lists of best practices. We have a few similar questions, but they don't address this exact issue: * https://unix.stackexchange.com/q/79315/22222 : The accepted answer suggests what I tend to do, keep the program's final output on stdout and anything else to stderr. However, this is just presented as a user's opinion, albeit supported by arguments. * https://unix.stackexchange.com/q/8813/22222 : This is specific to help messages but cites the GNU coding standard. This is the sort of thing I'm looking for, just not restricted to help messages only. So, are there any official rules on where progress reports and other informative messages (which aren't part of the program's actual output) should be printed?

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.

I am trying to build my system from scratch, since I really like the idea of atomicity of each program in unix-like approach, I would like to preserve it as much as possible in my build. Since GNU binutils, in a way, violates this principle, I would like to know if there is just GNU assembler, which wouldn't be dependant on binutils? If not, are there any minimal and performant alternatives to GNU assembler? I know of yasm, but in case there is a better one, I would like to know of it. Thank you in advance.

On GNU/Linux is it possible to change the default pager for info command? I would like to use less as the pager (similar to man pages). I have customized less to use colors to make navigation of man pages much easier.

- I did the following yesterday night (before midnight of Sunday in Germany): - Today's date

$ LC_TIME="en.GB.UTF8" date --iso-8601
2025-01-12

- Today's date (day of the week

$ LC_TIME="en.GB.UTF8" date +%u
7

$ LC_TIME="en.GB.UTF8" date +%a
Sun

# Issue - Since, week starts from Monday to Sunday, this week Monday should be 2025-01-06

bash
$ LC_TIME="en_GB.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_IE.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_IN.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_US.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_DE.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_JP.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_DK.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_CA.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

bash
$ LC_TIME="en_AU.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

# Another observation I did this today on 2025-01-13 (in Germany)

$ LC_TIME="en_AU.UTF-8" date -d "this-week-sunday" --iso-8601
2025-01-19
$ LC_TIME="en_AU.UTF-8" date -d "last-week-sunday" --iso-8601
2025-01-12
$ LC_TIME="en_AU.UTF-8" date -d "next-week-sunday" --iso-8601
2025-01-26

# Issue So, today it seems to be giving partly correct results. What is wrong from today's output: if from yesterday's output this-week-monday was 2025-01-13 so somehow computer was counting Sunday as the first day of the week in every locale (that I showed above). So then "this-week-sunday" should be yesterday and not 2025-01-19 (as shown today). # Summary **Yesterday**

bash
$ LC_TIME="en_GB.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

**Today**

env -i bash --norc --noprofile
bash-5.2$ LC_TIME="en_AU.UTF-8" date -d "this-week-sunday" --iso-8601
2025-01-19

**Issue**: So if yesterday (2025-01-12, Sunday), this-week-monday was 13th then, today this-week-sunday should be yesterday and not 2025-01-19 **Why am I getting the wrong date output?**

When I run the command fd --color always --max-depth=1 | column the output is not properly aligned, but it is when --color is set to --color never For reference, fd --color never --max-depth=1 | column prints

test-folder/	test12.txt	test16.txt	test2.txt	test5.txt	test9.txt
test1.txt	test13.txt	test17.txt	test20.txt	test6.txt
test10.txt	test14.txt	test18.txt	test3.txt	test7.txt
test11.txt	test15.txt	test19.txt	test4.txt	test8.txt

(It is properly aligned on my terminal, not sure why copy and pasting it here makes it look not aligned?) And fd --color always --max-depth=1 | column prints

test-folder/	test19.txt
test1.txt			test2.txt
test10.txt			test20.txt
test11.txt			test3.txt
test12.txt			test4.txt
test13.txt			test5.txt
test14.txt			test6.txt
test15.txt			test7.txt
test16.txt			test8.txt
test17.txt			test9.txt
test18.txt

I'm finding that the rows that aren't properly aligned are the ones with different colors. All the .txt files are green, while the folder is blue.The first row is not aligned because there are two items of different colors (a blue folder and a green txt file). According to https://unix.stackexchange.com/a/769660 version 2.40 of column should properly handle color codes; my column version from the man page is:

-linux 2.40.2   2024-07-04    COLUMN(1)

What's a simple way to have output from fd output in a bunch of columns? My use case is that I'd prefer to be using fd instead of ls every time I want to look at the files in a directory.

I thought GNU was the (only) supplier of essential tools whose open-source code powers Linux distributions. However while browsing unix.se, I saw some questions that explicitly state they are dealing with GNU, such as a question on the safety of parsing GNU

. This must imply that there are versions of

that are not provided by GNU, right? What are these versions, who make them and where can I find them?

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.*

Compiling code with GCC or Clang can result in some colorful error outputs. Linking code, however, doesn't enjoy the same luxury. It seems like the GNU Linker doesn't support colorized error output right out of the box. Is there a way around this? Is it possible to colorize/stylize linker errors from ld?

I'm in the process of upgrading my desktop/server setup and am considering using POWER9 architecture. However, I'm a bit concerned about the level of support it receives from GNU/Linux distributions and applications. Can anyone provide insights on how well supported POWER9 is within the GNU/Linux ecosystem in 2024? Any advice or recommendations would be greatly appreciated!

Is there a way to tell ping to show its usual termination statistics without stopping the execution? For instance, I'd like to quickly view: --- 8.8.8.8 ping statistics --- 2410 packets transmitted, 2274 received, +27 errors, 5% packet loss, time 2412839ms rtt min/avg/max/mdev = 26.103/48.917/639.493/52.093 ms, pipe 3 without having to stop the program, thus losing the accumulated data.