coreutils VS util-linux

https://github.com/coreutils/coreutils/commit/fcfba90d0d27a1...

A summary of other changes just released in GNU coreutils 9.5 are:

* mv accepts --exchange to swap files

> some are simple like yes(1)

Not that simple: https://github.com/coreutils/coreutils/blob/master/src/yes.c

The -S / --split-string option[1] of /usr/bin/env is a relatively recent addition to GNU Coreutils. It's available starting from GNU Coreutils 8.30[2], released on 2018-07-01.

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works for OS's that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

Fortunately this non-standard behavior is more the norm than the exception: it works at least on modern GNU/Linux, BSDs, and macOS.

[1] https://www.gnu.org/software/coreutils/manual/html_node/env-...

[2] https://github.com/coreutils/coreutils/blob/b09dc6306e7affaf...

> building a cat from scratch

> That would be an interesting project.

Here is the source code of the OpenBSD implementation of cat:

> https://github.com/openbsd/src/blob/master/bin/cat/cat.c

and here of the GNU coreutils implementation:

> https://github.com/coreutils/coreutils/blob/master/src/cat.c

Thus: I don't think building a cat from scratch or creating a tutorial about that topic is particularly hard (even though the HN audience would likely be interested in it). :-)

the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling.

If you look at the source code for yes, https://github.com/coreutils/coreutils/blob/master/src/yes.c

it builds a buffer of output and then writes that in a for loop

  while (full_write (STDOUT_FILENO, buf, bufused) == bufused)

Looking at the source of nohup, if the execvp() of the child happens then it _must_ have already done the signal (SIGHUP, SIG_IGN) so - WTF?

This got me wondering so I went and looked and it seems like lo and behold there was actually a commit to the GNU ls source just 2 weeks ago.

https://github.com/coreutils/coreutils/blob/master/src/ls.c

"maint: prefer char32_t to wchar_t"

even an empty file? Yes. so now it was a file with a copyright disclaimer and nothing else. And the koan-like question comes to mind is "Can you copyright nothing?" well AT&T sure tried.

Then somebody said our programs should be well defined and not depend on a fluke of unix, which at this point was probable a good idea. so it became "exit 0"

Then somebody said we should write our system utilities in C instead of shell so it runs faster. openbsd still has a good example of how this would look.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....

At some point gnu bureaucracy got involved and said all programs must support the '-h' flag. so that got added, then they said all programs must support locale so that got added. now days gnu true is an astonishing 80 lines long.

https://github.com/coreutils/coreutils/blob/master/src/true....

http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

> Yes, ls is maintained. Although, maintained is a very strong word. It exists.

Why would it be a strong word? Here it is, in src/ls.c: https://github.com/coreutils/coreutils

It is then packaged by tens of operating system distributions, who themselves maintain extra patchsets, some of which are then upstreamed.

It is installed and used on millions (billions?) of devices, for 3 decades.

It's a very reliable and trusty "sharp stick of metal" :)

There are su and runuser in util-linux (GPL-2.0) [1].

[1]: https://github.com/util-linux/util-linux/tree/master/login-u...

>It remained in the "getty" process for some time, well into the {Free,Net,Open}BSD era.

Still there in agetty: https://github.com/util-linux/util-linux/blob/master/term-ut... And, I imagine in other getty implementations.

TIOCSTI is irrelevant. When one is dropping privileges, in a system cron job or in a process supervised by one's favourite service management system, there is no terminal involved. TIOCSTI simply doesn't enter into the picture at all.

Only when one is in a terminal login session and using su to elevate / add privileges, does TIOCSTI become relevant. But no-one here is saying not to use su to add privileges.

People blame su, sudo, and (as the person at https://github.com/slicer69/doas/issues/110 did) doas for this feature of operating system kernels. The right thing to do with TIOCSTI it to just eliminate it from the kernel. OpenBSD did back in version 6.

Sadly, the argument from Alan Cox, Linux developer, when this was proposed years ago was that it should stay in Linux, and all of the programs like su, sudo, and doas should have even more things to do in the parent process that sticks around, namely pump I/O to and from a controlling pseudo-terminal that su/sudo/doas sets up for the shell subprocess, breaking (as the maintainer of OpenDoas pointed out) the long-standing notion that the child processes belong to the same terminal session and share things like a single getlogname() with the login shell.

6 years after https://www.openwall.com/lists/kernel-hardening/2017/05/10/3... and https://www.openwall.com/lists/oss-security/2017/06/03/9, there is no sign of anyone doing anything of the sort in any su or doas implementation. (It was briefly in one su implementation, but taken out in 2017 for being a "stupid hack": https://github.com/util-linux/util-linux/commit/23f75093264a...)

Fortunately, some six months ago Linux developers finally made TIOCSTI removable and the right course of action is available to those that want it: https://lore.kernel.org/lkml/20221228205726.rfevry7ud6gmttg5...

Huh, I will try this later. Bit confused by the instructions on the Archwiki but I think I can figure it out. Thanks so much for the help. Btw, it seems you were right on what was wrong. Good eyes.

So, this script serves as a pretty good wall replacement (wall will strip all escape/control sequences other than \007, by the way).

The login program (used for terminal logins) is part of the util-linux project: https://en.wikipedia.org/wiki/Util-linux

if anbody actually at Canonical is reading this and wants me (and others) to take snaps seriously, please consider submitting pull requests to some of the core cli tool projects impacted by the way you guys abuse the loop device mechanism. Something simple like the ability to export HIDE_SNAP_MOUNTS=1 that gets picked up by the impacted tools in util-linux (lsblk, mount, blkid, fdisk, etc) and gnu coreutils (du, df) and simply hides the lines related to loop device mounts would go a long way - preferably only the ones added by snap but even an option to hide all of them would be better than nothing.

Pick a different filesystem, or wait for this feature to land in util-linux.

Also a data format. Reasonably easy to find a spec (the wikipedia article should be sufficient to implement it). Also reasonably easy to find Free Software implementations, such as fdisk.