@BadAtNames

"-n" is quite handy.

@BadAtNames @fribbledom i don't think I had even considered that there might be options

@BadAtNames

@fribbledom

-vte
shows non-printing characters, useful in ux<->dos comparisons/conversions

@reenii @fribbledom You're one of the fortunate ones.

@gudenau @fribbledom that's why they shouldn't be there.

@gudenau @fribbledom
Right but one point McIlroy makes is how much smaller these commands and their manpages could be without them.

It's like OSes using more system resources obsoleting older hardware. Should we just accept this?

@darius @fribbledom
I often put a transparent x-terminal over a webpage I am copying commands from and juat clear the screen whenever output obscures what I'm reading.

@woodcat

I guess this is part of the issue: tar wasn't intended to be a file compression utility, but a t(ape) ar(chiver). If all it did was file compression, it probably would be a whole lot slimmer.

@fribbledom

> [Adding options to CLI programs has a cost]—more options means more maintenance burden—but that's a cost that maintainers pay to benefit users, which isn't obviously unreasonable considering the ratio of maintainers to users. This is analogous to Gary Bernhardt's comment that it's reasonable to practice a talk fifty times since, if there's a three hundred person audience, the ratio of time spent watching to the talk to time spent practicing will still only be 1:6.

2/4

@fribbledom

> If you think of the set of command line tools along with a shell as forming a language, a language where anyone can write a new method and it effectively gets added to the standard library if it becomes popular, where standards are defined by dicta like "write programs to handle text streams, because that is a universal interface", the language was always going to turn into a write-only incoherent mess when taken as a whole.

3/4

@fribbledom

> People make fun of… javascript for having all sorts of warts and weird inconsistencies, but as a language and a standard library, any commonly used shell plus the collection of widely used *nix tools taken together is much worse and contains much more accidental complexity due to inconsistency even within a single Linux distro and there's no other way it could have turned out.

Not entirely sure what to make of all this. I don't *want* to agree, but don't have great answers

4/4

@fribbledom
or better yet

find dir -print0 |xargs -0 chown user:group

@wolf480pl

For one: convenience. But also: not spawning a thousand chown processes.

@fribbledom
as for process spawning:
- there will be at most one chown at a time
- you could do:

find dir -exec chown user:group {} +

which would put as many files in each chown invocation as can fit in argv

- the whole Unix paradigm works best when creating processes is cheap. If creating processes is expensive, what can we do to make it cheaper?

@fribbledom
Convenience still stands though.
And that's the major reason why BSD and then GNU added most of these options

@wolf480pl

I know and didn't (necessarily) mean parallely. It will still launch chown a thousand times, though, and that's also not exactly the most efficient way of doing things 😉

@wolf480pl

To the second part of your reply, I guess some overhead we simply won't be able to get rid off:

- signal handlers
- env vars
- keeping state like current working dir, uid/gid/pid, open files
- arch specific stuff: registers
- address space / memory

Some things are optional, but probably are here for a good reason:

- cgroups
- namespaces

I'm probably also forgetting a whole bunch of other things here.

@wolf480pl @fribbledom I didn't know that detail! Thank you for sharing it. I guess I have some mass-spawning problems on my server when cron jobs run.

@vanitasvitae @fribbledom That one amused me because, as a UI/UX enthusiast, I agree with the sentiment but, perhaps ironically, I can also do that because I habitually unpack archives in the terminal.