Live data from Hacker News

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

joeyh.name

201–210 of 225 posts

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

#201
post #198
post #182

Earlier quoted context omitted.

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...

Yes, they're generally available in some form (now generally including the ‘originals’ now that V8–V10 have been published). And they're all very simple, which is the whole point of Unix tools.

I've found I'm using the `put`/`take` pair, for splitting a pipeline across shells, more again in the WFH era where I often have multiple ssh sessions into a machine, when I would probably have used the clipboard in a GUI session. Also useful for things like seeing stderr from different parts of a pipeline in different windows. `put` is just `cat >>$(mkpipe "$1")` and `take` is `cat $(mkpipe "$1")` where `mkpipe` is

    fifo="${TMPDIR:-/tmp}/fifo-$(id -u)-$1}"
    test -p "$fifo" || mkfifo "$fifo"
    echo "$fifo"

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

#202
post #80

Earlier quoted context omitted.

I'll bite: Why?

The Debian ripgrep binary is 5.1MB. That would consume over 15% of a 32MB flash, which is the common constraint you have to work with in many (actually, discounting Android, it might even be most) Linux deployments.

You're not likely to even find full-fat grep on such platforms (only busybox)

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

#203
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.

Hmm, I guess I considered Unix utils rather narrowly specialized, so `parallel` meant ‘my CPU got too many free cores’ for me. I'll take a closer look at it, thanks.

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

#204
post #164

Earlier quoted context omitted.

find doesn't return the same output as ls when run on another directory. Maybe there is a switch to do this? I'm not sure. $ mkdir -p tmp && touch tmp/a tmp/b tmp/c $ find ./tmp -maxdepth 1 -type f ./tmp/a ./tmp/c ./tmp/b $ ls -1 ./tmp a b c

You can also use basename with the find command $ find ./tmp -maxdepth 1 -type f -exec basename {} \; b a c I don't know the downsides of using basename though.

from all the solutions, this seems to be the most simple with readily available tools. Unfortunately it's still not as short as I would like it to be and I hope I remember the syntax with -exec $CMD {} \; the next time I need it.

Thanks to all the helpers, who took their time to propose solutions.

But what I was trying to say is: I would be ok with adding a new command to the tools I use on my machine, VMs and containers. fzf, fd, rg are tools which make my life easier. I would prefer to have the features of fls in ls itself or a tool similar to fls in coreutils, moreutils or another package .

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

#205
post #143

I wish there was a short and simple command for “list all files of a directory and no subdirectories“. ls doesn’t seem to have a switch for that kind of functionality. It’s discussed on stack-overflow. [0] Someone even wrote a nodejs tool for this functionality [1], but I would rather have something written in a compiled language. [0]: https://stackoverflow.com/questions/10574794/how-to-list-onl... [1]: https://githu…

The are two main responses to this comment as I write this. One of them lists only regular files. One of them lists anything that isn't a directory. And that 's why there isn't a short and simple command.

ah, yes, the simple test only had files, no symlinks, hidden files, etc, anything else you might want to distinguish upon in a shell script.

But I don't think it's too hard to solve this problem. A command which filters should also be able to invert the filter. One example for this is grep -v.

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

#206
post #175

I wish there was a short and simple command for “list all files of a directory and no subdirectories“. ls doesn’t seem to have a switch for that kind of functionality. It’s discussed on stack-overflow. [0] Someone even wrote a nodejs tool for this functionality [1], but I would rather have something written in a compiled language. [0]: https://stackoverflow.com/questions/10574794/how-to-list-onl... [1]: https://githu…

Try submitting a pr to exa. Probably the fastest way to get it solved properly.

Thanks for mentioning exa. I saw it before, but never tried it. Maybe this is an opportunity to learn Rust.

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

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

you raise a great point. why not install the package, then delete the /usr/bin files you don't need? would it solve the problem if the author namespaced the commands with a hyphenated prefix? curious about these considerations, which it seems like you've spent time thinking about. what do you see as the "best practices" regarding a set of utilities that are maintained and published together?

Another alternative might be, if the programs are single source code files and can mostly work by itself, you can just compile the ones you need and put the binaries where you need them, rather than installing a package.

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

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

Check out renameutils[1], which has the advantage over vidir of doing sanity checks before renaming. Also, this can be done in emacs using wdired. [1] - http://www.nongnu.org/renameutils/

MMV is reasonably powerful, but straightforward, can produce & consume rename listings, and is included in a lot of distros.: https://git.deb.at/w/pkg/mmv.git

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

#210
post #137

Earlier quoted context omitted.

Try sed s/foo/bar/ -i file to edit file.

That what I do now, one thing to note though is that the "-i" option is not always available. Usually, now, it is, but we still have a couple of Solaris servers at work that don't support it. This, btw, is why I hate shell scripts. There are so many variants of bourne shells and UNIX tools that writing a portable script is a minefield, as if properly dealing with spaces wasn't tricky enough...

Right you are. The -i option is not standard (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...)
Post reply on HN