On Wednesday, 11 March 2020 at 19:14:32 -0400, Dan Cross wrote: > On Wed, Mar 11, 2020 at 6:57 PM Greg 'groggy' Lehey wrote: > >> On Wednesday, 11 March 2020 at 14:18:08 +1100, Dave Horsfall wrote: >>> >>> The "ls" command for example really needs an option-ectomy; I find that I >>> don't really care about the exact number of bytes there are in a file as >>> the nearest KiB or MiB (or even GiB) is usually good enough, so I'd be >>> happy if "-h" was the default with some way to turn it off (yes, I know >>> that it's occasionally useful to add them all up in a column, but that >>> won't tell you how many media blocks are required). >> >> A good example. But you're not removing options, you're just >> redefining them. In fact I find the -h option particularly emetic, so >> a better choice in removing options would be to remove -h and use a >> filter to mutilate the sizes: >> >> $ ls -l | humanize >> >> But that's a pain, isn't it? > > I don't know; that's subjective. It's certainly more work than -h. >> That's why there's a -h option for people who like it. > > That's incomplete, in that it implies that an option is the only way > to achieve the goal of reducing the perceived pain, but that's not > the case. (Note I'm not saying you intended that as an > interpretation, but it's a reasonable intuition for an intention.) What I meant (and this is certainly my interpretation) was that somebody added the -h option because of perceived pain with piping output through another program. I didn't intend to imply that it was the only alternative. > An interesting counterpoint to this argument is how columnized "ls" > is handled under Plan 9: there is no `-C` option to `ls` there; > instead, there's a general-purpose `mc` filter that figures out the > size of the window it's running in, reads its input, decides how > many columns the input will fit into, and emits it columnized. But > yes, it would be a pain to type `ls | mc` every time one wanted > columnized `ls` output, so this is wrapped up into a shell script > called `lc`. Note that this lets you do stuff like, `lc -l` and see > multi-column long listings if the window is wide enough. Yes, that sounds like an excellent method. > For the `humanize` thing, I don't see why one couldn't have an `lh` > command that generated "human-friendly long output from ls." And yes, I deliberately didn't mention this option, though it occurred to me. I have a couple of scripts like this, like: alias l="ls -lbL," >> Note that you can't do it the other way round: you can't get the >> exact size from -h output. > > That's true, but now the logic is specialized to ls, and not > applicable to anything else (e.g., du? df? wc, perhaps?). Similarly > with `-,`. It is not general purpose, which is unfortunate. Yes, this is an issue that I mentioned in an earlier message (I added a positional parameter to work around it). But this is in the nature of the output. mc doesn't have this issue. > Granted, combining these things would be a little challenging, but is it > likely that one would want `ls -l,h`? Optimize for the common case, > etc.... Heh. Never thought of that. But since -h (apparently) never produces output with 4 digits, the -, doesn't ever come into effect. I've just tried it on some big files, and the -, is effectively ignored. > And then there's the question why you don't like the standard > output. I don't like the standard output because things like this are hard to read: -rw-r--r-- 1 grog lemis 8234010624 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 13225168900 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 I find this easier to read: -rw-r--r-- 1 grog lemis 8,234,010,624 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 13,225,168,900 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 I can't speak for Dave, but this is also less painful: -rw-r--r-- 1 grog lemis 7.7G 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 12G 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 The problem for me there is the difficulty comparing lengths, and the implicit inaccuracy. >> Because the number strings are too long and difficult to read, maybe? >> That's the rationale for the -, option. >> >>> Quickly now, without looking: which option shows unprintable >>> characters in a filename? Unless you use it regularly (in which >>> case you have real problems) you would have to look it up; I find >>> that "ls ... | od -bc" to be quicker, especially on filenames with >>> trailing blanks etc (which "-B" won't show). >> >> This is arguably a bug in the -B option. I certainly don't think the >> pipe notation is quicker. But it's nice to have both alternatives. > > By default, plan9 would quote filenames that had characters that > were special to the shell (there wasn't really the concept of > "non-printable characters in the Unix/TTY sense); this could be > disabled by specifying the `-Q` option. Hmm. In this particular case, so does Linux: === grog@bilbo (/dev/pts/11) ~ 2 -> touch "foo " === grog@bilbo (/dev/pts/11) ~ 4 -> l foo* -rw-r--r-- 1 grog grog 1499570 Jun 30 2012 foo -rw-r--r-- 1 grog grog 0 Mar 12 10:40 'foo ' I wonder if that's something we should emulate in FreeBSD. At the very least we should consider whether the lack of identification of trailing blanks is a bug in the FreeBSD implementation of -B. This option isn't in POSIX, and in Linux it means -B, --ignore-backups do not list implied entries ending with ~ So maybe it's a candidate for fixing. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA