Live data from Hacker News

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

joeyh.name

181–190 of 225 posts

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

#181

Earlier quoted context omitted.

-i is definitely not specificed by POSIX, but it supported on all those platforms with some small differences, for instance on OSX the backup extension (-i.bak) is not optional.

Amazingly, there is no portable way to use -i that works on both GNU and BSD sed implementations. Which means if you’re writing a portable script, you can’t use -i at all. (Would love to be proved wrong on this)

According to Stack Overflow [1], this works:

    sed -i.bak 's/foo/bar/' filename
[1]: https://stackoverflow.com/a/22084103/3266847

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

#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 to a width
    dabl -- delete adjacent blank lines
    dtb -- delete trailing blanks
    emboxxen / deboxxen -- convert to/from box drawing characters
    eol -- convert line endings
    field -- simple line field extraction
    freeze / thaw -- cross-shell synchronization
    mergl -- merge lines into previous lines' blanks
    pad -- pad lines to a width
    put / take -- cross-shell pipe
    uni -- unicode character properties and search

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

#183
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…

Since Debian Stretch / Ubuntu 17.04 they do the right thing. If you install parallel & moreutils you get the GNU parallel as /usr/bin/parallel and moreutil's parallel as /usr/bin/parallel.moreutils. If you only install moreutils, it provides /usr/bin/parallel. You can use the debian alternatives system to flip the order. https://superuser.com/a/1253492/78988

Another alternative might be to have a set of packages, 'moreutils-spnge, moreutiles-pee, ... moreutils-common, moreutils-doc', which could be installed independently, and, if desired, a 'moreutils' virtual package dependent on the whole set for simplified installation.

Debian also has namespace-collision policies and an 'alternatives' facility for deciding which of multiple implementations of a tool (gawk, nawk, mawk; vim, vim-tiny, nvi; python3, python2; etc.) is primary on a given system.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597050

https://www.debian.org/doc/debian-policy/ch-binary.html#virt...

https://www.debian.org/doc/debian-policy/ap-pkg-alternatives...

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

#184
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…

I don't recall how difficult it is to maintain a debian package.

It seems like it shouldn't be too much work to fork the repository, and tweak the packaging logic to only include this one binary. You'd still have to compile the whole thing every time, but rebasing would be straightforward.

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

#185
post #170
post #37

Earlier quoted context omitted.

Never say never :) If Rust being added to the Linux kernel[1] isn't far-fetched, I don't think adding a utility in Rust is crazy either. [1] - https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+d...

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.

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

#186

Earlier quoted context omitted.

You’re right that defaulting to the GNU coreutils is probably more convenient. However, NOT doing this is a good way to ensure that any scripts you write remain portable and don’t use GNU extensions. That’s the reason I stick with the default BSD coreutils on macOS.

> You’re right that defaulting to the GNU coreutils is probably more convenient. It's not about convenience. It is about having a development environment that matches the target runtime environment. You can run into nasty surprises when the default behavior of a tool in your dev environment is different than in your production environment. I've been writing shell scripts professionally for over 20 years and I have al…

You could also try restricting yourself to POSIX shell.

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

#187

Earlier quoted context omitted.

Amazingly, there is no portable way to use -i that works on both GNU and BSD sed implementations. Which means if you’re writing a portable script, you can’t use -i at all. (Would love to be proved wrong on this)

According to Stack Overflow [1], this works: sed -i.bak 's/foo/bar/' filename [1]: https://stackoverflow.com/a/22084103/3266847

That works when specifying a backup extension, but not if you don’t want to create a backup file.

    sed -i ‘’ ...
works on BSD sed but not GNU. Meanwhile:

    sed -i’’ ...
    sed -i ...
both work on GNU but not BSD.

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

#188
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…

I used vidir yesterday for something that would have been more annoying with other tools - if you swap the numbers at the beginning of the line, then you'll safely swap the file contents. Useful if your TV episodes are named the wrong thing...

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

#189
post #159

Earlier quoted context omitted.

Ha! Here’s how to have syntax highlighting while using less: https://superuser.com/questions/71588/how-to-syntax-highligh...

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

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

#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 fun for him/her. Finally, it's just NOT appropriate to call parts of this project "trash". He scrached his itch and was kind enough to publish his work. If you don't like it, just don't use it, no need to be harsh about it.

The right way for distros to package this is to split the moreutils source distribution into moreutils-* packages, plus a meta package that pulls in all of the commands. So your complaint actually belongs in your distro's bug tracker -- it has nothing to do with the moreutils project.

Post reply on HN