-
Section menu
This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.
[file this blog page at: dig del.icio.us Technorati]
Section menu
Today after so many years of using find I noticed a relatively recent addition to man 1 find for the -size option:
The + and - prefixes signify greater than and less than, as usual; i.e., an exact size of n units does not match. Bear in mind that the size is rounded up to the next unit.
That means that the [wbkMG] suffix is not merely
multiplicative but also warps
the size of the
file being tested:
Therefore -size -1M is not equivalent to -size -1048576c. The former only matches empty files, the latter matches files from 0 to 1,048,575 bytes.
Therefore to test for files of size less than some given quantity is awkward unless one used the c unit. Consider these examples:
$ ls -l total 0 -rw------- 1 pg pg 0 Jan 17 19:08 size_0000c -rw------- 1 pg pg 3071 Jan 17 19:08 size_3071c -rw------- 1 pg pg 3072 Jan 17 19:08 size_3072c -rw------- 1 pg pg 3073 Jan 17 19:08 size_3073c -rw------- 1 pg pg 4095 Jan 17 19:08 size_4095c -rw------- 1 pg pg 4096 Jan 17 19:08 size_4096c -rw------- 1 pg pg 4097 Jan 17 19:08 size_4097c $ find * -size -4k size_0000c size_3071c size_3072c $ find * -size +4k size_4097c
Selecting files of size N units or smaller is easy, just test for less than N+1 units or for not greater than N units:
$ find * -size -5k size_0000c size_3071c size_3072c size_3073c size_4095c size_4096c
$ find * ! -size +4k size_0000c size_3071c size_3072c size_3073c size_4095c size_4096c
Obvious attempts to exclude the file that is exactly 4k fail:
$ find * -size -4k ! -size 4k size_0000c size_3071c size_3072c $ find * -size -5k ! -size 4k size_0000c size_3071c size_3072c $ find * ! -size +4k ! -size 4k size_0000c size_3071c size_3072c
The problem is that all files sizes from 3073 to 4095 get rounded up to 4096 if using the k suffix, so no test using k can exclude files of size 4096 but accept those of size up to 4095, and this fails too:
$ find * -size -`expr 4 \* 1024 / 2`w size_0000c size_3071c size_3072c size_3073c
But this straightforwardly works:
$ find * -size -`expr 4 \* 1024`c size_0000c size_3071c size_3072c size_3073c size_4095c
In essence find only has size tests for greater-or-equal, or greater, or equal unless one uses suffix c.
It is sometimes forgotten that it is a good practice to mount
filesystem under directories below the root
directory or the user's home
dictory, because
programs that try to figure out that path to their current directory
can hang if those filesystems are stuck
. For
example traditionally Linux filesystems have been mounted under
/mnt/ if on fixed block devices or under /media/
if on detachable block devices.
It is however often a good idea to mount them on directories two directories below in the following cases:
One traditional solution is to mount filesystems two levels deep and then use symbolic links to them from where users expect them:
However it is possible for a remote filesystem from a server to become stuck but not another, and this means that the safest mount point naming scheme is to create a directory named after the filesystem and a directory with a conventional name under it, and mount the filesystem on that. For example /mnt/archive1/mp/ and /mnt/archive2/mp/.
In the latter scheme the /mnt/ prefix is sort of redundant, so a suitable minimal scheme for static mounting is:
With an auto-mounter it could be:
A little detail could be to name the actual mount-point directory instead of mp/ as in the example, with a name beginning with a period so it would be skipped over by ls and directory browsers by default, for example .m/ or even ..., resulting in mount-points like /auto/archive2/.../. Unfortunately directory names ending in a period do trigger a common bug, in that some tools strip ./ from everywhere, not just at the beginning of the path, so I settled on ._ as the name of the mount point directory.
$ acpitool -B | head -8
Battery #1 : present
Remaining capacity : 26530 mWh, 68.80%, 04:28:09
Design capacity : 45000 mWh
Last full capacity : 38560 mWh, 85.69% of design capacity
Capacity loss : 14.31%
Present rate : 5936 mW
Charging state : Discharging
Battery type : Li-poly
This is in part due to my
sabiwatts script
and
my other script to suspend the processes
running programs that keep being active in the background (mostly
web browsers).
But I have been using them for a long while and power draw IIRC never went lower than 9-10W. I suspected that the improvements is due mostly to two factors:
Actually it is still around 6 with WiFi and Bluetooth enabled, so I guess it is mostly improvements in the kernel chipset drivers.
6 watts is around the best even Intel laptops can do and it is quite welcome. I wonder what an ARM64 powered laptop could do.
Having bought an Epson printer I have tried to set it up with CUPS, which as usual in these cases has been hindered by poor and incomplete documentation, and some changes in CUPS practices.
I found tha there are some important non-obvious configuration details for its Epson-provided driver:
nativeESC/P-R drivers will work by default because as a rule Debian and Ubuntu are configured to access printers in driverless mode that is over the network using IPP. Indeed the future is driver-less:
For local printers that are connected by USB and not over the network therefore the default is that the ippusbxd (there is another version called ipp-usb) package and daemon is installed to wrap a local USB printer with a network accessible IPP interface (by default at localhost:60000). Unfortunately this daemon is automatically started by configuration in the file /lib/udev/rules.d/55-ippusbxd.rules for any printers and prevents access to the USB printer, so the native drivers will never work until it is disabled. The symptom for this is the messageCUPS printer drivers and backends are deprecated and will no longer be supported in a future feature release of CUPS. Printers that do not support IPP can be supported using applications such as ippeveprinter(1).
usblp1: removedin the kernel log messages,
If it is desired to use the native driver instead of the driverless
IPP access therefore two things must be
done:
