nosh is now up to version 1.19
The important news is that the embarrassment with the post-install setup
script for the Linux nosh-run-kernel-vt package is fixed. It was a
missing 1-line escape() shell function. I apologize.
Other terminal management news is that there's now a console-clear
command that does pretty much the same thing as the Bourne Again shell's
clear_console command (also coming with that name as a symbolic link
alias) but better.
* The bash clear_console tries to open a lot of device files, as can be
seen in Ubuntu bug #39068. This tool by comparison doesn't need
anything more than its standard output, and doesn't attempt to open any
terminal devices itself at all.
* The bash tool is specific to the Linux kernel terminal emulator. It
had to be turned off for Debian kFreeBSD in Debian bug #355336, patched
to make it stop when run as the superuser in xterm in Debian bug
#355815, and worked around again in Debian bug #793883. This tool,
contrastingly, actually works with xterm and PuTTY and clears their own
scrollback buffers. It uses a different mechanism that both they and
(ironically) the Linux kernel terminal emulator since 2011, all support.
* Debian bug #791342 would be fixed by it, because it doesn't use the
bodge of attempting to switch virtual terminals away and back (using
either tty1 or tty2 as the "other" terminal) to clear the scrollback buffer.
On the gripping hand, this is something that one doesn't actually need
if one is using the nosh-run-user-vt package. console-terminal-emulator
supports the same extension to ECMA-48 Erase Display as xterm and PuTTY
do, but the raison d'être for clear_console is the likes of Debian bug
#331504. clear_console is in fact a ten-year-old bodge, addressing a
security/privacy concern that's a lot older still. With user-space
virtual terminals, one has the freedom to do things right, without the
need for such bodges. (-: As the console-terminal-emulator manual page
explains, when a login session terminates and the terminal is hung up,
the terminal emulator erases the whole display buffer.
In more other news: On Linux, fsck at bootstrap time is now monitored.
What this means from a user standpoint is that if your system reaches
its "maximum mounts before a forced full fsck" point, it doesn't just
sit there with nothing visibly happening (if one cannot see the hard
disc activity light) for ages. The fsck@* services now invoke
"monitored-fsck" rather than fsck directly. This is an ordinary
chain-loading tool that opens a client connection to a local (i.e.
AF_LOCAL) socket and then chains to fsck adding in its (Linux-specific)
-Cfd option. There's a new monitor-fsck-progress service that runs the
server for that socket, and displays progress information on the
console. This latter is intentionally replaceable by alternative
services, of course. I'm intending to make its output somewhat
prettier, rather than just dumping the raw information at you as it does
in this release. But if you want to write your own ...
You'll have to delete /etc/system-control/convert/volumes (or modify the
contents of /etc/fstab) and run "redo all" to get your existing
auto-created fsck@* service bundles regenerated with the new command.
Or just edit the run files replacing fsck with monitored-fsck .
The big news is that as promised in the 1.18 announcement the
nosh-run-busybox-mdev package is now functional. Also as promised in
that announcement, here's more on the subject.
The nosh toolset doesn't come with a bunch of rules for your
plug-and-play manager, be that (BSD) devd, (Linux) udev, or busybox
mdev. Your plug-and-play manager does, or should do. As packaged up
for Debian Linux, udev comes with a whole bunch of pre-supplied rules in
/lib/udev/rules/ that gets one the "usual" device file tree in /dev/ .
And it almost goes without saying that the BSDs come with devd rules in
the box. The same is not true for the busybox Debian package. There's
no /etc/mdev.conf supplied.
You MUST write one before using busybox mdev. busybox mdev's default
behaviour as packaged, in the absence of /etc/mdev.conf , may be logical
and straightforward; but it does not result in a working Debian system.
Some things that I've hit myself are /dev/null not being accessible to
anyone except the superuser, which affects loads of things all over the
shop, and event device files not being under /dev/input/ where other
parts of the system expect them to be.
There's plenty to read on this subject in the non-Debian world, starting
with but not limited to:
You'll have to adapt these for Debian. There are also the examples in
/usr/share/doc/busybox/examples/ , of course, the larger of the two
fixing both of the aforementioned problems. The positive news is that
the busybox-mdev service implicitly serializes invocations of mdev, so
that there's no need for mucking around with mdev's sequence number
The recovery mode problem mentioned in the 1.18 announcement turns out
to have a simple local fix, which I'll incorporate into a more
comprehensive service fix:
# ln -s rescue /etc/service-bundles/targets/single