Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

joeyh.name

Post reply on HN
Print view View original

161–170 of 225 posts

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

#161

Post by boomboomsubban »

krick wrote: post #134
appleflaxen wrote: post #133

Earlier quoted context omitted.

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?

In a most general sense, this is not really a problem of moreutils, but of how tools are installed/distributed in Linux distributions. But since we have to be realistic, yes, package authors should take such problems into consideration. I think if tools are absolutely unrelated, they just should be distributed as a separate packages. GNU coreutils is tolerated mostly because it's so ubiquitous (so much, that it cause…

Stick the binary wherever your textile is, copy it to path on setup.

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

#162

Post by chriswarbo »

RMPR wrote: post #75
chriswarbo wrote: post #51

Earlier quoted context omitted.

I use Emacs shell-mode for most of my terminals, which allows navigating and editing the buffer just like any other file. I'll often make several copies of a command, then use a macro to alter each one; after checking that they look right, pressing Enter will send them all to the shell.

I always tried to use the shell with emacs (eshell, multi-term) but it didn't render correctly curses and all the fancy stuffs like emojis. Out of curiosity, how do you manage that?

I use a separate terminal (st) for curses-like things. They work in Emacs ansi-term, but since that doesn't offer the same navigation/editing interface as normal Emacs buffers I don't find it compelling enough to use.

Eshell is interesting, but I can't use the bashisms I'm used to, and I can't copy commands back-and-forth between the prompt and a standalone script.

shell-mode lives in-between these two extremes: it runs a normal shell, but Emacs manages the buffer. I don't know about ansi-term or eshell (or alternatives mentioned by others), but shell-mode handles emoji fine, as well as progress bars and colour codes; I think it defaults to TERM=dumb, so many programs won't output colour, etc. unless you override it to something like TERM=xterm-256.

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

#163

Post by jolmg »

nickthemagicman wrote: post #129
krick wrote: 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…

Is there a way to namespace on install? Or does that have to be configured in the package?

What I normally see in Archlinux is a rename of the less common conflicting utility when the package is built. In this example, the moreutils package's parallel utility and its manpage got renamed to parallel-moreutils.

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

#164

Post by iib »

rmetzler wrote: post #57
MaxBarraclough wrote: post #46

Earlier quoted context omitted.

But the top answer has it: > find . -maxdepth 1 -type f A little clunky, but there's certainly no need to mess about in JavaScript land. If you use it often, create a shell macro.

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.

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

#165

Post by happycube »

fiddlerwoaroof wrote: post #98
dig1 wrote: post #77

Earlier quoted context omitted.

MIPS and SPARC to name a few. Almost all routers are on MIPS and most of them are running some form of Linux or BSD. AFAIK, rust is still marked as "guaranteed to build" on these platforms, but assume only Linux. BSDs, not so much.

In my experience, most consumer routers are ARM?

Maybe new ones, but there's a ton of MIPS ones too.

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

#166

Post by tingletech »

nindalf wrote: post #136
gray_-_wolf wrote: post #109

Earlier quoted context omitted.

+ $ find /tmp/x ! -path /tmp/x -prune -type f -exec sh -c 'for p; do printf '\''%s\n'\'' "${p##*/}"; done' - {} + c b a Seems to do the trick and is POSIX only (so works on busybox and mac). You can probably just tack `| sort` at the end if you want it sorted.

This answer reminds me of the classic HN comment - why use Dropbox when "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software." People value software that's easy to use. That command you typed is a Frankenstein's m…

This had become a discussion of the best way to write the "shell macro" version that could replace the node.js program

  fls () {
   find . -maxdepth 1 -type f
  }
vs

  fls () {
   find . ! -path . -prune \
    -type f \ 
    -exec sh -c 'for p; do printf '\''%s\n'\'' "${p##*/}"; done' - {} +
  }
The user would just type `fls` in the directory they were exploring.

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

#167

Post by chalst »

appleflaxen wrote: post #133
krick wrote: 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?

Or use Nix to install these kinds of package and only create the symlinks you care about.

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

#168

Post by fooblat »

gpanders wrote: post #151
fooblat wrote: post #79

Earlier quoted context omitted.

If you use brew or macports you can install the coreutils package and then you're good to go with gnu find. I also use MacOS and I have setup the gnu userland on my local so it matches the linux environment on our servers and containers.

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 always taken this approach and it has served me well.

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

#169

Post by haberman »

gpanders wrote: post #149
enriquto wrote: post #144

Earlier quoted context omitted.

> tree I agree, tree is great. It can be somehow replicated by using "find .", if you are in a hurry. > bat If you need that functionality, why don't you open the file with vim, for example? > rg - better grep Grep is pretty nifty, I don't see how could it be improved. What is the main advantage of of rg over grep? > direnv - local environment variables I read the manpage for direnv and I was really scared. What is i…

Re: bat. I agree with you, I don’t get the hype over this program either. It’s pretty easy to configure 'less’ to use syntax highlighting and ‘less’ is installed basically everywhere. The main advantage of rg is how much faster it is than grep. It’s WAY faster. I don’t use direnv but I have colleagues who do. I think the idea is that it can set environment variables/run arbitrary commands when you cd into a certain d…

I also like that rg's default mode is to search all files recursively, skipping binary files and honoring .gitignore. 90% of the time this is just what I want.

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

#170

Post by chalst »

nindalf wrote: post #37
beojan wrote: post #32

Earlier quoted context omitted.

> rg Never going to happen because it's written in rust. ag ( https://github.com/ggreer/the_silver_searcher ) on the other hand is written in C.

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?

Post reply on HN