Re: grdc: show timezone when TZ is set
Sunday, 20220918 13:38+, Florian Obser wrote:
I'm happy with that, let's do this then
- fix the offset calculation
- output tm->tm_zone in addition to TZ to be able to spot typos.
I like the overall diff (thanks!), but one minor formatting nit is that
I believe it's more common under ISO 8601[1] to print UTC timezone
offset as "+/-%H%M", e.g. "-0400", not as "-4h00". At least, that's
what I'm familiar with in SMTP headers.
Updated diff below, where only change from your latest diff is in the
second printw(3) statement. Tested against both TZ='America/New_York'
(-0400) and TZ='Asia/Kolkata' (+0530).
Again, thanks for polishing this old "game"!
[1] https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC
$ got diff
diff /cvs/src
commit - 5d6f1c4a07abcf6c1413059c603776d5dc6805aa
path + /cvs/src
blob - 66e5eee79e6449916e83660a8c7c62667d04c5ab
file + games/grdc/grdc.c
--- games/grdc/grdc.c
+++ games/grdc/grdc.c
@@ -185,9 +185,12 @@ main(int argc, char *argv[])
vline(ACS_VLINE, YDEPTH);
if (tz != NULL) {
+ int h, m;
+ h = tm->tm_gmtoff / 3600;
+ m = abs((int)tm->tm_gmtoff % 3600 / 60);
move(ybase - 1, xbase);
- printw("[ %s %+d ]", tz,
- tm->tm_gmtoff / 60 / 60 );
+ printw("[ %s (%s) %+2.2d%02d]", tz,
+ tm->tm_zone, h, m);
}
attrset(COLOR_PAIR(2));
who(1) patch for unveil violation
Hello,
This morning I was surprised to see a who(1) unveil violation in a
lastcomm(1) report, so I looked into it and found that when requesting
show_idle (-u flag) or show_term (-T flag), we indeed try to read
_PATH_DEV, which isn't unveiled yet.
I'm not an unveil(2) expert, and there might be a better way to handle
this, but I confirmed this fixes both case 0 (no file arg) and case 1
(e.g. `who -u /var/log/wtmp`). Tested on a -current snapshot from
yesterday, as well as on an up-to-date 6.7-stable box.
Cheers,
David
===
--- who.c.orig Thu Aug 27 06:24:18 2020
+++ who.c Thu Aug 27 06:40:52 2020
@@ -124,6 +124,10 @@
if (unveil(_PATH_UTMP, "r") == -1)
err(1, "unveil");
+ if (show_term || show_idle) {
+ if (unveil(_PATH_DEV, "r") == -1)
+ err(1, "unveil");
+ }
switch (argc) {
case 0: /* who */
if (pledge("stdio rpath getpw", NULL) == -1)
Re: Teach du(1) the -m flag, disk usage in megabytes
Monday, 20200127 18:29-0500, Daniel Jakots wrote: > Can't you achieve what you want with `du -sh * | sort -h`? du(1)'s > -h options will automatically select the best suffix and sort(1)'s > -h will sort first using the suffix then the numerical value. Thanks! I didn't know about "sort -h". That indeed does what I want, and is a bit more readable (e.g. 8G instead of the quick mental math in evaluating 8192M). Like Todd said, old habits die hard. And at least in my case, I'm pleasantly surprised any time a tool features smart extensions and I don't have to manipulate arrays of raw integers. :) Actually, I think you've convinced me that using "sort -h" is better. In particular, I like that it future-proofs us up to and including yottabytes. What about something like this, to highlight this common use case? --- Index: du.1 === RCS file: /cvs/src/usr.bin/du/du.1,v retrieving revision 1.35 diff -u -p -r1.35 du.1 --- du.12 Sep 2019 21:18:41 - 1.35 +++ du.129 Jan 2020 16:02:45 - @@ -147,6 +147,16 @@ option is specified. .El .Sh EXIT STATUS .Ex -std du +.Sh EXAMPLES +To sort human-readable output by size, one might use the human-readable +extension to +.Xr sort 1 , +for example: +.Pp +.Dl du -sh * | sort -h +.Pp +This is useful to quickly identify large files and folders consuming +disk space. .Sh SEE ALSO .Xr df 1 , .Xr fts_open 3 ,
Re: Teach du(1) the -m flag, disk usage in megabytes
Monday, 20200127 10:05+1100, Jonathan Gray wrote: > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > This brings us in line with implementations in the other BSDs, Linux, > > and Illumos. > > Why is it needed? -k is required by POSIX, adding arguments for > megabytes, gigabytes, terabytes, petabytes etc seems silly when > there is already 512 byte blocks, kilobytes and -h output. It's a fair question. My reasoning is two-fold: (1) FreeBSD, NetBSD, Linux, and Illumos all support the "-m" flag, and it's helpful when one can use the same flags/scripts across different systems without surprises. While both FreeBSD and NetBSD also implement "-g" (gigabytes), other systems don't, and it's not an itch I have to scratch. However it's easy to add if we decide we want it. Presently only Linux easily supports blocksizes larger than a gigabyte, via e.g. "-B 1T" as noted by tedu@. FreeBSD also supports "-B", but the argument must be an integer number of bytes[1], e.g. "-B 1099511627776" (1024^4) for 1 terabyte, which is a bit different and feels less natural for everyday use. My feeling is that simple, common, and hard-to-misuse flags like "-m" and "-g" are more useful than an interface which requires most users first open a calculator. (2) We currently support 512-byte (default), kilobyte (-k), arbitrary BLOCKSIZE up to 1g per environ(7), and human-readable (-h), but only the first three can be piped to sort(1) e.g. when investigating filled disk scenarios when one wants to determine the largest files/directories on the disk (human-readable doesn't use the same scale for all outputs, so it can't be sorted as easily). In this case I simply find it easier to conceptualize thousands of megabytes than I do millions of kilobytes. For example: $ BLOCKSIZE=1k du -d0 * | sort -nr | head -n 5 17541678Audiobooks 9513850 Music 1991678 Documents 1638976 Books 223872 mbox $ BLOCKSIZE=1m du -d0 * | sort -nr | head -n 5 17131 Audiobooks 9291Music 1945Documents 1601Books 219 mbox The environment variable is a bit clunky to pass around and I think a flag like "-m" would represent a nice usability improvement. Thanks! David --- references [1] https://svnweb.freebsd.org/base/head/usr.bin/du/du.c?revision=326025&view=markup#l130
Teach du(1) the -m flag, disk usage in megabytes
This diff teaches du(1) the -m flag, report disk usage in megabytes.
This brings us in line with implementations in the other BSDs, Linux,
and Illumos.
Other base utilities where this flag might be useful include df(1)
and quot(8), although it doesn't appear to be universally adopted
among the other implementations. That said I can definitely cook
up a diff if others would find the flag useful elsewhere. In
particular I think the flag would be useful in quot(8), but that
tool has an unfortunate legacy, discouraged option "-h" which
conflicts with -k/-m/-h semantics elsewhere in base, such that
adding "-m" to quot(8) might only invite confusion.
Many thanks to florian@ for a first-pass review on bsd.network, and
for encouraging me to check out what the other BSDs and utilities in
base do, so that we maintain consistency across the ecosystem.
This is my first patch submission---any pointers for improvement would
be greatly appreciated! Thanks!
(diff below and also attached as "du-megabytes.diff" in case my mail
client mangles formatting; hopefully I got this right!)
---
Index: du.1
===
RCS file: /cvs/src/usr.bin/du/du.1,v
retrieving revision 1.35
diff -u -p -r1.35 du.1
--- du.12 Sep 2019 21:18:41 - 1.35
+++ du.125 Jan 2020 20:52:11 -
@@ -38,7 +38,7 @@
.Nd display disk usage statistics
.Sh SYNOPSIS
.Nm du
-.Op Fl achkrsx
+.Op Fl achkmrsx
.Op Fl H | L | P
.Op Fl d Ar depth
.Op Ar
@@ -86,6 +86,10 @@ By default, all sizes are reported in 51
The
.Fl k
option causes the numbers to be reported in kilobyte counts.
+.It Fl m
+Similar to
+.Fl k ,
+but report disk usage in megabytes.
.It Fl L
All symbolic links are followed.
.It Fl P
Index: du.c
===
RCS file: /cvs/src/usr.bin/du/du.c,v
retrieving revision 1.32
diff -u -p -r1.32 du.c
--- du.c24 Aug 2016 03:13:45 - 1.32
+++ du.c25 Jan 2020 20:52:31 -
@@ -61,7 +61,7 @@ main(int argc, char *argv[])
long blocksize;
int64_t totalblocks;
int ftsoptions, listfiles, maxdepth;
- int Hflag, Lflag, cflag, hflag, kflag;
+ int Hflag, Lflag, cflag, hflag, kflag, mflag;
int ch, notused, rval;
char **save;
const char *errstr;
@@ -70,11 +70,11 @@ main(int argc, char *argv[])
err(1, "pledge");
save = argv;
- Hflag = Lflag = cflag = hflag = kflag = listfiles = 0;
+ Hflag = Lflag = cflag = hflag = kflag = listfiles = mflag = 0;
totalblocks = 0;
ftsoptions = FTS_PHYSICAL;
maxdepth = -1;
- while ((ch = getopt(argc, argv, "HLPacd:hkrsx")) != -1)
+ while ((ch = getopt(argc, argv, "HLPacd:hkmrsx")) != -1)
switch (ch) {
case 'H':
Hflag = 1;
@@ -103,10 +103,17 @@ main(int argc, char *argv[])
case 'h':
hflag = 1;
kflag = 0;
+ mflag = 0;
break;
case 'k':
kflag = 1;
hflag = 0;
+ mflag = 0;
+ break;
+ case 'm':
+ kflag = 0;
+ hflag = 0;
+ mflag = 1;
break;
case 's':
maxdepth = 0;
@@ -155,6 +162,8 @@ main(int argc, char *argv[])
blocksize = 512;
else if (kflag)
blocksize = 1024;
+ else if (mflag)
+ blocksize = 1048576;
else
(void)getbsize(¬used, &blocksize);
blocksize /= 512;
@@ -320,6 +329,6 @@ usage(void)
{
(void)fprintf(stderr,
- "usage: du [-achkrsx] [-H | -L | -P] [-d depth] [file ...]\n");
+ "usage: du [-achkmrsx] [-H | -L | -P] [-d depth] [file ...]\n");
exit(1);
}
Index: du.1
===
RCS file: /cvs/src/usr.bin/du/du.1,v
retrieving revision 1.35
diff -u -p -r1.35 du.1
--- du.12 Sep 2019 21:18:41 - 1.35
+++ du.125 Jan 2020 20:52:11 -
@@ -38,7 +38,7 @@
.Nd display disk usage statistics
.Sh SYNOPSIS
.Nm du
-.Op Fl achkrsx
+.Op Fl achkmrsx
.Op Fl H | L | P
.Op Fl d Ar depth
.Op Ar
@@ -86,6 +86,10 @@ By default, all sizes are reported in 51
The
.Fl k
option causes the numbers to be reported in kilobyte counts.
+.It Fl m
+Similar to
+.Fl k ,
+but report disk usage in megabytes.
.It Fl L
All symbolic links are followed.
.It Fl P
Index: du.c
===
RCS file: /cvs/src/usr.bin/du/du.c,v
retrieving revision 1.32
diff -u -p -r1.32 du.c
--- du.c24 Aug 2016 03:13:45 - 1.32
+++ du.c25 Jan 2020 20:52:31 -
@@ -61,7 +61,7 @@ main(int argc, char *argv[
