Live data from Hacker News

Moreutils – Unix tools that nobody thought to write (2012)

joeyh.name

191–200 of 225 posts

Re: Moreutils – Unix tools that nobody thought to write (2012)

#191
post #170

Earlier quoted context omitted.

Interesting. Isn't it the case that LLVM doesn't support all architectures that Linux does?

I think this is just for kernel modules that you can choose to compile out.

That's what I expected too (as one of the people on the thread / one of the authors of the farthest-along set of bindings for modules), but Linus and Greg KH both seem fairly inclined for it to be on by default and used for core code (small bits of core code, in the beginning) and not simply modules. I'm not sure how that's going to play out with architecture support, and that's one of the things I want to get out of the Plumbers session this upcoming week.

https://github.com/fishinabarrel/linux-kernel-module-rust/is... is a chart of Linux architectures and whether Rust and LLVM support them.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#192
post #190
post #124

I seriously hate this package and the manner of combining different utils with different names in a same package in general. The reason being, "sponge" is an actually useful tool and for me it's pretty much the only useful tool in the package. So I need to install whole moreutils package on ubuntu to have "sponge" and I have to clog my bin namespace with all this trash. It would be mildly annoying from the perfection…

On principle, I agree with you -- this project should be split into multiple packages. However, it's the distro's job to harmoniously put various open source packages together. It's impossible for package authors to make everyone happy. Plus, in the moreutils case, the author has already gone to great lengths to publish his work for free, he shouldn't have to put up with more work to the point where it stops being fu…

Calling software "trash" is uncalled for, but squatting on a namespace is a real thing and not something that you can justify behind the usual "someone did this for free and owes you nothing" because this make the landscape worse for everyone else.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#193
post #191

Earlier quoted context omitted.

I think this is just for kernel modules that you can choose to compile out.

That's what I expected too (as one of the people on the thread / one of the authors of the farthest-along set of bindings for modules), but Linus and Greg KH both seem fairly inclined for it to be on by default and used for core code (small bits of core code, in the beginning) and not simply modules. I'm not sure how that's going to play out with architecture support, and that's one of the things I want to get out of…

Oh, wow, that would be huge. Not just architecture support, but even having a toolchain on some platforms might be problematic as I can imagine making rustc a requirement to build Linux to be fairly controversial in and of itself. And that architecture list is not looking very good…would be very interested to know what they decide on as well!

Re: Moreutils – Unix tools that nobody thought to write (2012)

#194
post #189
post #159

Earlier quoted context omitted.

While I don't use syntax highlighting, I find `lesspipe` useful for files that have a reasonable ‘presentation form’ as well as a source form — html, markdown, etc.

bat is another great alternative https://github.com/sharkdp/bat

Mentioned at the top of this thread ;)

Re: Moreutils – Unix tools that nobody thought to write (2012)

#195
post #27
post #15

Nice collection of quite useful tools. Some of these can be easily replicated by using a more modern shell (bash, zsh) like mispipe, others are just shortcuts (e.g. ifne, chronic). But what immediately stood out to me is `vidir`. I really like the idea of editing file names with an editor. Using loops and regex in a shell for mass renaming can be a mess. It should be way easier with `vim`. This tool made me install m…

On most POSIX systems you can use fc(1) to edit a command in your $EDITOR. In vi(1) and friends you can then use "%!ls" to replace the contents of the buffer with directory listing and edit the commands you want. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/f... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/v...

huh! I've been working on posix systems for 20 years and I didn't know that...

Re: Moreutils – Unix tools that nobody thought to write (2012)

#196
While we're on the topic and on the wave of modern riffs on classic tools, personally I'm pining for a remake of xargs—because I never can whack it into submission with anything more complex than `xargs rm`. Specifically, passing multiple arguments from the input to the called command apparently just can't be properly done, at least not on OSX.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#197
post #196

While we're on the topic and on the wave of modern riffs on classic tools, personally I'm pining for a remake of xargs—because I never can whack it into submission with anything more complex than `xargs rm`. Specifically, passing multiple arguments from the input to the called command apparently just can't be properly done, at least not on OSX.

parallel may be what you are looking for: https://www.gnu.org/software/bash/manual/html_node/GNU-Paral...

The defaults are a lot saner, and it's easier to pass arguments how you want.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#198
post #182
post #31

There's a few programs I wish were standard on all Unix systems by now: * tree - print directory structure * bat - cat, but actually designed for reading files. Syntax highlighting, line numbers, automatic paging. * rg - better grep * direnv - local environment variables

A few that I wish hadn't been ignored from 4BSD: jot -- print sequential or random data rs -- reshape a data array vis -- display non-printable characters in a visual format and from Unix >V7: apply -- apply a command to a set of arguments mc -- multicolumn print and from AT&T: tw -- file tree walk And then the obligatory personal tools that have stood the test of time: align -- align text columns crop -- crop lines…

Some of the above can easily be written in C or Python or Ruby (and some of the simpler ones even in shell), at least for simple versions, maybe without all the frills of the originals.

And seq in Linux is like jot for sequential data, at least.

And from my blog: An Unix seq-like utility in Python: https://jugad2.blogspot.com/2017/01/an-unix-seq-like-utility...

Re: Moreutils – Unix tools that nobody thought to write (2012)

#200
post #123

ts looks like it's a subset of https://github.com/ThomasHabets/ind sponge can be replaced with dd Other than that, yeah nice ideas. And very much in the unix spirit of one tool to do one thing.

sponge buffers the whole input before writing the output. Its utility would be in reading from a file, working on it with other tools, and writing the result back to the original file, all in one line.

Oh, neat! Thanks.
Post reply on HN